撰写于：2013年11月21日
作者：silex Wi-Fi专家

关于EAP的话题告一段落后，本文将说明“WiFi网络连接的步骤”。

信标和扫描
想要连接到WiFi网络的工作站(STA)，首先从寻找接入点(AP)开始。通常是通过被称为SSID(Service Set ID)的字符串来识别网络，但在WiFi规范上，识别AP的是BSSID(Basic Service Set ID，实际是MAC地址)，SSID是可选的，也可以使用没有SSID的AP。这种模式通常被称为“隐形AP”，但是“隐形AP”这个术语有很多不同的定义(注)，所以不一定是通用的术语。
(注)被称为“隐形AP”的形式有使用长度为0的SSID和使用字符代码仅0x00构成的SSID两种情况。另外，还有一种相当特殊的形式，就是AP不发送信标，只响应Probe request(后文)，这种情况也被称为“隐形AP”。
WiFi网络中的AP通常会在AP工作的信道上持续发送被称为“信标”的分组(通常是100毫秒间隔，即10次左右)。信标包含各种各样的信息，其中最具代表性的包括：
· BSSID, SSID
· 信标发送间隔
· 信道(频率)信息
· 支持的传输速度列表
· 安全信息
图1显示了silex SX-AP-4800N的信标示例。请注意，信息分散在各处，反映了WiFi标准逐步发展的经过。例如，关于安全性，WEP的信息在“Capabilities Bit”中，WPA的信息在“Vendor Specific:Microsoft WPA Information Element”中，WPA 2/802.11i的信息在“RSN Information”中。另外，关于通信速率，1～18Mbps为“Supported Rates”，24～54Mbps为“Extended Supported Rates”，802.11n的扩展模式为“HT Capabilities”。

图１ 信标示例

仔细观察，我想可以看到使用Capability Bits的32bit增建HT Capability IE的样子。在Capability Bits中，802.11/b混合用的Short Preamble，802.11b/g混合用的Short Slot Time和DSSS-OFDM等现在几乎没有意义的信息也很多，像这样的旧规格遗留和后面扩展的信息分散在多个字段中是WiFi无线LAN规格的特征。

STA可以通过接收信标来获得AP列表，该行为称为“静态扫描(Passive scan)”。另外，也可以积极地对AP进行“有人吗？”的询问(Probe request)，将该动作称为“动态扫描(Active scan)”。AP通过一个名为Probe response的包对Probe request进行响应，但Probe response的内容与信标几乎相同。

不仅是AP、STA，无线节点原则上只能同时发送和接收一个频率（信道）。因此，寻找想要连接的AP的STA必须在遍历所有“可能通信的信道”的同时进行静态或动态扫描，制作AP的一览。通常称为“扫描”时，多指进行该“逐个信道进行动态扫描”的动作。

在某些环境中，可能会有多个AP(在不同的信道上)使用相同的SSID。在企业网络中，为了用单一的SSID覆盖一栋大楼或一个楼层，同一SSID的AP在不同的信道上交替配置运用的情况也很多(漫游环境)。这种情况下，STA终端必须从生成的AP列表中选择“最容易连接的AP”。这个选择算法因制造商和配置而异，但是一般选择电波强度(RSSI:Received Signal Strength Indicator)最强的AP。

关联程序
那么，选择连接目的地的AP后，终于开始连接步骤了。这是通过数据包交换来执行的。
STA→AP 认证
AP→STA 认证
STA→AP Association Request
AP→STA Association Response

“认证”是WEP时代的“Shared” 认证中为了确认密码而使用的步骤，但现在几乎形同虚设。Shared认证不仅不会增加安全性，反而会成为安全漏洞（※注），所以现在强烈推荐不使用。另一方面，WPA以后扩展的认证方式（WPA-PSK和WPA-EAP）不使用认证的框架，所以在现在的WiFi中认证没有实质性的功能。
（※注）如果认证失败，则已知密码不同，所以攻击者可以通过任意组合“可能的密码组合”来寻找“正确”的密码。

Association Request是来自STA的连接请求，Association Response是来自AP的连接许可（或拒绝）响应。这里交换的信息也大致与信标和Probe-request/Probe-response相同，但更多的信息（如规则信息和WMM/QOS相关的信息），通常是可选的。“兼容性”问题，例如无法仅连接到特定制造商的特定接入点型号，经常发生在此关联过程中，这也是我们网络工程师最先考虑的部分。

认证步骤(4次握手)
Association手续完成后，在开放系统认证(无加密或WEP)的情况下，STA和AP的连接完成，但WPA使用安全性的情况下在这之后开始认证步骤。在PSK认证的情况下，在Association Response之后，AP会开始被称为4次握手的步骤。

STA→AP Association Request
AP→STA Association Response
AP→STA Key message 1/4
STA→AP Key message 2/4
AP→STA Key message 3/4
STA→AP Key message 4/4

Key message的详细内容就不提了，通过Nonce、IV、MIC等一系列信息的交换，用第三方不知道的方法交换秘匙信息。

使用WPA2-PSK的连接步骤的示例如图2所示。帧编号1 ~ 6是扫描步骤，7 ~ 12是联合步骤，17 ~ 23是4次握手步骤。 

图２ 连接步骤示例

WiFi连接失败……所谓的“连接不上”问题发生在其中的某个环节，例如找不到AP（SSID不同）、找到的AP不符合连接条件（安全设定不同）、Association Request被拒绝（国家代码不同、请求比特率不一致、脱离Listen Interval范围等）、4次握手失败（密码错误）。

若您所见，连接失败的原因大部分是设置错误，但在极少数情况下，包括错误在内的“兼容性问题”它也可能发生。例如，在AP的设置中，当禁止802.11n而设置为802.11b/g模式时，本来不应该设置的HT Capabilities信息在错误的状态下(例如假设有一个具有漏洞的AP进入信标中，只有length=0的报头，作为无内容字段)，在某些实现中(例如Windows PC)因为忽略了坏掉的信息所以能够连接，但是其他的实现方式(例如iPhone)因为把坏掉的信息当作错误处理所以无法连接。
在这种情况下，如果AP方面的设置允许802.11n的话，HT Capabilities信息就会正确登记，“为了提高兼容性，为什么要设置b/g模式呢?只有iPhone不能连接，设置成11n模式兼容性更高”的迷之现象，我想外行人不知道是怎么回事。而且，市面上销售的消费类AP，即使是同一厂家、同一型号的产品，由于生产批次不同，所搭载的芯片组也会有所不同，这种微妙的漏洞也会因批次不同有所差异。

这并不是威胁，消费类AP在大部分情况下都没有问题，但是偶尔出现这样的问题，如果不抓取数据包查看内容就不知道发生了什么。此时，会出现“我家的无线局域网不好，能告诉我哪里不好吗?”诸如此类的问题，我想，越了解无线LAN，越不可能知道仅通过症状就能判断问题的原因了。

认证步骤(EAPoL)
那么，EAP认证的情况下，在Association Response之后，AP开始EAPoL认证步骤。
STA→AP Association Request
AP→STA Association Response
AP→STA EAPoL Identity Request
STA→AP EAPoL Identity Response
AP→STA EAPoL Request
STA→AP EAPoL Response
       .
       .
       .
AP→STA EAPoL Success

EAPoL的请求/响应交换重复多次，直到AP返回成功或错误。EAPoL的内容取决于配置的EAP类型（例如，LEAP、TLS、PEAP），简单的EAP-MD5只需一次Challenge request/Challenge response，而EAP-TLS和PEAP通常需要20到30次数据包交换，以便将TLS协议的过程（Server Hello、Client Hello、Cipher Spec…）拆分为帧。
EAP完成后，通常会运行4次握手来交换密码密钥。因为WiFi的规格上“认证”和“加密”是不同的规格，所以也可以用“EAP-PEAP+无密码”和“EAP-TLS+WEP密码”的组合来工作，但是在强大的EAP认证中特意组合弱密码使用的实用意义几乎没有。

连接后的处理
经过扫描、关联和认证后，STA就与AP连接，可以收发数据包。但是即使连接完成了，还有一些工作要做。
如果使用WPA（WPA/WPA2），则 AP 会定期续订组播密钥（GTK）。GTK更新后， AP将向连接中的STA发送“密钥更新通知”（EAPoL Group Key Message，1/2）。收到此消息的STA必须执行相应的密钥更新处理并返回“EAPoL Group Key Message，2/2”。通常，这个过程运行在驱动上层实现。
根据AP的实现和设置，STA 可能会在一段时间不活动后自动断开连接（超时功能）。此时，如果发出断开通知（Deauthentication），STA端可以进行重新连接处理，但有些AP会默默断开连接而不发出通知，也有由于信号状况暂时恶劣，预期的断线通知可能无法到达。这样的话，会导致“有时会断开连接”“一旦断了就不会再重新连接”这种不理想的问题发生。

为了避免这种“不知不觉就断开”的问题，根据驱动程序的安装和设置，有时即使没有上层通信也会定期进行通信，将其称为保持连接（Keep alive）。保持连接发送的数据可以是没有数据的空帧(Null frame)，或者是通知自己的IP地址的ARP包（Gratituous ARP），这也根据实现和设置而不同。

前面提到的漫游环境…在具有相同SSID的AP进行多个动作的环境中，STA掌握“当前连接的AP的电波状况”和“其他AP的电波状况”，在电波状况恶化时掌握其他AP要求重新连接(漫游)的动作。漫游是无线连接完成后驱动所进行的最重要的工作，也是比GTK更新和保持程序更容易成为故障根源的功能。
总之，“现在连接的AP电波状况”可以从信标的RSSI中掌握，但是在很多实现中，不仅仅是信标，通信分组的数据速率和重发次数也包含在漫游计算中。因为信标是以最低数据速率（2.4GHz为1Mbps DSSS+BPSK，5GHz为6Mbps OFDM+BPSK+编码率1/2）发送的，所以信标RSSI未必反映实际数据通信速率下的电波状况。
比“当前连接的AP”更麻烦的是掌握“漫游目标候补的AP”。如上所述，“原则上无线节点只能同时在一个频率（信道）发送和接收数据包”，因此不能一边与连接中的AP通信，一边扫描其他信道AP。这里是各厂商都下了功夫的地方。当检测到数据通信在一定时间内中断时进行扫描，当电波状况恶化到一定程度以上时，即使中断数据通信也进行无线扫描，从而寻找漫游目的地AP。

WiFi驱动程序复杂的原因
以上是关于WiFi的连接和通信的步骤，我试着解说了“非常基本的内容”。这些功能几乎都在“WiFi驱动程序”上实现（※注）。“调查Association-Reponse帧中包含的HT Information IE的Rx Supported MCS Scheme字段，将可设定的HT发送速率的位图设定为PHY驱动程序”等功能也是WiFi驱动程序的一部分。
（※注）部分的功能在“扩展功能”中，广义上包括扩展功能在内，都被称为“驱动程序”。

通常所谓的“设备驱动”，只有将数据块从A点（存储器上）转移到B点（设备的连接处）的功能。例如，如果是有线网驱动程序，只需在上级指定的数据上加上MAC头，经由DMA传递给MAC控制器（或反之）。以太网也有一个简单的协议（CSMA/CD），就像电路繁忙控制一样简单，但它基本上是由以太网芯片硬件处理的，不需要驱动软件来处理。
但是，在WiFi中，即使采取一个“连接接入点”的动作，也需要“扫描”、“关联”、“认证”、“漫游监视”、“KeepAlive“、“GTK监视”这一系列的功能，每一个功能都需要多个数据包的收发。WiFi的规格阶段性发展的现状（WEP、WPA、WPA2和11b、11a/g、11n等），以及根据制造商·安装·设置的不同，数据包结构和字段值均有微妙的不同（既有规格上的不同，也有因bug而产生的不同），这会更加增加驱动程序工作的复杂性。“WiFi驱动程序”比其他驱动程序（例如有线LAN的驱动程序）复杂得多，这是有理由的。
WiFi的连接步骤是标准规格和协议决定的，所以也有人认为，不要模仿每个供应商、每个芯片、每个驱动程序的安装，在系统上作为标准功能安装驱动，驱动程序只支持“设置频率”、“发送数据包”、“接收数据包”程度的功能就好了（※注）。实际上，Windows、MacOS、Linux也采取了这样的方法。但是，iTRON等工业嵌入式RTOS没有类似的功能，结果还是必须由驱动程序全部承担所有工作，智能型的WiFi模块在芯片上卸载连接手续（部分），相反必须绕过系统的WiFi功能等，因为有各种各样的“情况”，所以不能一体化。最终，驱动程序作为解决各种矛盾和情况的“必要性”继续存在。
（※注）蓝牙配置与此相近，驱动蓝牙芯片的“HCI驱动程序”和实现协议和配置文件的服务层很好地实现了分开处理。为什么WiFi没有变成这样呢……这是历史的遗留问题吗。

回顾历史
20世纪80年代中期，在工程工作站（EWS）开始流行的时候，TCP/IP协议被称为“规格太重，不适合PC”。说起那个时候的PC，因为是背负着640 KByte内存限制的单任务DOS，所以没办法。虽然也有从DOS PC共享Unix上文件的PC-NFS系统，但由于安装上有很多习惯和错误，很难使其与操作兼容。
DOS的内存限制源于intel 80286的CPU架构(注)，实际上取消这一限制是在95年Windows95大卖之后。但是初期微软生产的TCP/IP堆栈在Winsock上有bug, 95系统和NT系统的运行不一样，直到2000年左右都没有稳定下来。在Unix的世界里，TCP/IP的规范在4.3BSD(1986)基本成型，但从普及到规范在消费者市场上也花了15年左右的时间。
(注)关于286的Protected Virtual Address Mode，我个人有些怨言，关于这个写起来太长了，就不多说了。今后也不想在这个博客上讨论。

我觉得无线LAN的状况也和过去的TCP/IP相似。1999年10月，IEEE802.11b-1999发布，至今已经过了整整14年，但仍然没有稳定下来的迹象，每隔几年就会有一次的提速，重复进行后续扩展(802.11a/g/n/ac/ad)，安全标准WPA2(802.11i)的制定也花费了时间(出现了WPA/TKIP这种不成熟的过渡标准)，上次提到的EAP因为认证协议的混乱也还没有解决吧。
作为企业来说，如果规格混乱，出现兼容性的问题，可能会更感激增加的工作量，这也许是企业愿意看到的，但作为一名工程师，我希望“适可而止”。