公司研发的硬件，运行自行定制的 Android ROM（基于 AOSP 4.4），偶尔会发生一个怪异的网络问题：

• 主机 wifi 首先接入当前网络 A，一切没问题（可以访问 IDC 服务器）；切换接入到另一个网络 B，无法访问 IDC 服务器，但此时在网络 B 的主机访问其他的 Internet 服务并无问题
• 主机 wifi 首先接入网络 B，一切没问题；切换接入到一个网络 A，一切没问题；再切回到网络 B，无法访问 IDC 服务器，访问其他 Internet 服务并无问题

这个问题在办公室环境下发生频率较高（但并非 100%），也有部分客户会抱怨切换网络后不能访问服务器。

公司网络 A 的结构不同于一般家用网络，默认网关和对外的出口路由器并不是同一台设备，结构示意如下：

DHCP
Network: 192.168.0.0/24
Gateway: 192.168.0.1，负责公司内部各网络间的数据交换
DNS: 192.168.0.201
Router: 192.168.0.254，负责提供 Internet 接入

先说原因/结论：主机的 ROM 不能正确清理由 ICMP Redirect 报文生成的路由缓存。

下文是分析过程的流水记录。

初次排查

刚发生这个问题的时候，大家都很困惑，因为除了主机外，其他的设备全部没有这个问题（手机、平板、PC），自然会认为问题是出在主机上。不过因为在客户手上的机器并没怎么出现过这个问题，所以公司内部测试的时候会避免这个问题。

随着业务规模扩大，主机遭遇的网络环境各种各样，有更多的客户反馈这个问题，于是在一个周末，几个同事一起分析这个问题：

1. 起初，我们怀疑是 DNS 被劫持，但在不同网络下 ping IDC 服务器可以看得到 DNS 解析没问题
2. 奇怪的是，在 A 网络下直接 ping IDC 的 IP 可以 ping 通，切换到 B 网络下却一直提示 unreachable
3. 而同样的，在 A 网络下 ping baidu.com 可以 ping 通，切换到 B 网络下也仍能 ping 通 baidu.com，仔细观察了一下发现，baidu.com 做了 DNS balance，所以测试中先后两次其实 ping 的是不同的 IP
4. A 网络下选定一个 baidu 的 IP 直接 ping 可以 ping 通，切换到 B 网络下也仍能 ping 通，这下就很头疼了，因为就 IDC 的 IP 无法 ping 通
5. 重复了一次第 4 步，这次发现 baidu 的 IP 和 IDC 的 IP 一个表现，B 网络下也不能 ping 通
6. 翻看 Linux 的路由表，并没有什么特别
7. 大家都陷入了沉思……
8. 重复测试了几遍，结果和第一次没什么差别，IDC 的 IP 表现一直一致，baidu 的 IP 一会正常一会儿不正常
9. 引入新的网络 C，在网络 B 和网络 C 之间反复切换多次对比测试，一切都正常
10. 有十几年经验的 IT 经理做了一个较合理的猜想：Linux 自己控制着一张隐藏的路由表，主机因为某个 bug，在切换网络时，隐藏的路由表没有同步更新，导致同样的 IP 在不同的网络下不能正确寻路
11. 最后的结论是：公司的网络架构较一般环境复杂，通常情况下不会有客户会处在这么复杂的架构下，如果发生了这种情况，尽可能帮助客户简化网络复杂度

虽然这次分析并没有找到真正的原因，但是 IT 经理的猜想对我产生挺大冲击的。

因为在我看来，操作系统该做的是维护和管理好资源，对用户提供抽象的高级管理接口。

就路由而言，理当遵照我们所看到的路由表那样去工作，怎么会偷偷搞一张用户无法控制的隐藏路由表呢？

可这又是当时最能解释现象的说法，我也只能信，同时也因此感到困惑。

不过后来的某一天，在一篇讲述 Linux 下策略路由的文章中了解到，Linux 支持最多 255 张策略路由表，普通的路由指令显示的只是其中一张较低优先级的默认路由表而已。这一刻我几乎就信了，只要查出出问题的那张路由表不就可以解决这个网络问题吗！

这时，我突然挺佩服 IT 经理，能大胆地做出这么一个方向上让人豁然开朗的猜想。

不过，进展仍然止步于此，因为之后我们没有再去讨论这个问题，我也没再去分析出问题的主机网络状况。

问题再现

最近仍有客户反馈这个问题，在上周，硬件部和 IT 部一起重新搭建一个网络环境，用来调查这个问题，因为硬件部担心问题可能是出在 wifi 芯片上。

当时 IT 的同事找到正在码代码的我（我并不清楚他们在做什么测试），向我咨询一个奇怪的问题，描述如下：

主机接入新网络 X，一切正常，切换到公司网络 A，一切正常，切换回网络 X，不能 ping 通网络 X 中的网关。而此时，接入网络 X 的手机并没有异常，可以 ping 通网关，诡异的是，居然也能 ping 通主机。

一开始听到这个描述，我直接摇头否认这个问题的描述，因为我认为，同在一个简单链路内，没有理由不能相互 ping 通（没有防火墙），更何况问题发生时，主机和手机之间是可以相互 ping 通的；而 wifi 环境下所有数据包都需要经过 AP 中转，AP 同时也是路由器，没理由数据包能被路由转发到其他设备，但路由自己却收不到。

可是，当我坐在主机前，做了一些验证后，我惊呆了，居然真的不能 ping 通网关。要知道，在同一个链路内，数据的传递只靠各自的网卡就能完成。

最终分析

查看路由表，切换网络前后的路由表都看不出异常，这时我突然想起来查一下”隐藏的路由表”，可是最后翻遍所有的路由表，发现没有任何异常，看来上一次的分析结论和 Linux 的 255 张路由表没有关系。

没有什么头绪，抓包吧，一边 ping 网关，一边 tcpdump 抓包，终于！露出马脚了！

网络 X 的网关是 192.168.1.1，网络 A 的网关是 192.168.0.1，网络 A 的出口路由是 192.168.0.204。

当我接入在网络 X 下，ping 着网络 X 的网关时，tcpdump 抓包却看到系统一直在广播 ARP 查找 192.168.0.204 这个 IP，明明切换了网络，192.168.0.204 根本就不再出现网络 X 上，而这个 IP 又正是网络 A 的出口路由（非网关），这一定不是巧合！

重启主机，从没接入任何网络时就开始抓包，抓住整个测试过程中的所有包，看能否找出原因：

1. 在初次接入网络 X 的情况下，没有发现异常
2. 切换到网络 A 下，果然，频繁收到 ICMP 的重定向包，指示相关的 IP 访问可以由 192.168.0.204 转发完成。注意，这里的重定向不仅仅只有公司的 API 服务器 IP，还有网络 X 的网关 192.168.1.1（由于接入过网络 X，某些应用可能抓取了 X 下的网关做网络连通性测试用途）
3. 切换回网络 X，重新 ping 网关，真的 ping 不通了，而且抓到的全部都是探寻 IP 地址 192.168.0.204 的 ARP 数据包

不过，找来更多的机器试图重现这个问题，却发现这问题并不能完全重现。继续分析了一下，原因在于路由器发送 ICMP 重定向包存在一个不污染网络的策略，有一个频率限制，外部看起来呈现一定的随机性。针对这个小问题，在网络 A 的网关上人为伪造 ICMP 重定向包每 3 秒发送一次，最终做到了所有机器全部可以重现问题。

解决方案

很简单，调整内核参数，忽略所有 ICMP 重定向包：

1
2

net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.accept_redirects = 0

PS：尽管问题出现在 ROM 本身，但是最终没能查到原因。

提问

此前，我有过这样一个疑惑：

wifi 的数据传输形式为广播，那么考虑一下，当 A 站发送数据给 B 站时

1. 如果 A 站和 B 站之间信号不直接可达，那么数据将会先由 A 站流往 AP（接入点/基站/路由器），再由 AP 流往 B 站，即靠 AP 做转发
2. 如果 A 站和 B 站之间信号直接可达，数据广播出去后，AP 和 B 站都会收到这个数据，那么 B 站是直接接受还是抛弃？又由于 AP 并不知道 B 站是否已经接收，所以会坚持转发一次，如果 B 站直接接受了，岂不是会导致数据无条件重发？

在理解了 wifi 的数据加密形式后，疑惑也被顺便解开了。

PS：说 wifi 其实不严谨，802.11 会更规范一点，不过为了方便理解，直接说 wifi 也无妨，因为不少读者可能不熟悉 802.11 和 wifi 的关系。

共识

行文开始前先做一些概念约束以及一些我的个人观点。

模式限定

探讨范围限定在 AP 模式，也就是最流行的 wifi 接入模式，不涉及 Ad-hoc 模式，简要的描述就是：

• 有一个无线设备工作在 AP 模式，承担基站的角色（路由器）
• 其他所有的设备全部和基站建立无线链路（手机、平板、笔记本……接入 wifi）
• 所有站点之间的数据通信均通过基站进行转发，类似于 C/S 模式
• 只要基站挂掉，所有站点之间将无法互相通信

通信数据安全

一般而言，通信数据的加密手段不同于数据存储。对于数据存储，通常采用对称加密，且只用一把密钥；而通信数据的做法大致是这样的：

• 通信双方共享一把长期的主密钥 K
• 通信双方基于 K 做一次安全握手，派生出一把当前会话使用的密钥 k
• 接下来的通信均使用 k 加密
• 每隔一定时间，双方重新派生出一把新的会话密钥 k2，替换 k，继续后续通信

这样做的好处有两点：

• 密钥分离：会话密钥 k 即便泄露也不会牵连主密钥 K，反过来主密钥被攻破之前的历史会话也不会因为一把 k 的泄露而全军覆没
• 密钥新鲜度：同一把密钥加密的样本越多，越有利于密码分析。即便算法本身没被破，定期轮换密钥也能提高整体的安全性

广播报文与广播链路

在广播式链路上发送广播报文具有得天独厚的优势：

• 古老的集线器也是广播式链路，某站点要发送一个广播报文，集线器不需要任何处理，只需要把广播报文当成普通报文广播即可
• 交换机将集线器的广播式链路改成了点对点链路，某站点要发送一个广播报文，交换机只能将该报文从每一个端口发送一次
• wifi 使用无线电通讯，自然也是广播链路，因此，某站点要发送一个广播报文，AP 只需要发送一次数据即可，无需将广播报文挨个站点发送一次

流程

大致流程如下（忽略广播）：

1. AP 和站点之间共享相同的初始密钥 PMK（Pairwise Master Key），关于 PMK 的来源后文会给出
2. 每当有站点请求接入 AP，AP 和站点之间就会通过 PMK 生成出一把正式传输数据用到的密钥 PTK（Pairwise Transient Key）
3. AP 和站点之间的通讯全部使用 PTK 加密

如果稍加留意，你会发现，每个站点和 AP 之间都维护着一个 PTK，但是站点和站点之间是不共享 PTK 的，站点 A 和 AP 之间的通讯使用 PTKa，站点 B 和 AP 之间的通讯使用 PTKb。

因此，站点 A 是没有能力和站点 B 直接通讯的，必须经由 AP 做数据转发，也就是说，即使站点 B 接收到了站点 A 发出的帧中白纸黑字写着”接收方为站点 B”，站点 B 也不得不抛弃，因为帧中的载荷数据是使用 PTKa 加密的，而站点 B 并不知道 PTKa，只能等待 AP 解析此帧，并换用 PTKb 加密后重新发送一个新帧，站点 B 才可以看见来自站点 A 的数据。

换言之，PTK 的方式保证了站点和站点之间在链路上是 “隔离” 的，任何站点都无法嗅探到不是发送给它的数据。

接下来谈谈数据的广播，如果站点 A 需要发送 IP 广播，单借助 PTK，也是可以做到的：站点 A 将广播包发送给 AP，AP 再将广播包重新编码逐个发给所有接入的站点，但这种做法太愚蠢，现实的流程如下：

1. AP 启动后生成一个随机初始密钥 GMK（Group Master Key）
2. AP 使用 GMK 通过某种算法，衍生出一个用于加密广播/组播数据的密钥 GTK
3. 每个接入 AP 的站点在得到了 PTK 后，AP 将 GTK 使用 PTK 加密后发送给站点

换言之，所有站点都持有相同的 GTK，那么站点发送 IP 广播的流程究竟是怎么样的呢？最容易想到的有两种。

第一种，站点直接通过 GTK 进行广播：

1. 站点 A 使用 GTK 加密广播包并发送
2. 站点 B 接收到从站点 A 发出的广播包
3. 站点 C 离 A 较远，没能收到从站点 A 发出的广播包
4. AP 收到了从站点 A 发出的广播包，然后做一次接力转发
5. 所有站点接收到从 AP 转发的广播包

第二种，由 AP 通过 GTK 进行广播：

1. 站点 A 使用 PTKa 加密广播包并发送
2. AP 接收到从站点 A 发出的广播包
3. AP 解码接收到的广播包，并使用 GTK 加密该广播包，再接力转发出去
4. 所有站点接收到该 AP 转发的广播包

不难看出，第二种方式是最优的，因为模式简单且和单播方式统一，而且第一种方式会造成站点重复接收广播包。事实上也的确采用的第二种方式。所以，GTK 对于站点来说，只用于解密，对于 AP 来说，只用于加密。

总结：wifi 网络内的所有站点间的所有通信都必须交给 AP 转发，站点和站点之间不存在任何直接通信行为。

关于 PMK

PMK 是怎么来的呢？

简单的说，接入 wifi 时需要你填的那个密码被称之为 PSK（Pre-Shared Key），将 PSK 使用一套算法进行一次转换，就是所谓的 PMK 了。

当然，PMK 不仅仅可以通过 PSK 得到，如果 wifi 使用 802.1X 的企业级证书认证方式（民用 wifi 很少支持这种认证方式），那么，PMK 就是标准的非对称密钥生成的对称密钥。

关于 GMK

此前我认为：GMK 可能只是为了和 PMK 概念对称，实际使用中，感觉完全没有存在的必要，AP 每次都生成一个随机串作为 GTK 就可以了。

如今我认为：GMK 的存在是为了方便 GTK 的周期性轮换——比如有站点退出网络时，应当更换 GTK 让退出的站点无法继续解密后续的广播数据，由 GMK 经过派生算出新 GTK，比每次都重新生成随机串要更轻量、可控。GMK 是某个 AP 自己内部的事，并不在多个 AP 之间共享。