android framework

Android 系统 wifi基础知识

第3章 Wi-Fi基础知识
本章所涉及的源代码文件名及位置
·wireless.h external/ kernel-headers/ original/ linux/ wireless.h
·driver_wext.c external/ wpa_supplicant_8/ src/ drivers/ driver_wext.c
·netlink.h external/ kernel-headers/ original/ linux/ netlink.h
·driver_nl80211.c external/ wpa_supplicant_8/ src/ drivers/ driver_nl80211.c
·nl80211_copy.h
external/ wpa_supplicant8/ wpa_supplicant/ src/ drivers/ nl80211_copy.h
3.1 概述
W i-Fi（W ireless Fidelity）是一个无线网络通信技术的品牌，由W i-Fi联盟（W i-Fi
Alliance，W FA）拥有。W FA专门负责W i-Fi认证与商标授权工作。严格地说，W i-Fi是
一个认证的名称，该认证用于测试无线网络设备是否符合IEEE 802.11系列协议的规范。通
过该认证的设备将被授予一个名为W i-Fi CERTIFIED的商标。不过，随着获得W i-Fi认证
的设备普及，人们也就习以为常得称无线网络为W i-Fi网络了。
提示 IEEE 802.11规范和W i-Fi的关系很难用一两句话说清楚，读者可阅读参考资料
[1]进行了解。简单来说，IEEE 802.11是无线网络技术的官方标准，而W FA则参考802.11
规范制订了一套W i-Fi测试方案（Test Plan）。不过，Test Plan和802.11的内容并不完
全一致。有些Test项包含了目前802.11还未涉及的内容。另外，Test Plan也未覆盖802.11
所有内容。所以参考资料[1]把W i-Fi定义为802.11规范子集的扩展。
本章从以下两方面向读者介绍W i-Fi技术。
·IEEE 802.11协议涉及的理论知识，包括无线频谱资源、IEEE 802.11/ 802.X协议中
的相关内容、关键概念（如Access Point）、MAC帧、无线网络安全等。
·如何在Linux系统中通过Linux W ireless Extension以及nl80211 API操作无线网
络设备。
提示由于篇幅问题，本书将不讨论W FA制订的一些标准（如W i-Fi Display、W i-Fi
Simple Configuration等）。不过作为W i-Fi技术的重要组成部分，笔者将在博客中对它
们进行系统介绍 ① 。
① 笔者博客地址为blog.csdn.net/ innost或者my.oschina.net/ innost/ blog。
3.2 无线电频谱和802.11协议的发展历程
本节将介绍无线电频谱和802.11协议发展历程。
3.2.1 无线电频谱知识 [2]
W i-Fi依靠无线电波来传递数据。绝大多数情况下，这些能收发无线电波的设备往往被
强制限制在某个无线频率范围内工作。这是因为无线频谱（即无线电波的频率，Radio
Spectrum，单位为Hz）是一种非常重要的资源。所以目前大部分国家对无线频谱的使用都
有国家级的管制。以下是几个主要国家的管制机构。
·FCC（Federal Communication Commission），美国联邦通信委员会。
·ERO（European Radio-Communication Office），欧洲无线电通信局。
·MIIT（Ministry of industry and Information Technology），中国工信部下属
的无线电管理局。
·ITU（International Telecommunication Union），国际电信联盟。
上述这些机构是如何管理无线频谱资源的呢？一般而言，无线频谱资源将按照无线电频
率的高低进行划分。有一些频率范围内的频谱资源必须得到这些管制机构的授权才可使用，
而有些频率范围的频谱资源无须管制机构的授权就可使用。这些无须授权的频谱大部分集中
在ISM（Industrial Scientific Medical），国际共用频段中。
ISM是位于ISM频段的频谱资源被工业、科学和医学三个主要机构使用。ISM一词最早
由FCC定义。不过，各国的ISM频段并不完全一致。例如，美国有三个频段属于ISM，分别
是902-908MHz、2400-2483.5MHz和5725-5850MHz。另外，各国都将2.4GHz频段划分
于ISM范围，所以W i-Fi、蓝牙等均可工作在此频段上。
注意虽然无须授权就可以使用这些频段资源，但管制机构对设备的功率却有要求，因
为无线频谱具有易被污染的特点，而较大的功率则会干扰周围其他设备的使用。
3.2.2 IEEE 802.11发展历程
使用过W i-Fi的读者或多或少都接触过IEEE 802.11，它到底代表什么呢？
IEEE（Institute of Electrical and Electronics Engineers）是美国电气和电子工
程师协会的简称。802是该组织中一个专门负责制定局域网标准的委员会，也称为
LMSC（LAN/ MAN Standards Committee，局域网/ 城域网标准委员会）。该委员会成立
于1980年2月，其任务就是制定局域网和城域网标准。
由于工作量较大，该委员会被细分成多个工作组（W orking Group），每个工作组负
责解决某个特定方面问题的标准。工作组也会被赋予一个编号（位于802编号的后面，中间
用点号隔开），故802.11代表802项目的第11个工作组 [3] ，专门负责制订无线局域网
（W ireless LAN）的介质访问控制协议（Medium Access Control，MAC）及物理层
（Physical Layer，PHY）技术规范。
和工作组划分类似，工作组内部还会细分为多个任务组（Task Group，TG），任务
是修改、更新标准的某个特定方面。TG的编号为英文字母，如a、b、c等。
提示 TG编号使用大小写字母，其含义不同，小写字母的编号代表该标准不能单独存
在。例如802.11b代表它是在802.11上进行的修订工作，其本身不能独立存在。而大写字母
的编号代表这是一种体系完备的独立标准，如802.1X是处理安全方面的一种独立标准。
802.11制定了无线网络技术的规范，其发展历经好几个版本。表3-1是IEEE 802.11各
版本的简单介绍 [4] 。
提示可从IEEE官方网站下载802.11-2012标准PDF全文（下载地址为
http:/ / standards.ieee.org/ about/ get/ 802/ 802.11.html），长达2793页，包含从802.11a
到802.11z各个版本（包括a、b、d、e、g、h、i、j、k、n、p、r、s、u、v、w、y、z）
所涉及的技术规范。
3.3 802.11无线网络技术
从本节开始，将介绍802.11涉及的无线网络技术。首先介绍OSI基本参考模型。
3.3.1 OSI基本参考模型及相关基本概念
1.OSI/ RM
ISO（International Organization for Standardization，国际标准化组织）和
IEC（International Electrotechnical Commission，国际电工技术委员会）于1983年
联合发布了ISO/ IEC 7498标准。该标准定义了著名的OSI/ RM
[5] （开放系统互联参考模
型，Open Systems Interconnection Reference Model）。
在OSI/ RM中，计算机网络体系结构被划分成七层，其名称和对应关系如图3-1所示。
图中绘制了OSI/ RM以及另外一个常用的网络体系TCP/ IP的结构。先来看OSI/ RM，它将网
络划分成七层，由上到下分别如下 [6] 。
·应用层（Application Layer）：应用层能与应用程序界面沟通以达到向用户展示的
目的。常见的协议有HTTP、HTTPS、FTP、SMTP等。其数据单位为
APDU（Application Protocol Data UNIT）。
·表示层（Presentation Layer）：表示层能为不同客户端提供数据和信息的语法转
换，使系统能解读成正确的数据，同时它还能提供压缩解压、加密解密等服务。例如不同格
式图像（如GIF、JPEG、TIFF等）的显示就是由位于表示层的协议来支持的。其数据单位
为PPDU（Presentation Protocol Data UNIT）。
图3-1 OSI RM及TCP/ IP结构
·会话层（Session Layer）：会话层用于为通信双方制定通信方式，创建和注销会话
（双方通信）等。常见的协议有ZIP、AppleTalk、SCP等。其数据单位为
SPDU（Session Protocol Data UNIT）。
·传输层（Transport Layer）：传输层用于控制数据流量，同时能进行调试及错误处
理，以确保通信顺利。发送端的传输层会为数据分组加上序号，以方便接收端把分组重组为
有用的数据或文件。传输层的常见协议有TCP、UDP等。其数据单位为TPDU（Transport
Protocol Data Unit）。
·网络层（Network Layer）：网络层为数据传送的目的地寻址，然后再选择一个传
送数据的最佳路线。网络层数据的单位为Packet或Datagram。常见的设备有路由器等。常
见协议有IP、IPv6。
·数据链路层（Data Link Layer）：在物理层提供比特流服务的基础上，建立相邻节
点之间的数据链路。通过差错控制提供数据帧（Frame）在信道上无差错的传输。数据链路
层在不可靠的物理介质上提供可靠的传输。该层的作用包括物理地址寻址、数据的成帧、流
量控制、数据的检错、重发等。数据链路层数据的单位为Frame（帧）。常见的设备有二层
交换机、网桥等。
·物理层（Physical Layer）：物理层定义了通信设备机械、电气、功能和过程等方面
的特性，用以建立、维护和拆除物理链路连接。物理层数据的单位为bit。
图3-1中左边所示为另外一个常用的网络体系，即TCP/ IP模型。对比图3-1中的两个模
型，我们可简单认为TCP/ IP Model是OSI/ RM的一个简化版本。
提示关于OSI/ RM的详细信息，请读者阅读本章参考资料[5]。
2.LLC和MAC子层
虽然ISO/ IEC 7498标准所定义的OSI/ RM只将网络划分为七层。但实际上每一层还可
划分为多个子层（Sub Layer）。所有这些子层中，最为人熟知的就是ISO/ IEC 8802 [7] 规
范划分Data Link Layer而得到的LLC（Logic Link Control Sub Layer）和
MAC（Medium Access Control Sub Layer）。它们的信息如图3-2所示。
图3-2 MAC和LLC子层
ISO/ IEC 8802将Data Link Layer划分成了两个子层。
·媒介访问控制子层（MAC Sub Layer）：该子层的目的是解决局域网（Local Area
Network，LAN）中共用信道的使用产生竞争时，如何分配信道的使用权问题。目前LAN
中常用的媒介访问控制方法是CSMA/ CD（争用型介质访问控制）。由于无线网络的特殊
性，MAC的控制方法略有不同。将在下文介绍相关内容。
·逻辑链路控制子层（LLC Sub Layer）：该子层实现了两个站点之间帧的交换，实
现端到端（源到目的），无差错的帧传输和应答功能及流量控制功能。
在Data Link层划分的这两个子层中，802.11只涉及MAC层。由于物理介质的不同，
无线和有线网络使用的MAC方法有较大差别，主要区别如下 [8] 。
·有线网络最常使用的方法（此处仅考虑以太网）是CSMA/ CD（Carrier Sense
Multiple Access/ Collision Detect，载波监听多路访问/ 冲突检测机制）。其主要工作原
理是：工作站发送数据前先监听信道是否空闲，若空闲则立即发送数据。并且工作站在发送
数据时，边发送边继续监听。若监听到冲突，则立即停止发送数据并等待一段随机时间，然
后再重新尝试发送。
·无线网络主要采用CSMA/ CA（Carrier Sense Multiple Access/ Collision
Avoidance，载波监听多路访问/ 冲突避免机制）方法。无线网络没有采用冲突检测方法的
原因是：如果要支持冲突检测，必须要求无线设备能一边接收数据信号一边传送数据信号，
而这种设计对无线网络设备来说性价比太低。另外，冲突检测要求边发送数据包边监听，一
旦有冲突则停止发送。很显然，这些因发送冲突而被中断的数据发送将会浪费不少的传输资
源。所以，802.11在CSMA/ CD基础上进行了一些调整，从而得到了CSMA/ CA方法。其主
要工作原理见下节内容。
注意 CSMA/ CA协议信道利用率低于CSMA/ CD协议信道利用率。信道利用率受传输
距离和空旷程度的影响，当距离远或者有障碍物影响时会存在隐藏终端问题，降低信道利用
率。在802.11b W LAN中，在1Mbps速率时最高信道利用率可达到90% ，而在11Mbps时最
高信道利用率只有65% 。
3.CSMA/ CA [8]
CSMA/ CA主要使用两种方法来避免碰撞。
·设备发送数据前，先监听无线链路状态是否空闲。为了避免发生冲突，当无线链路被
其他设备占用时，设备会随机为每一帧选择一段退避（backoff）时间，这样就能减少冲突
的发生。
·RTS-CTS握手。设备发送帧前，先发送一个很小的RTS（Request To Send）帧给
目标端，等待目标端回应CTS（Clear To Send）帧后才开始传送。此方式可以确保接下来
传送数据时，其他设备不会使用信道以避免冲突。由于RTS帧与CTS帧长度很小，使得整体
开销也较小。
我们通过图3-3来介绍RTS和CTS的作用。
图3-3 RTS/ CTS原理
如图3-3所示，以站A和站B之间传输数据为例，站B、站C、站E在站A的无线信号覆盖
的范围内，而站D不在其内。站A、站E、站D在站B的无线信号覆盖的范围内，但站C不在
其内。
如果站A要向站B发送数据，站A在发送数据帧之前，要先向站B发送一个请求发送帧
RTS。在RTS帧中会说明将要发送的数据帧的长度。站B收到RTS帧后就向站A回应一个允
许发送帧CTS。在CTS帧中也附上站A欲发送的数据帧的长度（从RTS帧中将此数据复制到
CTS帧中）。站A收到CTS帧后就可发送其数据帧了。
怎么保证其他站不会干扰站A和站B之间的数据传输呢？
·对于站C，站C处于站A的无线传输范围内，但不在站B的无线传输范围内。因此站C
能够收听到站A发送的RTS帧，但经过一小段时间后，站C收听不到站B发送的CTS帧。这
样，在站A向站B发送数据的同时，站C也可以发送自己的数据而不会干扰站B接收数据（注
意，站C收听不到站B的信号表明，站B也收不听到站C的信号）。
·对于站D，站D收听不到站A发送的RTS帧，但能收听到站B发送的CTS帧。因此，站
D在收到站B发送的CTS帧后，应在站B随后接收数据帧的时间内关闭数据发送操作，以避
免干扰站B接收自A站发来的数据。
·对于站E，它能收到RTS帧和CTS帧，因此，站E在站A发送数据帧的整个过程中不
能发送数据。
总体而言，使用RTS和CTS帧会使整个网络的效率下降。但由于这两种控制帧都很短
（它们的长度分别为20和14字节）。而802.11数据帧则最长可达2346字节，相比之下的开
销并不算大。相反，若不使用这种控制帧，则一旦发生冲突而导致数据帧重发，则浪费的时
间就更大。
另外，802.11提供了三种情况供用户选择以处理。
·使用RTS和CTS帧。
·当数据帧的长度超过某一数值时才使用RTS和CTS帧。
·不使用RTS和CTS帧。
尽管协议经过了精心设计，但冲突仍然会发生。例如，站B和站C同时向站A发送RTS
帧。这两个RTS帧发生冲突后，使得站A收不到正确的RTS帧因而站A就不会发送后续的
CTS帧。这时，站B和站C像以太网发生冲突那样，各自随机地推迟一段时间后重新发送其
RTS帧。
提示根据802.11协议，CSMA/ CA具体运作时由协调功能（Coordination
Function，CF）来控制。协议规定有四种不同的协调功能，分别是DCF（Distributed
CF，分布式协调功能）、基于DCF之上的PCF（Point CF）、HCF（Hybrid CF，混合
型协调功能）以及用于Mesh网络的MCF（Mesh CF）。由于无线网络是共享介质，所以协
调功能的目的就是用于控制各个无线网络设备使用无线媒介的时机以避免冲突发生。形象点
说，这就好比在一个会议室里，所有人都可以发言，但如果多个人同时发言又不知道谁和谁
在说话。所以，每个打算发言的人都需要检查当前发言的情况。本章不详细介绍802.11中
CF相关的内容。感兴趣的读者可阅读802.11协议第9节"MAC sublayer functional
description"。
另外，规范还定义了基于竞争的服务（contention-based service，使用DCF进行数
据交换）和基于无竞争的服务（contention-free service，使用PCF进行数据交换），本
章也不讨论它们。
4.MAC层Service及其他概念 [5][9]
ISO/ IEC 7498及相关的一些标准文档除了对网络体系进行层次划分外，还定义了层和
层之间交互方式及其他一些基本组件。它们可用图3-4来表示。
图3-4 MAC Entity、Service和Clients
图3-4绘制了MAC层相关的组件及交互方式。
·协议规定了每一层所提供的功能，这些功能统一用Service来表示。MAC层为上层提
供MAC Service。从Java编程角度来看，就好比定义了一个名为MAC Service的Java
Package。
·每一层内部有数个Entity。Entity代表封装了一组功能的模块。上面提到的Service
就是由Entity提供的。根据OSI/ RM的层次关系，第N层为第N+1层提供服务。所以，MAC
Entity对上一层提供MAC Service。从Java编程角度来看，MAC Entity就好比MAC
Service Package中定义的类，不同的Entity代表该Package中实现不同的功能类。一个
Package中的Entity可以相互调用以完成某个功能。
·第N+1层要使用第N层服务时，必须经由Service Access Point来完成。MAC的
Service必须借由MSAP（MAC Service Access Point）来访问。
根据上面的介绍，Entity定义了一个类，其中是否定义了相应的功能函数呢？在标准文
档中，和功能函数对应的术语是primitives（原语）及它们的parameters（参数）。图3-
4列举了MAC Service的两个重要函数，分别是如下。
·M_UNITDATA.request：Client调用该原语发送数据。该原语的参数是
destination_address（目标地址）、source_address（源地址）、MSDU（MAC
Service Data Unit，即数据）、priority（优先级）。
·M_UNITDATA.indication：当位于远端机器的MAC层收到上面发送的数据后，将
通过indication原语通知上一层以处理该数据。
提示关于MAC层的服务详细定义，请读者阅读3.3.5节MAC服务定义内容。
值得指出的是，规范只是从逻辑上定义了上述内容，它并没有指定具体的实现。关于
MAC Service的详细定义，读者可阅读本章参考资料[10]，即ISO/ IEC 15802-1。
协议还定义了SDU和PDU两个概念。当上一层调用MAC的request原语时，会把要发
送的数据传给MAC层。这个数据被称为MSDU。对MAC层来说，MSDU其实就是MAC要
发送的数据，即载荷（Payload）。MAC层处理Payload时还会封装MAC层自己的一些头
信息。这些信息和MSDU共同构成了MAC层的Protocol Data Unit（简写为MPDU）。从
OSI/ RM角度来看，经过N+1层封装后的数据是（N+1）-PDU。该数据传递给N层去处理
时，对N层来说就是（N）-SDU。N层封装这个SDU后就变成自己的（N）-PDU了。
5.MIB [11]
在阅读802.11相关规范时，经常会碰到MIB（Management Information Base，管理
信息库）。MIB是一个虚拟的数据库，里边存储了一些设备信息供查询和修改。MIB常见的
使用之处是网管利用SNMP协议管理远程主机、路由器等。
MIB内部采用树形结构来管理其数据。内部的每一个管理条目（Entry）通过
OID（Object IDentifier）来访问。MIB定义了Entry的属性和可取的值。由于属性及其
可取值的定义采用了与具体编程语言无关的方式，所以一个MIB库可以很轻松地通过编译器
（compiler）将其转换成对应的编程语言源码文件。
提示 MIB的定义比较烦琐，可阅读参考资料[11]中的资料列表以学习完整的MIB知
识。
从笔者角度来看，对802.11来说，MIB就是定义的一组属性。802.11定义的MIB属性
在http:/ / www.ieee802.org/ 11/ 802.11mib.txt中。下载后将得到一个802.11mib.txt文
件。可通过JMIBBrowser ① 工具加载并查看其内容，如图3-5所示。
图3-5 802.11 MIB内容
首先点击图3-5所示左下角的"Load MIB"按钮以加载802.11mib.txt文件，然后查看
802.11mib定义的一些属性。如图3-5所示，左侧显示当前查看的dot11MACAddress的条
目。右侧显示该条目的信息，Access中的"read-only"表示只读，Description表示该条目
的意义。
802.11mib定义了一个较全的属性集合，一般而言，设备可能只支持其中一部分属性。
图3-6所示为Note 2上wlan0设备的MIB信息截图（由于篇幅问题只包含部分Note 2 wlan0
设备的MIB属性）。
以第一条属性dot11RSNAOptionImplemented为例，其在802.11mib.txt的定义如图
3-7所示。
相比直接浏览802.11mib.txt文本文件而言，利用JMIBBrowser工具查看属性会更加
方便和直观一些。
图3-6 Note 2 wlan0设备的MIB属性
图3-7 dot11RSNAOptionImplemented属性内容
提示以后分析wpa_supplicant源码时，会碰到802.11mib定义的属性，建议在阅读
本节时下载相关文件和工具程序。另外，以上内容涉及的知识点是读者以后阅读802.11协议
时必然会碰到的。由于802.11协议引用的参考资料非常多，故本节整理了其中最基础的知识
点，请读者务必认真阅读本节内容。
① 用Java语言编写的小工具，可利用SNMP协议查看和设置指定设备MIB，下载地址为
http:/ / sourceforge.net/ projects/ jmibbrowser/ 。
3.3.2 802.11知识点导读
802.11规范全称为《Part 11：W ireless LAN Medium Access
Control（MAC）and Physical Layer（PHY）Specifications》。从其标题可
知，802.11规范定义了无线局域网中MAC层和PHY层的技术标准。
2012年版的802.11协议全文共2793页，包含20小节（clause），23个附录（A～
W ）。图3-8所示为802.11协议原文目录的一部分。
图3-8 802.11协议原文目录
由图3-8可知802.11协议内容非常丰富。读者可尝试阅读该文档，但估计很快会发现这
将是一件非常枯燥和令人头疼的事情。主要原因是此规范类似于手册，它非常重视细节的精
准，但各技术点前后逻辑上的连贯性较差，使得读者极难将散落在协议中各个角落的技术点
整理出一个内容有序，难度由浅入深的核心知识框架来。
基于上述原因，本章后续小节将从以下几个方面介绍802.11规范中的一些核心内容。
·3.3.3节介绍802.11中的物理组件和网络结构。
·3.3.4节将在物理组件和网络结构基础上，介绍802.11为无线网络所定义的服务。了
解这些服务对我们从整体上理解无线网络的功能有重要意义。
·3.3.5节介绍802.11 MAC服务和帧方面的内容。这部分知识比较具体，相信读者理解
起来没有问题。
·3.3.6节介绍MAC层管理实体方面的内容。清楚这部分内容有助于读者理解后续有关
Linux W i-Fi编程的知识。
·3.3.7节介绍802.11安全性方面的知识。
提示篇幅原因，本书不可能囊括规范的所有内容。但相信读者在理解本节内容的基础
上，能够轻松开展更加深入的研究。另外，为帮助读者理解规范，本章会在重要知识点之处
添加“规范阅读提示”。
由于802.11物理层涉及大量和无线电、信号处理相关的知识。这些知识不仅内容枯燥繁
杂，而且对软件工程师来说并无太大意义，故本章不做介绍。愿意深入研究的读者可阅读相
关资料。
3.3.3 802.11组件
本节介绍802.11规范中的物理组件和相关网络结构。首先来看无线网络中的物理组件。
1.物理组件 [12]
802.11无线网络包含四种主要物理组件，如下所示。
·W M（W ireless Medium，无线媒介）：其本意指能传送无线MAC帧数据的物理
层。规范最早定义了射频和红外两种物理层，但目前使用最多的是射频物理层。
·STA（Station，工作站）：其英文定义是"A logical entity that is asingly
addressable instance of aMAC and PHY interface to the W M"。通俗点说，STA就是
指携带无线网络接口卡（即无线网卡）的设备，例如笔记本、智能手机等。另外，无线网卡
和有线网卡的MAC地址均分配自同一个地址池以确保其唯一性。
·AP（Access Point，接入点）：其原文定义是"An entity that contains one STA
and provides access to the distribution services，via the W M for associated
STAs"。由其定义可知，AP本身也是一个STA，只不过它还能为那些已经关联的
（associated）STA提供分布式服务（Distribution Service，DS）。什么是DS呢？请读
者阅读下文。
·DS（Distribution System，分布式系统）：其英文定义为"A system used to
interconnect aset of basic service sets（BSSs）and integrated local area
networks（LANs）to create an extended service set（ESS）“。DS的定义涉及BSS、
ESS等无线网络架构，其解释见下文。
上述四个物理组件如图3-9所示。其中，最难解释清楚的就是DS。笔者在仔细阅读规范
后，感觉其对DS的解释并不直观。此处将列举一个常见的应用场景以帮助读者理解。
图3-9 802.11四大主要物理组件
一般家用无线路由器一端通过有线接入互联网，另一端通过天线提供无线网络。打开
Android手机上的W i-Fi功能，并成功连接到此无线路由器提供的无线网络（假设其网络名
为"TP-LINK_1F9C5E”，可在路由器中设置）时，我们将得到：
·路由器一端通过有线接入互联网，故可认为它整合（integrate）了LAN。
·不论路由器是否接入有线网络（即本例中的互联网），手机（扮演STA的角色）和路
由器（扮演AP的角色）之间建立了一个小的无线网络。该无线网络的覆盖范围由AP即路由
器决定。这个小网络就是一个BSS。另外，定义中提及的ESS是对BSS的扩展。一个ESS可
包含一或多个BSS。在本例中，ESS对应的ID就是"TP-LINK_1F9C5E"，即我们为路由器
设置的网络名。
上述内容中将BSS和LAN结合到一起以构成一个ESS的就是DS。虽然规范中并未明示
DS到底是什么，但绝大部分情况下，DS是指有线网络（通过它可以接入互联网）。后文将
介绍DS所提供的分布式服务（即DSS）。现在对读者来说，更重要的概念是其中和无线网
络架构相关的BSS和ESS等。这部分内容将在下节介绍。
规范阅读提示
1）上文介绍的AP、STA、DS的定义都来自于802.11的3.1节。该节所列的定义是最精
确的。以DS为例，此节所定义的DS涉及和有线网络的结合。但规范中其他关于DS的说明
均未明示是否一定要和LAN结合。
2）关于STA，其定义只说明它是一个可"singly addressable"的实体，而没有说明其
对应的功能。所以，读者会发现AP也是一个STA。另外还有提供QoS（Quality of
Service）的STA。除此之外，从可移动性的角度来看，还有Mobile STA和Portable STA
之分。Portable STA虽然可以移动，但只在固定地点使用（例如AP就是一个典型的
Portable STA）。而Mobile STA表示那些只要在W i-Fi覆盖范围内，都可以使用的
STA（例如手机、平板电脑等设备）。
2.无线网络的构建 [12]
有了上节所述的物理组件，现在就可以搭建由它们构成的无线网络了。802.11规范中，
基本服务集（Basic Service Set，BSS）是整个无线网络的基本构建组件（Basic
Building Block）。如图3-10所示，BSS有两种类型。
·独立型BSS（Independent BSS）：这种类型的BSS不需要AP参与。各STA之间可
直接交互。这种网络也叫ad-hoc BSS（一般译为自组网络或对等网络）。
·基础结构型BSS（Infrastructure BSS）：所有STA之间的交互必须经过AP。AP
是基础结构型BSS的中控台。这也是家庭或工作中最常见的网络架构。在这种网络中，一个
STA必须完成诸如关联、授权等步骤后才能加入某个BSS。注意，一个STA一次只能属于
一个BSS。
图3-10 BSS的两种方式
提示 Independent BSS缩写为IBSS。而Infrastructure BSS没有对应的缩写。不
过，一般用BSS代表Infrastructure BSS。根据前文所述，AP也是一个STA，但此处STA
和AP显然是两个不同的设备。
由图3-10中BSS的结构可知，其网络覆盖范围由该BSS中的AP决定。在某些情况下，
需要几个BSS联合工作以构建一个覆盖面更大的网络，这就是一个ESS（Extended
Service Set，扩展服务集），如图3-11所示。
图3-11 ESS示意图
ESS在规范中的定义是"A set of one or one interconnected BSSs that appears as
asingle BSS to the LLC layer at any STA associated with one of those BSSs"。此
定义包含几个关键点。
一个ESS包含一或多个BSS。如图3-11所示的BSS1和BSS2。
BSS1和BSS2本来各自组成了自己的小网络。但在ESS结构中，它们在逻辑上又构成了
一个更大的BSS。这意味着最初在BSS2中使用的STA4（利用STA3，即BSS2中的AP上
网）能跑到BSS1的范围内，利用它的AP（即STA2）上网而不用做任何无线网络切换之类
的操作。此场景在手机通信领域很常见，例如在移动的汽车上打电话，此时手机就会根据情
况在物理位置不同的基站间切换语音数据传输而不影响通话。
注意 ESS中的BSS拥有相同的SSID（Service Set Identification，详细内容见下
文），并且彼此之间协同工作。这和目前随着W i-Fi技术的推广，家庭和工作环境中存在多
个无线网络（即存在多个ESS）的情况有本质不同。在多个ESS情况下，用户必须手动选择
才能切换到不同的ESS。由于笔者日常工作和生活中，ESS只包含一个BSS，当某个AP停
机时，笔者就得手动切换到其他无线网络中去了。另外，切换相关的知识点属于
Roaming（漫游）范畴，读者可阅读Secure Roaming in 802.11 Networks一书来了解相
关细节。
上述网络都有Identification，分别如下。
·BSSID（BSS Identification）：每一个BSS都有自己的唯一编号。在基础结构型
网络中，BSSID就是AP的MAC地址，该MAC地址是真实的地址。IBSS中，其BSSID也是
一个MAC地址，不过这个MAC地址是随机生成的。
·SSID（Service Set Identification）：一般而言，BSSID会和一个SSID关联。
BSSID是MAC地址，而SSID就是网络名。网络名往往是一个可读字符串，因为网络名比
MAC地址更方便人们记忆。
ESS包括一到多个BSS，而它对外看起来就像一个BSS。所以，对ESS的编号就由
SSID来表达。只要设置其内部BSS的SSID为同一个名称即可。一般情况下，ESS的SSID
就是其网络名（network name）。
规范阅读提示
1）上述网络结构中，并未提及如何与有线网络（LAN）的整合。规范中其实还定义了
一个名为portal的逻辑模块（logical component）用于将W LAN（W ireless LAN）和
LAN结合起来。由于W LAN和LAN使用的MAC帧格式不同，所以portal的功能类似翻译，
它在W LAN和LAN间转换MAC帧数据。目前，portal的功能由AP实现。
2）规范中还定义了QoS BSS。这主要为了在W LAN中支持那些对QoS有要求的程序。
由于无线网络本身固有的特性，W LAN中的QoS实现比较复杂，效果也不如LAN中的
QoS。初学者可先不接触这部分内容。
3.3.4 802.11 Service介绍 [13]
本节对802.11规范定义的和数据传输相关的服务进行介绍。规范在各服务的逻辑联系上
往往一句带过，使得很难把它们之间的关系搞清楚。对数据传输来说，其逻辑关系如下。
·DSS用于完成数据的传输。
·由于有线和无线网络的差异性，当数据需要传输到有线网络时候，就通过
Integration Service在二者之间进行转换。
·由于存在transition，为了保证DSS能找到对应的STA，所以就存在association、
reassociation服务。
·当STA不再使用DSS时，就通过disassociation服务离开DS。
802.11规范定义了很多Service。Service就是无线网络中对应模块应该具有的功能。
本节内容主要来自802.11规范4.4节到4.8节，集中介绍了802.11无线网络应该提供的
Service。
1.802.11 Service的分类
从模块考虑，802.11中的Service分为两大类别（Category），分别如下。
·SS（Station Service）：它是STA应该具有的功能。
·DSS（Distribution System Service）：它指明DS应具有的功能。
前文也提到过DS，其定义比较模糊。规范中还特别强调说802.11并不指明DS的具体实
现，它只是从逻辑上指明DS应该具有的功能，也就是DSS。
提示虽然规范未说明DS到底是什么，但目前普遍认为DS就是指以太网。
SS和DSS包含一些相同的服务。这是因为无线网络中，SS和DSS将协同工作。以数据
传输为例，STA和DS都需要支持MAC帧数据的收发。所以二者必然包含类似的服务。另
外，802.11中的Service还可从其所代表的功能出发进行划分以得到如下类别。
·6种Service用于支持802.11 MAC层的数据传输（规范定义为MAC Service Data
Unit Delivery）。
·3种Service用于控制802.11 LAN的访问控制（Access Control）和数据机密性
（Data Confidentiality）。
·2种Service用于频谱管理（Spectrum Management）。
·1种Service用于支持QoS。
·1种Service用于支持时间同步。
·1种Service用于无线电测量（Radio Measurement）。
接下来，本章将从功能划分角度出发来介绍其中所涉及的服务。
2.数据传输相关服务
毋庸置疑的是，无线网络最重要的一个功能就是传输数据了。对802.11来说，此处的数
据就是无线MAC帧数据。规范一共定义了6种Service支持数据传输。其中，QoS traffic
Scheduling服务和QoS有关，主要目的是满足QoS的要求，本书不对这部分内容进行介
绍。
（1）Distribution Service和Integration Service
本节介绍数据传输服务中的前两位，Distribution Service（DS，分布式服务）和
Integration Service（IS，整合服务）。前文也提到过DSS，其目的其实非常简单。只要
STA传送任何数据都会使用这项服务。当AP接收到数据帧后，就会使用该服务将帧传输到
目的地。任何使用接入点的通信都会通过该服务进行传播。包括关联至同一个AP的两个
STA之间的相互通信。规范还特别绘制了示意图来展示DS，如图3-12所示。
·BSS1中的STA1想发送数据给BSS2中的STA4。
·STA1先要把数据传输给BSS1中的AP，即STA2。
·STA2通过使用DSS将数据传输给DS。
·DS根据相关的信息找到位于BSS2的AP，即STA3。
·STA3把数据传递给STA4。
图3-12 DS示意图
在上述过程中，DSS的作用就是把来自STA2的数据传递到正确的STA3。规范并未说
明DS如何实现DSS，它只要求数据发送端传递足够的参数使得STA3能被正确找到。
整合服务的使用也包含在图3-12中。当DSS发现数据的目的端是LAN时，就需要把数
据传给Portal了。这时候，DS就会使用IS将无线数据进行必要的转换，以发送到LAN中
去。
同样，规范并未指明IS的具体实现，不过读者可知家用的无线路由器就实现了该功能。
（2）association、reassociation、disassociation服务
前文曾提到，规范要求使用DSS时，必须提供足够的信息给它以保证数据能传输成功。
这些足够的信息就是由association（关联）、reassociation（重新关联）和
disassociation（取消关联）服务提供的。这些服务是如何帮助DSS的呢？回答这个问题
前，先介绍Transition Type。
Transition Type对STA在无线网络中移动的类型进行了分类，分别如下。
·No-Transition：即没有移动。它包括固定不动的情况以及在某个AP无线覆盖范围
内移动。
·BSS-Transition：即从ESS中的一个BSS切换到另一个BSS。根据前面对ESS的介
绍，我们希望这种移动不影响网络的使用。当然，要真正实现无缝切换，需要做一些其他工
作。这部分内容由规范中的"Fast BSS Transition"一节描述。
·ESS-Transition：从一个ESS中的BSS切换到位于另外一个ESS的BSS。这种情况
极有可能导致网络切换，影响用户使用。
当DS传输数据时，DSS需要知道和哪个AP建立联系。所以，规范要求STA在传输数据
前，必须要和一个AP建立关联关系，这就需要使用association服务。关联服务的目的在于
为AP和STA建立一种映射关系。例如当图3-12中的DS向BSS1发送数据时，它得知道
STA1和STA2通过association服务建立了一种映射，这样数据才能传递给STA1。
在同一时刻，一个STA只能和一个AP建立关联关系。但AP可和多个STA建立关联关
系。关联服务回答了这样一个问题：哪个AP为STA X服务？
当STA进行transition的时候（如BSS Transition），它就需要使用reassociation服
务了。因为之前它和BSS1建立了关联关系，此后它需要和BSS2建立关联关系。这时就可以
使用reassociation服务来完成该功能。reassociation服务只能由STA发起。
当STA不需要使用DSS，或者AP不再为某个STA服务时，就需要调用disassociation
服务。这样STA就不能再使用DSS传输数据了。相比关联和重新关联，STA和AP都可以调
用取消关联服务。
提示随着W i-Fi安全要求的提高，上述场景在强健安全网络（Robust Security
Network）中将有较大不同。
规范阅读提示
1）上述内容在RSN中大有不同。RSN主要为了增强W LAN的数据加密和认证性能，并
且针对W EP加密机制的各种缺陷做了多方面的改进。关于安全方面的内容，我们留待后文
再介绍。
2）介绍Service的时候，规范中还有一段对MAC帧类型进行了非常简单的介绍，即
Service的具体调用是通过发送不同的MAC帧来触发的。规范中MAC帧分为三大类型，分
别是data（数据帧）、management（管理帧）和control（控制帧）。其中和service直
接相关的是management帧，而control帧用于帮助传输data和management帧。关于
MAC帧的详细内容在3.3.5节。
3.访问控制和数据机密性相关服务
访问控制和数据机密性（Access Control and Data Confidentiality）包括三个服
务。其主要目的是解决无线网络中安全防护相关的工作。相比有线网络而言，安全性是无线
网络中非常重要的一部分。以访问控制为例，在有线网络中，例如你去一家公司参观，只有
在经过对方同意的情况下，才能使用有线上网。有线网络控制由网管或相关人员实施。而无
线网络中，只要你在该公司内部无线网络的覆盖范围内，都可以接入此网络。很明显，这时
就需要对无线网络实施访问控制了。
在访问控制的进一步上，数据机密性用于对数据的内容进行加密保护。因为即使实施了
访问控制，由于传输的数据还是通过无线网络，那么理论上无线网络覆盖内的所有人都可以
接收到该数据。如果不加密的话，数据内容就能被不相关的人窥窃了。
规范定义了三个服务用于处理安全性，分别如下。
·Authentication和Deauthentication：这两个服务用于Access Control，译为身
份验证以及解除身份验证。
·Confidentiality：原本称为私密性（privacy）服务，后来对这部分内容实施了加
强。目前规范中提到的数据加密方法有W EP、TKIP、CCMP。
4.频谱管理服务
频谱管理服务包括TPC（Transmit Power Control，传输功率控制）服务和
DFS（Dynamic Frequency Selection，动态频率选择）服务。这两个服务的目的在于满
足不同管制机构对无线电资源使用时的一些特定要求。
对TPC而言，当无线设备工作在5GHz频段时，必须限制其各信道的最大发射功率，以
避免干扰卫星服务。其主要特点包括：
·支持STA根据功率要求选择和不同的AP关联。
·根据管制机构的要求，设定当前信道的最大传输功率。
·根据传输过程中的损耗等信息来自动调整传输功率。
和TPC类似，DFS也是针对那些工作在5GHz频段的无线设备，使其能够根据情况动态
选择传输信道以避免干扰雷达系统。DFS的主要特点是针对信道（即不同频率），包括：
·根据STA支持的信道情况去选择合适的AP。
·静默某个信道，以支持雷达的使用该信道。
·在使用某个信道前，先检查是否有雷达系统已经使用该信道了。如果有，则必须停止
在该信道工作以避免干扰雷达。
5.QoS和时间同步服务
规范对这两个服务的介绍不多，故本书也不展开详细讨论。简单来说，802.11规范支持
使用任何一种合适的QoS机制以预留一些资源，例如RRP（Resource Reservation
Protocol）。
时间同步服务目的是支持一些对同步性要求较高的应用（如视音频播放等）。这些应用
使用的同步方式可基于规范中定义的STA之间时间同步（Timing Synchronization
Function，TSF）机制之上。
提示 QoS来源于802.11e。
6.无线电测量服务
无线电测量（Radio Measurement）服务所提供的功能如下。
·为上层应用提供查询无线电相关信息的接口。
·通过无线电测量来获取周围AP的信息。
·能够在所支持的信道上进行无线电测量。
提示无线电测量服务来源于802.11k。
7.802.11 Service相关知识总结
本节对802.11提供的服务进行了基本介绍。服务其实是从无线网络所提供的功能的角度
来考察无线网络技术的。所有服务中最关键的三个如下。
·数据传输服务：这是无线网络的一个主要功能。
·安全方面的服务：由于无线网络的特殊性，所以安全性是它必须要考虑的问题。
·无线电测量服务：无线电测量用于无线网络组建。例如STA必须通过该服务去发现周
围的AP。
提示笔者认为，上述服务从文字描述上看起来并不复杂。但对软件工程师来说，很难
把上述知识和编程/ 代码等联系起来。不过没有关系，下文的内容将更加具体。尤其是3.3.6
节关于MLME（MAC Layer Management Entity）的介绍，其描述方式就很接近编程中
的API介绍。
3.3.5 802.11 MAC服务和帧
本节将向读者介绍802.11中MAC服务以及MAC帧方面的内容。首先来看MAC服务。
1.MAC服务定义 [14]
根据3.3.1节所示，MAC层定义了一些Service用于为上层LLC提供服务。其
中，802.11中定义的MAC提供三种服务，分别如下。
·MA-UNITDATA.request：供LLC层发送数据。
·MA-UNITDATA.indication：通知LLC层进行数据接收。
·MA-UNITDATA-STATUS.indication：通知LLC层自己（即MAC层）的状态。
规范中这三种服务的定义和编程语言中的函数非常像。根据前文所述，服务在规范中被
称为原语（primitive），每个服务有特定的参数（parameter）。另外，规范对每条原语
都做了非常详细的解释，例如原语使用场景（从编程角度看就是介绍什么时候用这些
API），MAC层如何处理这些原语（从编程角度看即描述应该如何实现这些API）。
（1）MA-UNITDATA.request服务
request用于发送数据，其定义如下所示。
MA-UNITDATA.request(
source address // 指定本次数据发送端的MAC地址
destination address // 指定接收端的MAC地址。可以是组播或广播地址
routing information // 路由信息。对于802.11来说，该值为null（表示该值没有作用）
data // MSDU，即上层需要发送的数据。对802.11来说，其大小不能超过2304字节
priority // priority和service class的解释见下文
service class
)
request原语中，除priority和service class参数外，其他都很容易理解。而priority
和service class参数与QoS有关系。
·priority的取值为0～15的整数。对于非QoS相关的操作，其取值为Contention和
ContentionFree。802.11中，QoS设置了不同的用户优先级（User Priority，UP）。显
然，UP高的数据将优先得到发送。Priority参数和QoS中的其他参数一起决定发送数据的
优先级。
·service class的取值也针对是否为QoS而有所不同。对于非QoS，取值可为
ReorderableGroupAddressed或StrictlyOdered。这两个都和数据发送时是否重排
（reorder）发送次序有关。非QoS情况下，STA发送数据时并不会主动去调整发送次序。
而QoS情况下，很明显那些UP较高的数据见得到优先处理。但对于组播数据，发送者可以
设置service class为ReorderableGroupAddressed进行次序调整。
对request原语来说，当LLC需要发送数据时，就会调用request。MAC层需要检查参
数是否正确。如果不正确，将通过其他原语通知LLC层，否则将启动数据发送流程。
（2）MA-UNITDATA.indication服务
下面来看MAC层收到数据后用于通知LLC层的原语indication，其定义如下。
MA-UNITDATA.indication(
source address // 代表数据源MAC地址。其值取值MAC帧中的SA（关于MAC帧格式详情见后文）
destination address // 代表目标MAC地址，取自MAC帧中的DA，可以是组播地址
routing information // 值为null
data // MAC帧数据
reception status // 表示接收状态，例如成功或失败。对802.11来说，该状态永远返回success
// MAC层会丢弃那些错误的数据包
priority // 和request的取值略有不同，此处略过
service class
)
802.11中，indication只有在MAC层收到格式完整、安全校验无误及没有其他错误的
数据包时才会被调用以通知LLC层。
（3）MA-UNITDATA-STATUS.indication服务
STATUS.indication用于向LLC层返回对应request原语的处理情况。其原型如下。
MA-UNITDATA-STATUS.indication(
// source和destination address和对应request的前两个参数一样
source address
destination address
transmission status // 返回request的处理情况，详情见下文
provided priority // 只有status返回成功，该参数才有意义。其值和调用request发送数据时的值一致
provided service class // 只有status返回成功，该参数才有意义
)
indication最关键的一个参数是transmission status，可以是以下值。
·Successful：代表对应request发送数据成功。
·Undeliverable：数据无法发送。其原因有数据超长（excessive data length）、
在request时指定了routing information（non-null source routing）、不支持的
priority和service class、没有BSS（no BSS available）、没有key进行加密（cannot
encrypt with anull key）等。
提示本节对应于规范的第5节"MAC service definition"。和前面内容相比，本节内
容更贴近于代码实现，当然也就更符合程序员的“审美观”。
接下来介绍和MAC帧相关的内容。
2.MAC帧 [15][16][17]
802.11 MAC帧格式如图3-13所示。
图3-13 802.11 MAC帧格式
由图3-13可知，MAC帧由以下三个基本域组成。
·MAC Header：包括帧控制（Frame Control）、时长（Duration）、地址
（Address）等。注意，每个方框上面的数字表示该域占据的字节数。例如Frame Control
需要2字节。
·Frame Body：代表数据域。这部分内容的长度可变，其具体存储的内容由帧类型
（type）和子类型（sub type）决定。
·FCS：（Frame Check Sequence，帧校验序列）用于保障帧数据完整性。
规范阅读提示
1）关于MAC帧的格式。规范中还指出，如果是QoS数据帧，还需要附加QoS Control
字段。如果是HT（High Throughput，一种用于提高无线网络传输速率的技术）数据帧，
还需要附加HT Control字段。
2）关于Frame body长度。规范中指出其长度是7951字节，它和Aggregate-
MPDU（MAC报文聚合功能）以及HT有关。本文不拟讨论相关内容。故此处采用2312字
节。
下面分别介绍MAC帧头中几个重要的域，首先是Frame Control域。
（1）Frame Control域
Frame Control域共2字节16位，其具体字段划分如图3-14所示。
图3-14 Frame Control域的组成
·Protocol Version：代表802.11 MAC帧的版本号。目前的值是0。
·Type和Subtype：这两个字段用于指明MAC帧的类型。802.11中MAC帧可划分为
三种类型，分别是control、data和management，每种类型的帧用于完成不同功能。详情
见下文。
·To DS和From DS：只用在数据类型的帧中。其意义见下文。
·More Fragments：表明数据是否分片。只支持data和management帧类型。
·Retry：如果该值为1，表明是重传包。
·Power Management：表明发送该帧的STA处于活跃模式还是处于省电模式。
·More Data：和省电模式有关。AP会为那些处于省电模式下的STA缓冲一些数据
帧，而STA会定时查询是否有数据要接收。该参数表示AP中还有缓冲的数据帧。如果该值
为0，表明STA已经接收完数据帧了（下节将介绍省电模式相关的内容）。
·Protected Frame：表明数据是否加密。
·Order：指明接收端必须按顺序处理该帧。
Type和Subtype的含义如表3-2所示。其中仅列出了部分Type和Subtype的取值。
㈠本书将在第7章详细介绍Action帧。
From DS和To DS的取值如表3-3所示。
扩展阅读省电模式 [18]
无线网络的使用者常见于笔记本电脑、智能手机等设备，它们最大的一个特点就是能够
移动（无线技术的一个重要目的就是摆脱各种连接线的缠绕）。无线带来便捷的同时也引入
了另外一个突出问题，即电量消耗。在当前电池技术还没有明显进步的现实情况下，802.11
规范对电源管理也下了一番苦功。
规范为STA定义了两种和电源相关的状态，分别是Active模式和PS（Power Save）
模式。处于PS模式下，无线设备将关闭收发器（transceiver）以节省电力。
STA为了节电而关闭数据收发无可厚非，怎么保证数据传输的连贯性呢？下面讨论基础
结构型网络中省电模式的知识。在这种网络中，规范规定AP为了保证数据传输的连贯性，
其有两个重要工作。
1）AP需要了解和它关联的STA的电源管理状态。当某个STA进入PS状态后，AP就要
做好准备以缓存发给该STA的数据帧。一旦STA醒来并进入Active模式，AP就需要将这些
缓存的数据发送给该STA。注意，AP无须PS模式，因为绝大多数情况下，AP是由外部电
源供电（如无线路由器）。在AP中，每个和其关联的STA都会被分配一个
AID（Association ID）。
2）AP需要定时发送自己的数据缓存状态。因为STA也会定期接收信息（相比发送数据
而言，开启接收器所消耗的电力要小）。一旦STA从AP定时发送的数据缓存状态中了解到
它还有未收的数据，STA则会进入Active模式并通过PS-POLL控制帧来接收它们。
现在来看MAC帧中Power Management的取值情况。
·对于AP不缓存的管理帧，PM字段无用。
·对于AP发送的帧，PM字段无用。
·STA发送给还未与之关联的AP的帧中，PM字段无用。
·其他情况下，PM为1表示STA将进入PS状态，否则将进入Active状态。
配合PM使用的字段就是More Data。根据前文介绍，STA通过PS-POLL来获取AP端
为其缓存的数据帧。一次PS-POLL只能获取一个缓存帧。STA怎么知道缓存数据都获取完
了呢？原来More Data值为1表示还有缓存帧，否则为0。虽然MAC帧中没有字段说明AP缓
存了多少帧，但通过简单的0/ 1来标示是否还有剩余缓存帧也不失为一种好方法。
提示规范中的PS处理比较复杂，建议阅读参考资料[18]。
（2）Duration/ ID域
Duration/ ID域占2字节共16位，其具体含义根据Type和Subtype的不同而变化，不过
大体就两种，分别代表ID和Duration。
·对于PS-POLL帧，该域表示AID的值。其中最后2位必须为1，而前14位取值为1～
2007。这就是该域取名ID之意。
·对于其他帧，代表离下一帧到来还有多长时间，单位是微秒。这就是该域取名
Duration之意。
注意 Duration的用法和CSMA/ CA的具体实现有关。本章不对它进行详细讨论，可
阅读参考资料[8]。
（3）Address域
讲解Address域的用法之前，先介绍MAC地址相关的知识。根据IEEE 802.3 [19] 协
议，MAC地址有如下特点。
·MAC地址可用6字节的十六进制来表示，如笔者网卡的MAC地址为1C-6F-65-8C-
47-D1。
·MAC地址的组成包括两个部分。0～23位是厂商向IETF等机构申请用来标识厂商的
代码，也称为“组织唯一标识符”（Organizationally Unique Identifier，OUI）。后24
位是各个厂商制造的所有网卡的一个唯一编号。
·第48位用于表示这个地址是组播地址还是单播地址。如果这一位是0，表示此MAC地
址是单播地址；如果这位是1，表示此MAC地址是组播地址。例如01-XX-XX-XX-XX-XX
为组播地址。另外，如果地址全为1，例如FF-FF-FF-FF-FF-FF，则为MAC广播地址。
·第47位表示该MAC地址是全球唯一的还是本地唯一。故该位也称为G/ L位。
图3-15所示为MAC地址示意图 [19][20] 。
图3-15 MAC地址格式
注意图3-15中的字节序和比特序。
·字节序为Big-endian，即最高字节在前。所以图中的first byte实际对应的MAC地
址最左边一组。以Note 2 MAC地址90-18-7C-69-88-E2为例，first byte就
是“90”（如果是Little-endian，则first byte是"E2"），其OUI是SamsungE，代表三
星电子。
·比特序为Little-endian，即最低位在前。这就是01-XX-XX-XX-XX-XX为组播地
址的原因了。因为“01”对应的二进制是“0000-0001”，其第0位是1，应该放在图中
first byte最左边一格。
提示上面的数值按从左至右为最高位到最低位。一般情况下，字节序和比特序是一致
的。但是以太网数据传输时，字节序采用Big-endian，比特序为Little-endian。
参考资料[19]中原文是这样描述的。
The first bit（LSB）shall be used in the Destination Address field as an
address type designation bit to identify the DA either as an individual or as
agroup address.If this bit is 0，it shall be…individual address",“Each octet of
each address filed shall be transmitted least significant bit first。
802.11 MAC帧头部分共包含四个Address域，但规范中却有五种地址定义，分别如
下 [15] 。
·BSSID：在基础型BSS中，它为AP ① 的地址。而在IBSS中则是一个本地唯一MAC
地址。该地址由一个46位的随机数生成，并且U/ M位为0，G/ L位为1。另外对MAC广播地
址来说，其名称为wildcard BSSID。
·目标地址（Destination Address，DA）：用来描述MAC数据包最终接收者（final
recipient），可以是单播或组播地址。
·源地址（Source Address，SA）：用来描述最初发出MAC数据包的STA地址。一
般情况下都是单播地址。
·发送STA地址（Transmitter Address，TA）：用于描述将MAC数据包发送到W M
中的STA地址。
·接收STA地址（Receiver Address，RA）：用于描述接收MAC帧数据的。如果某
个MAC帧数据接收者也是STA，那么RA和DA一样。但如果接收者不是无线工作站，而是
比如以太网中的某台PC，那么DA就是该机器的MAC地址，而RA则是AP的MAC地址。这
就表明该帧将先发给AP，然后由AP转发给PC。
上述无线地址中，一般只使用Address 1～Address 3三个字段，故图3-13中它们的位
置排在一起。表3-4展示了Address域的用法。
由表3-4可知，Address 1用作接收端，Address 2用作发送端。Address 3携带其他信
息用于帮助MAC帧的传输，针对不同类型，各个Address域的用法如下。
·IBSS网络中，由于不存在DS，所以Address 1指明接收者，Address 2代表发送
者。Address 3被设置为BSSID，其作用是：如果Address 1被设置为组播地址，那么只有
位于同一个BSSID的STA才有必要接收数据。
·基础结构型网络中，如果STA发送数据，Address 1必须是BSSID，代表AP。因为
这种网络中，所有数据都必须通过AP。Address 3代表最终的接收者，一般是DS上的某个
目标地址。
·基础结构型网络中，如果数据从AP来，那么Address 1指明STA的地址，Address 2
代表AP的地址，Address 3则代表DS上的某个源端地址。
·Address 4只在无线网络桥接的时候才使用。本书不讨论这种情况。
图3-16描述了基础型结构网络和无线桥接情况下不同地址的使用场景。
图3-16 地址的使用
如图3-16所示：
·数据包发往DS的情况下，SA和TA一致，而RA和BSSID一致。
·数据包来自DS的情况下，RA和DA一致，而TA和BSSID一致。
·无线桥接的情况下，SA、TA、RA和DA四种地址都派上了用场。
提示关于Address域的作用请读者务必清楚下面三个关键点。
1）MAC帧头中包含四个Address域，在不同的情况下，每个域中包含不同的地址。原
则是Address 1代表接收地址，Address 2代表发送端地址，Address 3辅助用，Address
4用于无线桥接或Mesh BSS网络中。
2）规范定义了五种类型的地址，即BSSID、RA、SA、DA和TA。每种地址有不同的
含义。
3）在某些情况下，有些类型地址的值相同，如图3-16所示。
（4）Sequence Control域
Sequence Control域长16位，前4位代表片段编号（Fragment Number），后12位
为帧顺序编号（Sequence Number），域格式如图3-17所示。
图3-17 Sequence Control域格式
·Sequence Number：STA每次发送数据帧时都会设置一个帧顺序编号。注意，控制
帧没有帧顺序编号。另外，重传帧不使用新的帧顺序编号。
·Fragment Number：用于控制分片帧。如果数据量太大，则MAC层会将其分片发
送。每个分片帧都有对应的分片编号。
（5）MAC帧相关知识总结
本节对MAC帧格式进行介绍。这部分内容难度并不大，但读起来肯定有些枯燥。笔者
在阅读参考资料[15]时也有同样的感觉。后来笔者利用公司的AirPcap无线网络分析设备截
获无线网络数据并使用wireshark软件进行分析后，感觉MAC帧信息直观多了，如图3-18
所示。
图3-18 AirPcap使用
AirPcap设备比较贵，但该工具对于将来W i-Fi知识的学习、工作中的难题解决相当有
帮助。
注意本书的资源共享文件中提供几个W i-Fi数据包捕获文件，读者可直接利用它们进
行分析。详情见1.3节。
接下来介绍常见的几种具体的MAC帧。首先从控制帧开始。
3.控制帧 [15][17]
控制帧的作用包括协助数据帧的传递、管理无线媒介的访问等。规范中定义的控制帧有
好几种，本节将介绍其中的四种，它们的帧格式如图3-19所示。由图可知，控制帧不包含
数据，故其长度都不大。
图3-19 控制帧格式
·RTS（Request To Send）：根据3.3.3节关于CSMA/ CA的介绍，RTS用于申请无
线媒介的使用时间。值为Duration，单位为微秒。Duration的计算大致是：要发送的数据
帧或管理帧所需时间+CTS帧所需时间+ACK帧所需时间+3 SIFS ② 时间。
·CTS（Clear To Send）：也和CSMA/ CA有关，用于回复RTS帧。另外它被
802.11g保护机制用来避免干扰旧的STA。
·ACK：802.11中，MAC以及任何数据的传输都需要得到肯定确认。这些数据包括普
通的数据传输、RTS/ CTS交换之前帧以及分片帧。
·PS-POLL：该控制帧被STA用于从AP中获取因省电模式而缓存的数据。其中AID的
值是STA和AP关联时，由AP赋给该STA的。
规范阅读提示
1）控制帧还包括CF-End、CF-End+CF-Ack等，这部分内容请读者阅读规范8.3.1
节。
2）上述帧中Duration字段的计算也是一个比较重要的知识点，读者同样可阅读规范
8.3.1节以了解其细节。
4.管理帧 [15][17]
管理帧是802.11中非常重要的一部分。相比有线网络而言，无线网络管理的难度要大很
多。MAC管理帧内容较为丰富，本节将介绍其中重要的几种管理帧，分别是Beacon（信
标）帧、Association Request/ Response（关联请求/ 回复）帧、Probe
Request/ Response（探测请求/ 回复）帧、Authentication/ Deauthentication（认证/ 取
消认证）帧。
介绍具体管理帧之前，先来看看管理帧的格式，如图3-20所示。
图3-20 管理帧格式
所有管理帧都包括MAC Header的6个域。不过，无线网络要管理的内容如此之多，这
6个域肯定不能承担如此重任，所以管理帧中的Frame Body将携带具体的管理信息数据。
802.11的管理信息数据大体可分为两种类型。
·定长字段：指长度固定的信息，规范称为Fixed Field。
·信息元素：指长度不固定的信息。显然这类信息中一定会有一个参数用于指示最终的
数据长度。
从程序员的角度来看，不同的管理信息数据就好像不同的数据类型或数据结构一样。下
面我们来看看802.11为管理帧定义了哪些数据类型和数据结构。
（1）定长字段
管理帧中固定长度的字段如下。
1）Authentication Algorithm Number：该字段占2字节，代表认证过程中所使用的
认证类型。其取值如下。
·0：代表开放系统身份认证（Open System Authentication）。
·1：代表共享密钥身份认证（Shared Key Authentication）。
·2：代表快速BSS切换（Fast BSS Transition）。
·3：代表SAE（Simultaneous Authentication of Equals）。用于两个STA互相认
证的方法，常用于Mesh BSS网络。
·65535：代表厂商自定义算法。
提示 Authentication Algorithm Number的定义是不是可以在代码中用枚举类型来
表示呢？
2）Beacon Interval field：该字段占2字节。每隔一段时间AP就会发出Beacon信号
用来宣布无线网络的存在。该信号包含了BSS参数等重要信息。所以STA必须要监听
Beacon信号。Beacon Interval field字段用来表示Beacon信号之间间隔的时间，其单位
为Time Units（规范中缩写为TU。注意，一个TU为1024微秒。这里采用2作为基数进行计
算）。一般该字段会设置为100个TU。
3）Capability Information（性能信息）：该字段长2字节，一般通过Beacon帧、
Probe Request和Response帧携带它。该字段用于宣告此网络具备何种功能。2字节中的
每一位（共16位）都用来表示网络是否拥有某项功能。该字段的格式如图3-21所示。
图3-21 Capability Information格式
图3-21中几个常用的功能位如下。
·ESS/ IBSS：基础结构型网络中，AP将设置ESS位为1，IBSS位为0。相反，IBSS
中，STA设置ESS位为0，而IBSS位为1。Mesh BSS中，这两个位都为0。
·Privacy：如果传输过程中需要维护数据机密性（data confidentiality），则AP设
置该位为1，否则为0。
·Spectrum Mgmt：如果某设备对应MIB中dot11SpectrumManagementRequired
为真，则该位为1。根据802.11 MIB对dot11SpectrumManagementRequired的描述，它
和前面介绍的TPC（传输功率控制）和DFS（动态频率选择）功能有关。
·Radio Measurement：如果某设备对应MIB中的
dot11RadioMeasurementActivated值为真，则该位置为1，用于表示无线网络支持
Radio Measurement Service。
4）Current AP Address：该字段长6字节，表示当前和STA关联的AP的MAC地址。
其作用是便于关联和重新关联操作。
5）Listen Interval：该值长2字节，和省电模式有关。其作用是告知AP，STA进入
PS模式后，每隔多长时间它会醒来接收Beacon帧。AP可以根据该值为STA设置对应的缓
存大小，该值越长，对应的缓冲也相应较大。该值的单位是前文提到的另外一个定长字段
Beacon Interval。
6）Association ID（AID）：该字段长2字节。STA和AP关联后，AP会为其分配一
个Association ID用于后续的管理和控制（如PS-POLL帧的使用）。不过为了和帧头中的
Duration/ ID匹配，其最高2位永远为1，取值范围1～2007。
7）Reason Code：该字段长2字节。用于通知Diassociaton、Deauthentication等
操作（包括DELTS、DELBA、DLS Teardown等）失败的原因。Reason Code的详细取
值情况可参考规范的8.4.1.7节的Table 8-36。此处为读者列出几个常见取值及含义，如表
3-5所示。
注意规范一共定义了67个不同的Reason Code值，其详细含义请参考规范的图8-
36。
8）Status Code：该字段长2字节，用于反馈某次操作的处理结果。0代表成功。该字
段取值的细节请读者参考规范8.4.1.9节的Table 8-37。
管理帧中定长字段还有其他几个，此处就不一一列举了。读者可参考规范8.4.1节以获
取详细信息。下面我们介绍管理帧定义的不定长数据结构，即信息元素（Information
Elements，IE）。
（2）信息元素
信息元素（IE）包含数据长度不固定的信息，其标准结构如图3-22所示。其
中，Element ID表示不同的信息元素类型。Length表示Information字段的长度。根据
Element ID的不同，Information中包含不同的信息。
图3-22 IE标准结构
表3-6列出了几种Element ID及Length的取值情况。完整的取值列表请参考规范中
Table 8-54。
注意，表3-6中最后一列的Subelements表示该项对应的Information采用如图3-23所
示的格式来组织其数据。
图3-23 Subelement格式
很显然，图3-23和图3-22所示格式完全一样，这也就是Subelement的由来。
Subelement的具体内容介绍由Subelement ID来决定。
规范阅读提示规范指出IE中的Length字段代表Information的长度。但规范给出的
具体IE信息表（如Table 8-54）其Length一列却是IE的全长（即Element ID字段长
+Length字段+Info字段长度）。本节所列表3-5中的Length长仅取Info字段长度。故比
Table 8-54中的Length长度少2字节。
（3）常用管理帧
了解了定长字段以及信息元素后，下面介绍管理帧中几种重要类型的帧。
1）Beacon帧：非常重要，AP定时发送Beacon帧用来声明某个网络。这样，STA通过
Beacon帧就知道该网络还存在。此外，Beacon帧还携带了网络的一些信息。简单来
说，Beacon帧就是某个网络的心跳信息。Beacon帧能携带的信息非常多，不过并非所有信
息都会包含在Beacon帧中。表3-7介绍了Beacon帧中必须包含的信息。
提示如果读者手头有AirPcap工具，不妨尝试截获一下周围的Beacon帧。
2）Probe Request/ Response帧：STA除了监听Beacon帧以了解网络信息外，还可以
发送Probe Request帧用于搜索周围的无线网络。规范要求由送出Beacon帧的STA回复
Probe Response帧，这样，在基础结构型网络中，Beacon帧只能由AP发送，故Probe
Response也由AP发送。IBSS中，STA轮流发送Beacon帧，故Probe Response由最后一
次发送Beacon帧的STA发送。
表3-8列出了Probe Request帧中必须包含的信息。
当AP收到Probe Request时，会响应以Probe Response帧。Probe Response帧包含
的内容绝大部分和Beacon帧一样，此处就不拟详细讨论了。读者可参考规范Table 8-27获
取详细信息。
提示图3-18所示为笔者利用AirPcap截获的SSID为"Test"的Probe Request帧，读
者不妨回头看看此图。
3）Association Request/ Response帧：当STA需要关联到某个AP时，将发送此帧。
该帧携带的一些信息项如表3-9所示。
请读者参考规范Table 8-22获取Association Request帧包含的全部信息项。
针对Association Request帧，AP会回复一个Association Response帧用于通知关联
请求处理结果。该帧携带的信息如表3-10所示。
请读者参考规范Table 8-23获取Association Response帧包含的全部信息项。
4）Authentication帧：用于身份验证，其包含的信息如表3-11所示。
至此，我们对802.11 MAC管理帧的相关知识就介绍完毕。规范定义的管理帧类型并不
多，一共15种。但管理帧携带的信息却相当复杂，其中定长字段有42种，IE有120种。此处
建议读者先了解管理帧中信息的组织方式，然后对最重要的几种管理帧做简单了解。以后碰
到不熟悉的情况，可直接查询802.11规范相关小节即可获取最完整的信息。
5.数据帧 [15][17]
图3-24展示了802.11中完整的数据帧格式。
图3-24 数据帧格式
其中，QoS Control和HT（High Throughput）Control字段只在QoS和HT的情况
下出现。本书不讨论它们的内容。其他情况下，Frame Body最大长度为2312字节。
提示图3-24中4个Address字段的使用请参考表3-3和图3-16。
6.802.11上层协议封装 [21]
本节介绍802.11中如何对上层协议进行格式封装。和Ethernet不同，802.11使用LLC
层来封装上层协议，如图3-25所示。
图3-25 802.11上层协议封装
图3-25中，最上层是Ethernet帧格式。前面12字节分别是目标MAC地址以及源MAC
地址。Type字段可以为0x0800，代表后面的数据是IP包。
当Ethernet帧要在无线网络上传输时，必须先将其转换为LLC帧，如中间一层所示。
这种转换方法由RFC 1042规定。它主要在MAC headers和Type之间增加了4个字段。它们
统称为SNAP header（Sub Network Access Protocol，子网访问协议），分别如下。
·DSAP（Destination Service Access Point，目标服务接入点）。
·SSAP（Source Service Access Point，源服务接入点）。
·Control（控制字段，值被设定为0x03，代表Unnumbered Information，即未编
号信息）。
·OUI（固定为0x000000）。
LLC数据最后被封装成802.11MAC帧。主要变化是帧头信息，因为802.11 MAC帧最
多能携带4个MAC地址。其他信息则作为802.11 MAC帧的数据载荷。
注意 802.11除了可以用RFC 1024来封装Ethernet外，还支持802.1h的封装方法。详
情见参考资料[21]。
笔者截获的802.11 MAC帧以及以太网帧IP包如图3-26所示。
图3-26 以太网帧和802.11 MAC帧
图3-26上半部分为Ethernet的IP帧封装情况，下半部分为IP包在802.11中的封装情
况。
注意图3-26中的黑框表示Radiotap头信息。它是网卡添加在802.11 MAC头部前的
数据，记录了信号强度、噪声强度和传输速率等物理层信息。关于Radiotap更多信息，请
读者参考http:/ / www.radiotap.org/ 。
通过对MAC提供的服务以及MAC帧相关知识的介绍，读者会发现这部分难度主要集中
在802.11 MAC帧上，尤其是管理帧包含的信息更是非常丰富。
从程序员角度看，可以认为本节为802.11定义了大量的数据结构和数据类型。从下一节
开始，我们将介绍MAC层中的“类和函数”。
规范阅读提示
1）本节内容主要取自规范的第8章"Frame Formats”。
2）由于篇幅问题，本书不介绍802.11 MAC层的功能。这部分内容主要集中在规范的
第9章"MAC sublayer functional description"。
① 此条根据审稿专家的反馈意见修改。Infrastructure BSS中，BSSID一般为AP的
MAC地址。
② SIFS（Short InterFrame Space，短帧间隔）和CSMA/ CA的具体实现有关，本文不
讨论。
3.3.6 802.11 MAC管理实体 [22][23]
802.11包括了MAC层和PHY层。根据图3-4可知这两层内部都对应有Entity，它们通
过SAP（Service Access Point）为对应的上层提供服务。图3-27展示了802.11中的
Entity和SAP。
图3-27 802.11 Entity模型
由图3-27可知：
·MAC_SAP为LLC层提供服务，其具体内容见3.3.5节“MAC服务定义”。
·MAC子层中还有专门负责管理的Entity，名为MLME（MAC Sublayer
Management Entity），它对外提供的接口是MLME_SAP。
·PHY层还可细分为PLCP和PMD两层（本书不讨论）。
·物理层对外提供的管理实体是PLME（PHY Sublayer Management Entity），对
应的SAP缩写为PLME_SAP。
·为了方便对802.11 MAC及PHY层统一操作和管理，规范还定义一个SME（Station
Management Entity）。该实体独立于MAC和PHY层。使用者可通过SME实体来操作
MAC层和PHY层中的SAP。
本节重点关注MAC的管理Entity（即MLME）及其对应的SAP。规范中关于
MLME_SAP一共有82个原语，其中一部分如图3-28所示。
图3-28 MLME SAP部分内容
原语的定义曾在3.3.5节MAC服务定义中见过，它其实就是通过定义API来表达自己所
具有的功能。MLME_SAP非常多，本章不可能全部覆盖，此处仅介绍三个常用的原语。
·Scan：用于扫描周围的无线网络。
·Authenticate：关联到某个AP前，用于STA的身份验证。
·Associate：关联某个AP。关联成功后，STA就正式加入无线网络了。
提醒请读者务必注意一点，理解MLME_SAP原语对掌握W i-Fi技术非常重要。从编
程角度来说，MLME_SAP相当于定义了一套接口函数，而后续章节将介绍的
wpa_supplicant只是对它们的实现。
1.Scan介绍
原语的参数比较多，但并不是所有参数都需要（由对应的MIB项控制），本书仅介绍比
较重要的参数（用加粗字体表示）。
（1）request
Scan.request原语用于扫描周围的无线网络，其原型如下。
MLME-SCAN.request(
BSSType,BSSID,SSID,ScanType,ProbeDelay,
ChannelList,MinChannelTime,MaxChannelTime,
RequestInformation, SSID List,
ChannelUsage,AccessNetworkType,HESSID,MeshID,VendorSpecificInfo
)
Scan参数中，比较几个重要的分别如下。
·BSSType：类型为枚举（Enumeration），可取值为INFRASTRUCTURE、
INDEPENDENT、MESH、ANY_BSS。
·BSSID：类型为MAC地址。可以是某个指定的BSSID或者广播BSSID。
·SSID：类型为字符串。0～32字节长。指定网络名，如果长度为0，则为wild ssid。
·ScanType：类型为枚举，可取值为ACTIVE（主动）、PASSIVE（被动）。详情
见下文。
·ProbeDelay：类型为整型，单位为微秒。用于ACTIVE模式的扫描，详情见下文。
·ChannelList：类型为有序整数列表（Ordered set of integers），扫描时使用。
·MinChannelTime和MaxChannelTime：类型均为整型。用于指示扫描过程中在每
个信道上等待的最小和最长时间。时间单位为TU。
由Scan.request的ScanType参数可知，802.11规定了两种扫描模式。
·ACTIVE模式：这种模式下，STA在每个Channel（信道）上都会发出Probe
Request帧用来搜索某个网络。具体工作方式是，STA首先调整到某个信道，然后等待来帧
指示（表明该信道有人使用）或超时时间ProbeDelay。两个条件满足任意一个，STA都将
发送Probe Request帧，然后STA在该信道上等待最少MinChannelTime时间（如果在此
时间内信道一直空闲），最长MaxChannelTime时间。
·PASSIVE模式：这种模式下，STA不发送任何信号，只是在ChannelList中各个信
道间不断切换并等待Beacon帧。根据前述介绍可知，在基础结构型网络中AP会定时发送
Beacon帧以宣告网络的存在。所以，PASSIVE模式下，STA能根据Beacon帧来了解周围
所存在的无线网络。
（2）confirm
Scan.confirm用于通知扫描结果，其原型定义如下。
MLME-SCAN.confirm（
BSSDescriptionSet，BSSDescriptionFromMeasurementPilotSet，
ResultCode，VendorSpecificInfo
）
·BSSDescriptionSet：类型为BSSDescription列表。具体内容见下文。
·ResultCode：类型为枚举，可取值为SUCCESS和NOT_SUPPORTED。
BSSDescription包含很多内容，常见项如表3-12所示。
获取周围的无线网络后，STA可以选择加入（join）其中的一个BSS。规范没有定义网
络加入的原语，但实际上大部分无线网卡在实现时，都需要join相关的处理。因为如果周围
存在多个无线网络时，需要用户参与来选择加入哪一个网络。BSSDescription全部取值列
表请参考规范6.3.3.3.2节。
2.Authenticate介绍
关联到某个AP前，STA必须通过身份验证。该处理由Authenticate对应的原语来完
成。由于身份验证涉及两个STA（以基础结构型网络为例，一个是STA，另一个是AP），
所以Authenticate包含4个原语，分别如下。
·MLME-Authenticate.request：STA A向AP B发起身份验证请求。
·MLME-Authenticate.confirm：STA A收到来自AP B的身份验证处理结果。
·MLME-Authenticate.indication：AP B收到来自STA A的身份验证处理请求。
·MLME-Authenticate.response：AP B向STA A发送身份验证处理结果。
先来看request和confirm原语。
（1）request和confirm
request和confirm原语原型如下。
MLME-AUTHENTICATE.request(
PeerSTAAddress,AuthenticationType, AuthenticateFailureTimeout,
Content of FT Authentication elements,
Content of SAE Authentication Frame,
VendorSpecificInfo
)
// confirm原型
MLME-AUTHENTICATE.confirm(
PeerSTAAddress,AuthenticationType, ResultCode,
Content of FT Authentication elements,
Content of SAE Authentication Frame,
VendorSpecificInfo
)
上述原语定义说明如下。
·PeerSTAAddress：类型为MAC地址，代表对端STA的地址。以本例而言，则是AP
B的MAC地址。
·AuthenticationType：类型为枚举，可取值有OPEN_SYSTEN、
SHARED_KEY、FAST_BSS_TRANSITION和SAE。用于表示认证过程中使用的认证类
型。这部分内容见3.3.7节无线网络安全相关介绍。
·AuthenticateFailureTimeout：类型为整型，代表认证超时时间，单位为TU。
·ResultCode：代表认证处理结果。
MLME-AUTHENTICATE.request将触发STA A发送Authenticate帧。下面来看AP
B如何处理收到的这个Authenticate帧呢？
（2）indication和response
这两个原语定义和request以及confirm基本一样。
MLME-AUTHENTICATE.indication(
PeerSTAAddress,AuthenticationType,
Content of FT Authentication elements,
Content of SAE Authentication Frame,
VendorSpecificInfo
)
// response原型
MLME-AUTHENTICATE.response(
PeerSTAAddress,AuthenticationType, ResultCode,
Content of FT Authentication elements,
Content of SAE Authentication Frame,
VendorSpecificInfo
)
indication和对应的response参数与request以及confirm一样，此处不详述。
3.Associate介绍
STA通过身份验证后，就需要和AP关联。只有关联成功后，STA才正式成为无线网络
的一员。
注意对于RSN，关联成功后还需通过802.1X身份验证。相关内容留待3.3.7节介绍。
Associate包含的原语和Authentication一样，都有request、confirm、indication
和response。我们先来看request和confirm。
（1）request和confirm
request和confirm原语定义如下。
MLME-ASSOCIATE.request(
PeerSTAAddress, AssociateFailureTimeout,CapabilityInformation,
ListenInterval,Supported Channels,
RSN,
QoSCapability,Content of FT Authentication elements,SupportedOperatingClasses,
HT Capabilities,Extended Capabilities,20/40 BSS Coexistence, QoSTrafficCapability,
TIMBroadcastRequest,EmergencyServices,VendorSpecificInfo
)
// confirm原语
MLME-ASSOCIATE.confirm(
ResultCode,CapabilityInformation,AssociationID,SupportedRates,
EDCAParameterSet,RCPI.request,RSNI.request,RCPI.response,
RSNI.response,RMEnabledCapabilities,Content of FT Authentication elements,
SupportedOperatingClasses,HT Capabilities,Extended Capabilities,
20/40 BSS Coexistence, TimeoutInterval,BSSMaxIdlePeriod,TIMBroadcastResponse,
QosMapSet,VendorSpecificInfo
)
上述原语中包含的参数信息如下。
·PeerSTAAddress：响应Association请求的STA的MAC地址，即AP的地址。
·AssociateFailureTimeout：类型为整型，代表关联超时时间，单位为TU。
·CapabilityInformation：指定AP的性能信息。
·ListenInterval：用于告知AP，STA进入PS模式后，监听Beacon帧的间隔时间。
·RSN：类型为RSNE，指示STA选设置的安全方面的信息。详情见3.3.7节。
·ResultCode：AP返回的处理结果。
·AssociationID：AP返回的关联ID。
·SupportedRates：AP返回的所支持的传输速率列表。速率以500kbps为单位。
（2）indication和response
indication和response原语定义如下。
MLME-ASSOCIATE.indication(
PeerSTAAddress,CapabilityInformation,ListenInterval,SSID,SupportedRates,
RSN,QoSCapability,RCPI,RSNI,RMEnabledCapabilities,
Content of FT Authentication elements,SupportedOperatingClasses,
DSERegisteredLocation,
HT Capabilities,Extended Capabilities,20/40 BSS Coexistence,QoSTrafficCapability,
TIMBroadcastRequest,EmergencyServices,VendorSpecificInfo
)
// response原语
MLME-ASSOCIATE.response(
PeerSTAAddress,ResultCode,CapabilityInformation,AssociationID,
EDCAParameterSet,RCPI,RSNI,RMEnabledCapabilities,
Content of FT Authentication elements,
SupportedOperatingClasses,DSERegisteredLocation,HTCapabilities,
Extended Capabilities,
20/40 BSS Coexistence, TimeoutInterval,BSSMaxIdlePeriod,TIMBroadcastResponse,
QoSMapSet,VendorSpecificInfo
)
上述原语和参数中，只有indication的SSID略有不同，它代表发起关联请求的STA的
MAC地址。
4.STA状态转换 [24]
上面原语操作成功后，STA状态将发生变化。STA从最初到最终的状态切换如图3-29
所示。
图3-29 STA状态切换
图3-29中包含很多知识点，下面一一介绍它们。首先是MAC帧Frame的类别
（Class），规范定义MAC帧一共有三种类别，分别是Class 1、Class 2和Class 3，各自
包含不同的MAC帧，如表3-13所示。
结合图3-29，可知STA在不同状态下发送的MAC帧类别也不同。这主要是和网络安全
有关，没有通过身份验证的STA是不允许随意传输数据的。图3-29中，STA的状态转换如
下（以基础结构型网络为例）。
·STA首先处于State 1，即未认证和未关联的情况。为了能加入无线网络，它需要发
送Authentication帧给AP。如果认证成功，将转入State 2。State 1情况下不能发送数据
帧。
·State 2是已认证，未关联状态。STA将发送Association帧给AP进行关联。成功
后，进入State 3。State 2情况下也不能发送数据帧。
·State 3属于已认证，已经关联，但还未通过RSN（Robust Security Network，强
健安全网络）认证的状态。RSN采用802.1X进行控制。由于未通过RSN认证，所以只能发
送处理认证的数据帧，即4-W ay Handshake（四次握手）帧。这部分内容在3.3.7节介绍。
·4-W ay Handshake成功后，STA进入State 4。此时它完全加入无线网络，所有数
据帧就能正常传输。
MAC管理实体包含的功能很多，不过对程序员来说，其理解难度反而较小，因为它定
义的原语类似代码中的API，而且每个参数的作用有详尽的解释。读者以后在分析
wpa_supplicant的时候，不妨多回顾本节内容。
3.3.7 无线网络安全技术知识点
安全是无线网络技术中一个很重要的部分，它主要有三个保护点。
·数据的完整性（Integrity）：用于检查数据在传输过程中是否被修改。
·数据的机密性（Confidentiality）：用于确保数据不会被泄露。
·身份验证和访问控制（Authentication and Access Control）：用于检查受访者的
身份。
提示身份验证和访问控制的问题在无线网络中尤为明显。因为W i-Fi以空气作为传播
媒介，这意味着任何人通过类似AirPcap这样的工具就能获取其周围的无线通信数据。而在
以太网环境中，虽然网络数据也是通过广播方式发送，但用户需要把网线插到网口中才能监
听数据。相信没有哪个公司能随随便便允许一个外人把网线插到其公司内部的网口上。由于
无线网络天然就不存在有线网络中这种类似的物理隔离，所以身份验证和访问控制是无线网
络中非常重要的一个问题。
无线网络安全技术也是随着技术发展而逐渐在演变，下面介绍其主要发展历程。
·802.11规则首先提出了W EP（W ired Equivalent Privacy，有线等效加密）。如其
名所示，它是为了达到和有线网络同样的安全性而设计的一套保护措施。
·经过大量研究，人们发现W EP很容易破解。在802.11规范提出新解决方案之
前，W FA提出了一个中间解决方案，即W PA（W i-Fi Protected Access）。这个方案后
来成为802.11i草案的一部分。
·802.11i专门用于解决无线网络的安全问题。该规范提出的最终解决方案叫
RSN（Robust Security Network，强健安全网络），而W FA把RSN称为W PA2。
本节先介绍W EP，然后介绍RSN中的数据加密，最后将介绍EAP、802.1X和RSNA密
匙派生等内容。
注意本书仅介绍数据加密及完整性校验的大致工作流程，而算法本身的内容请读者自
行研究。
另外，安全知识点中会经常见到Key（密钥）和Password（密码，也叫Passphrase）
这两个词。它们本质意思都一样，只不过Password代表可读（human readable，如字符
串、数字等）的Key，而Key一般指由算法生成的不可读（如二进制、十六进制数据等）的
内容。
1.W EP介绍
W EP是802.11规范的元老，在1999年规范刚诞生时就存在了。但随着技术的发展，如
今W EP已经无力应付复杂险恶网络环境中的安全问题了。先来介绍W EP中的数据加密。
（1）W EP中的数据加密 [16][25][26]
保护数据Confidentiality的一个主要方法就是对所传输的数据进行加密，而W EP采用
了流密码（Stream Cipher）对数据进行加密。这种加密方法的原理如图3-30所示。
图3-30 流密码工作原理
流密码的工作原理如下。
·源数据通过Key Stream（密钥流）进行加密，加密方式就是异或（XOR），得到密
文。
·接收端得到密文后，再用相同的Key Stream进行异或操作，这样就能得到目标数
据。两次异或操作，Key Stream又一样，所以目标数据就是源数据。
·整个过程中，只要Key Stream保证随机性，那么不知道Key Stream的人理论上就
无法破解密文。
根据上述内容可知，流密码安全性完全依赖于Key Stream的随机性，那么怎么生成它
呢？一般的做法是：用户输入一个Secret Key（即密码）到伪随机数生成器
（PseudoRandom Number Generator，PRNG）中，而PRNG会根据这个Secret Key生
成密钥流。
下面回到W EP，它的加密处理过程如图3-31所示。
图3-31 W EP加密过程
W EP加密过程如下。
·左上角PRNG的输入（即随机数种子），包括一个IV（Initialization Vector，初始
向量，长24位）和W EP Key（Key长度有40、104和128位。位数越多，安全性越高）。IV
的值由设备厂商负责生成。PRNG最终输出Key Stream。
·XOR（即加密）操作的一方是Key Stream，另一方是数据和ICV（Integrity
Check Value，完整性校验值）。ICV长32位，其值由CRC-32方法对Data进行计算后得
到。XOR操作后的数据即图3-29所示的Encrypted部分。可知Data和ICV都经过了加密。
·最终的MAC帧数据（frame payload）包括IV以及加密后的Data以及ICV。
再来看W EP的解密过程，如图3-32所示。
图3-32 W EP解密过程
W EP解密过程如下。
·帧数据中的IV和W EP Key共同作为PRNG的输入以得到Key Stream。
·Key Stream和帧数据中的Cipher Text执行异或操作，得到明文（Plaintext）以及
ICV。
·接收端同时对自己解密得到的明文进行完整性校验，得到ICV′。如果ICV和ICV′
一样，则数据正确。
提醒 W EP弱点很多，其最主要的一个问题就是所有数据都使用同一个W EP Key进行
加密。至于W EP存在的其他问题，读者可阅读参考资料[25]以获得更详细的信息。
（2）W EP中的身份验证 [27][28]
W EP其实并没有考虑太多关于身份验证方面的事情，根据IEEE 802.11-2012规范，本
节真正的名字应该叫"Pre-RSNA Authentication"，即RSNA出现之前的身份验证。不过
由于Pre-RSNA的认证方法和W EP有密切关系，所以一般就叫W EP身份验证。
W EP身份验证有以下两种。
·开放系统身份验证（Open System Authentication）：这种验证其实等同于没有验
证，因为无论谁来验证都会被通过。那它有什么用呢？规范规定，如果想使用更先进的身份
验证（如RSNA），则STA在发起Authentication请求时，必须使用开放系统身份验证。
由于开放系统身份验证总是返回成功，所以STA将接着通过Association请求进入图3-29中
的State 3然后开展RSNA验证。
·共享密钥身份认证（Shared Key Authentication）：Shared Key这个词以后还会
经常碰到，它表示共享的密码。例如在小型办公及家庭网络（Small Office/ Home
Office，SOHO）环境中，AP的密码一般很多人（即很多STA）都知道。
提示初看上去，共享密钥身份验证的安全性比开放系统要强，但实际却恰恰相反。因
为使用了共享密钥身份验证就不能使用更为安全的RSNA机制。
由于笔者家庭网络就使用了共享密钥身份验证，故这里也简单向读者介绍一下其工作原
理，如图3-33所示。
图3-33 共享密钥身份验证原理
由图3-33可知Shared Key验证的方法包括四次帧交互。
·STA（即图中的Client）发送Authentication请求给AP。
·AP收到请求后，通过Authentication Response发送一个质询明文（Challenge
Text，长度为128字节）给STA。
·STA取出Challenge Text，通过图3-31所示的W EP加密方法利用自己设置的密钥对
质询文进行加密，然后再次发送Authentication Request给AP。
·AP收到第二次Authentication Request帧后，会利用AP的密钥进行解密，同时还
要验证数据完整性。如果ICV正确，并且解密后的译文等于之前发送的质询文，则可知STA
拥有正确的密码，故STA身份验证通过。
·AP返回验证处理结果给STA。如果成功，STA后续将通过Association请求加入该
无线网络。
W EP的介绍就到此为止，下面来介绍RSNA中的数据加密。
2.RSN数据加密及完整性校验 [29][30]
RSN中数据加密及完整性校验算法有两种，分别是TKIP和CCMP。下面分别来介绍它
们。
规范阅读提示规范中还有一种广播/ 组播管理帧完整性校验的方法，叫
BIP（Broadcast/ Multicast Integrity Protocol）。请读者自行阅读规范11.4.4节以了解
相关内容。
介绍TKIP前，先介绍W PA。W PA是802.11i规范正式发布前用于替代W EP的一个中间
产物。相比W EP，W PA做了如下改动。
·W PA采用了新的MIC（Message Integrity Check，消息完整性校验）算法用于替
代W EP中的CRC算法。新算法名为Michael。
·采用TKIP（Temporal Key Integrity Protocol，临时密钥完整性协议）用于为每
一个MAC帧生成不同的Key。这种为每帧都生成单独密钥的过程称为密钥混合（Key
Mixing）。
（1）TKIP加密
下面简单介绍TKIP的加密过程，如图3-34所示。
图3-34 TKIP加密过程
·左下角：用于数据完整性校验的Michael算法的输入包括两部分，一部分是MIC
Key（由厂商负责实现），另一部分是MAC帧头中的DA、SA、Priority和MAC帧数据。
Michael算法的输出为Data和MIC。它们将作为后续加密算法的输入（等同于图3-31中加
密前的Data+ICV）。
·左上角：TKIP的密钥计算分为两部分。首先是第一阶段的密钥混合，其输入有
TA（Transmitter Address，32位）、TK（Temporal Key，128位）和TSC（TKIP
Sequence Counter，序列号计数器。共48位，此处取其前32位）。此阶段密钥混合段的产
物是TTAK（TKIP-mixed Transmit Address and Key，长80位）。注意，TK的来历见
后文关于密匙派生的知识。
·中间部分：Phase 2 key mixing属于密钥计算的第二部分。本阶段计算的输入有
TTAK和TSC（取其后16位），其产物可用作后续加密计算的W EP种子（包括一个128位的
ARC4密钥以及IV，可参考图3-31）。
·最后一步：利用W EP的加密方法进行数据加密，其过程即先利用W EP种子和PRNG
生成密钥流（由于每一个待加密的帧都会有不同的TSC，导致在进行PRNG前，每次输入都
有不同的W EP Key），然后使用XOR操作对Data和MIC进行异或。
由上述内容可知，TKIP将为每一帧数据都使用不同的密钥进行加密，故其安全性比
W EP要高。另外，由于生成密钥和计算完整性校验时会把MAC地址（如DA、SA、TA）等
信息都考虑进去，所以它可以抵抗几种不同类型的网络攻击[30]。不过，从加密本身来考
虑，TKIP和W EP一样都属于流密码加密。
（2）CCMP加密
CCMP出现在W PA2中，它比TKIP更安全，因为它采用了全新的加密方式
CCMP（Counter Mode with CBC-MAC Protocol，计数器模块及密码块链消息认证码
协议），这是一种基于AES（Advanced Encryption Standard，高级加密标准）的块的
安全协议。
CCMP加密过程如图3-35所示。
图3-35 CCMP加密过程
·左下角：PN（Packet Number，帧编号，48位）和KeyId（Key Identifier，密钥
标示符，每帧使用一个密钥）共同构成一个8字节的CCMP头（CCMP Header）。另外，
每一帧的PN都会累加，所以图中有一个"Increment PN"处理框（注意，重传包的PN不累
加）。
·左上角：Plaintext MPDU（注意不是MSDU）意味着整个MAC帧（包括Head）都
是输入参数。MPDU被拆分成三个部分，其中A2（Address 2字段）、Priority和PN共同
构成Nonce（即临时的随机数，用一次后就丢弃不再使用）。MPDU中的MAC头信息将构
成AAD（Additional Authentication Data，附加认证数据）。
·AAD、Nonce、MPDU中的MAC数据（Payload）以及TK（Temporary Key）共
同作为加密算法的输入，最终得到加密后的数据及消息校验码（Message Integrity
Check，MIC）。
·CCMP Header、MAC Header、加密后的Data以及MIC共同构成了MPDU包。
关于RSN中的加密算法TKIP及CCMP就介绍到此。由于加解密工作上由硬件来完成，
读者仅需了解其中涉及的概念即可。
3.EAP和802.1X介绍
从本节开始，我们将重点关注安全主题中最后一个重要部分，即身份验证。首先介绍
EAP，然后介绍802.1X。
提示 wpa_supplicant很大一部分内容就是在处理身份验证，所以本节也将花费较多
的笔墨来介绍相关内容。
（1）EAP [31][32][33]
目前身份验证方面最基础的安全协议就是EAP（Extensible Authentication
Protocol），协议文档定义在RFC3748中。EAP是一种协议，更是一种协议框架。基于这
个框架，各种认证方法都可得到很好的支持。下面来认识EAP协议。首先介绍其中涉及的几
个基本概念。
·Authenticator（验证者）：简单点说，Authenticator就是响应认证请求的实体
（Entity）。对无线网络来说，Authenticator往往是AP。
·Supplicant（验证申请者 ① ）发起验证请求的实体。对于无线网络来
说，Supplicant就是智能手机。
·BAS（Backend Authentication Server，后端认证服务器）：某些情况下（例如
企业级应用）Authenticator并不真正处理身份验证，它仅仅将验证请求发给后台认证服务
器去处理。正是这种架构设计拓展了EAP的适用范围。
·AAA（Authentication、Authorization and Accounting，认证、授权和计
费）：另外一种基于EAP的协议。实现它的实体属于BAS的一种具体形式，AAA包括常用
的RADIUS服务器等。在RFC3748中，AAA和BAS的概念可互相替代。
·EAP Server：表示真正处理身份验证的实体。如果没有BAS，则EAP Server功能
就在Authenticator中，否则该功能由BAS实现。
EAP架构如图3-36所示。
图3-36 EAP架构
由图3-36所示，Supplicant通过EAPOL（EAP Over LAN，基于LAN的扩展EAP协
议）发送身份验证请求给Authenticator。图中的身份验证由后台验证服务器完成。如果验
证成功，Supplicant就可正常使用网络了。
下面来认识EAP的协议栈，如图3-37所示。
图3-37 EAP协议栈
由图3-37可知，EAP没有强制定义位于最底层（Lower Layer，LL）的传输层。目前
支持EAP协议的网络有PPP、有线网（EAPOL，也就是802.1X协议）、无线网络（即
802.11 W LAN）、TCP、UDP等。另外，LL本身的特性（例如以太网和无线网都支持数据
重排及分片的特性）会影响其上一层EAP的具体实现。
·EAP Layer用于收发数据，同时处理数据重传及重复（Duplicate）包。
·EAP Supplicant/ Authenticator Layer根据收到EAP数据包中Type字段（见下文
介绍）的不同，将其转给不同的EAP Method处理。
·EAP Method属于具体的身份验证算法层。不同的身份验证方法有不同的Method
Type。
EAP协议的格式非常简单，如图3-38所示。
图3-38 EAP协议格式
·Code：EAP协议第一字节，目前仅有四种取值，分别为1（Request）、
2（Response）、3（Success）、4（Failure）。
·Identifier：消息编号（ID），用于配对Request和Response。
·Length：2字节，用于表示EAP消息包长度（包括EAP头和数据的长度）。
·Data：EAP中具体的数据（Payload）。当Code为Request或Response的时
候，Data字段还可细分为Type以及Type Data。Type就是图3-37中的EAP Method
Type。
EAP Method Type取值如下。
·1：代表Identity。用于Request消息中。其Type Data字段一般将携带申请者的一
些信息。一般简写为EAP-Request/ Identity或者Request/ Identity。
·2：代表Notification。Authenticator用它传递一些消息（例如密码已过期、账号
被锁等）给Supplicant。一般简写为Request/ Notification。
·3：代表Nak，仅用于Response帧，表示否定确认。例如Authenticator用了
Supplicant不支持的验证类型发起请求，Supplicant可利用Response/ Nak消息以告知
Authenticator其支持的验证类型。
·4：代表身份验证方法中的MD5质询法。Authenticator将发送一段随机的明文给
Supplicant。Supplicant收到该明文后，将其和密码一起做MD5计算得到结果A，然后将
结果A返回给Authenticator。Authenticator再根据正确密码和MD5质询文做MD5计算得
到结果B。A和B一比较就知道Supplicant使用的密码是否正确。
·5：代表身份验证方法为OTP（One Time Password，一次性密码）。这是目前最
安全的身份验证机制。相信网购过的读者都用过它，例如网银付费时系统会通过短信发送一
个密码，这就是OTP。
·6：代表身份验证方法为GTC（Generic Token Card，通用令牌卡）。GTC和OTP
类似，只不过GTC往往对应一个实际的设备，例如许多国内银行都会给申请网银的用户一
个动态口令牌。它就是GTC。
·254：代表扩展验证方法（Expanded Types）。
·255：代表其他试验性用途（Experimental Use）。
图3-39所示为一个简单的EAP交互。第三和第四步时，Authenticator要求使用MD5
质询法进行身份验证，但Supplicant不支持，故其回复NAK消息，并通知Authenticator
使用GTC方法进行身份验证。第六步中，如果Supplicant回复了错误的GTC密码
时，Authenticator可能会重新发送Request消息以允许Supplicant重新尝试身份验证。一
般认证失败超过3次才会回复Failure消息。
图3-39 EAP交互
EAP的基本情况就介绍到此，读者可通过RFC3748了解它的详细情况。下面介绍
802.1X。
提示可阅读参考资料[32]以了解EAP的其他几种验证方法。
（2）802.1X [34][35]
802.1X是802.1规范家族中的一员。简单来说，802.1X详细讨论了EAP在W ired LAN
上的实现，即EAPOL。先来认识802.1X中的两个重要概念，如图3-40所示。
由图3-40可知，802.1X定义了：Controlled Port和UnControlled Port（受控和非
受控端口）。
Port是802.1X的核心概念，其形象和我们常见的以太网中网口很类似。Port的定义和
图3-4中所述的定义一样。802.1X定义了两种Port，对于UnControlled Port来说，只允许
少量类型的数据流通（例如用于认证的EAPOL帧）。Controlled Port在端口认证通过前
（即Port处于Unauthorized状态），不允许传输任何数据。
802.1X身份验证通过后，Control Port转入Port Authorized状态。这时，双方就可
通过Controlled Port传递任何数据了。
提示 802.1X-2010文档只有200来页，但难度不小，引用的参考资料也非常多。建议
读者看完本节后再结合实际需求去阅读它。另外802.1X中还定义了一个很重要对象叫
PAE（Port Access Entity）。Entity的概念在3.3.1节曾介绍过，它代表封装了一组功能
的模块。在802.1X中，PAE负责和PACP（Port Access Control Protocol）协议相关的
算法及处理工作。PAE分为Supplicant PAE和Authenticator PAE两种。
下面来看EAPOL的数据格式，如图3-41所示。
图3-40 802.1X中的Port
图3-41 EAPOL格式
由图3-41可知EAPOL消息格式如下。
·Protocol Version：占1字节，代表当前使用的802.1X版本号。值为0x03代表
802.1X-2010，值为0x02则表示802.1X-2004，值为0x01表示802.1X-2001。
·Packet Type：EAPOL对EAP进行了扩展，该字段取值详细内容见表3-14。
·Packet Body Length：指明Packet Body的长度。
EAPOL消息中最重要的是Packet Type，目前规范定义的几种常见取值如表3-14所
示。
EAPOL-Key用于交换身份验证过程中使用的密钥信息，其对应的Packet Body格式如
图3-42所示。Descriptor Type表示后面Descriptor Body的类型。802.1X
中，Descriptor Type值为2时，Descriptor Body的内容由802.11定义。此处给读者展示
一个实际的例子，如图3-43所示。
图3-42 EAPOL-Key帧对应的Body格式
图3-43 EAPOL-Key帧实例
图3-43中：
·0x888e代表EAPOL在802.11帧中的类型。
·Key Descriptor Type值为2，表示EAPOL RSN Key。
·Descriptor Body的内容就是大括号中所包含的信息。其细节请读者阅读802.11第
11.6.2节。
最后，看看用MD5质询算法作为身份验证的EAPOL认证流程，如图3-44所示。
图3-44 EAPOL认证流程
·Supplicant主动向Authenticator发送EAPOL-Start消息来触发认证。注
意，EAPOL-Start消息不是必需的。
·Authenticator收到EAPOL-Start消息后，将发出EAP-Request/ Identity消息以
要求Supplicant输入用户名。由于EAPOL-Start消息不是必需的，所以一个未经验证的
Supplicant发送了其他数据包也将触发Authenticator发送EAP-Request/ Identity消息。
·Supplicant将用户名信息通过EAP-Response/ Identity消息发送给
Authenticator。Authenticator再将它经过封包处理后（转换成RADIUS Access-
Request消息）送给AS（Authenticator Server）进行处理。
·AS收到Authenticator转发的用户名信息后，将其与数据库中的用户名表对比，找
到该用户名对应的密码信息。然后随机生成的一个MD5质询文并通过RADIUS Access-
Challenge消息发送给Authenticator，最后再由Authenticator转发给Supplicant。
·Supplicant收到EAP-Request/ MD5 Challenge消息后，将结合自己的密码对MD5
质询文进行处理，处理结果最终通过EAP-Response/ MD5 Challenge消息经由
Authenticator返回给AS。
·AS将收到RADIUS Access-Request消息和本地经过加密运算后的密码信息进行对
比，如果相同，则认为该Supplicant为合法用户，然后反馈认证成功消息（RADIUS
Access-Accept和EAP-Success）。
·Authenticator收到认证通过消息后将端口改为授权状态，允许Supplicant访问网
络。注意，有些Supplicant还会定期向Supplicant发送握手消息以检测Supplicant的在线
情况。如果Supplicant状态异常，Authenticator将禁止其上线。
·Supplicant也可以发送EAPOL-Logoff消息给Authenticator以主动要求下线。
至此，我们对EAP和802.1X进行了简单介绍，EAP和802.1X的目前是为了进行身份验
证，二者有自己的数据格式。如果没有特殊需要，掌握上述知识就可以了。
提示后续分析wpa_supplicant时还将对802.1X进行更为详尽的介绍。
下面介绍安全部分最后一个内容，RSNA。
4.RSNA介绍 [36][37]
RSNA（Robust Secure Network Association，强健安全网络联合）是802.11定义
的一组保护无线网络安全的过程，是一套安全组合拳。这套组合拳包含的过程如图3-45所
示。RSNA包括如下过程。
图3-45 RSNA过程
1）RSNA网络发现阶段。当STA扫描无线网络时，需检查Beacon帧或Probe
Response帧中是否有RSNE信息元素。如果有，STA根据RSNE处理原则选择合适的AP并
完成802.11 Authentication（设置认证类型为Open System Authentication）和
Association。
2）上一步建立的安全保护机制非常弱，所以RSNA的第二步工作是开展802.1X认证。
目的是利用802.1X认证机制实现有效安全的认证用户身份，同时还需要分配该次会话所需
要的一系列密钥用于后续通信的保护。
3）RSNA通过4-W ay Handshake和Group Key Handshake协议完成RSNA中的密钥
管理工作。密钥管理工作主要任务是确认上一阶段分配的密钥是否存在，以及确认所选用的
加密套件，并生成单播数据密钥和组播密钥用于保护数据传输。
当上面三个步骤都完成后，RSNA网络就建立成功。由上所述，我们发现RSNA包括两
个主要部分。
·在数据加密和完整性校验方面，RSNA使用了前面章节提到的TKIP和CCMP。TKIP
和CCMP中使用的TK（Temporary Key）则来自于RSNA定义的密钥派生方法。
·密钥派生和缓存。RSNA基于802.1X提出了4-W ay Handshake（四次握手协议，用
于派生对单播数据加密的密钥）和Group Key Handshake（组密钥握手协议，用于派生对
组播数据加密的密钥）两个新协议用于密钥派生。另外，为了加快认证的速度，RSNA还支
持密钥缓存。密钥派生和缓存的详情见下文。
RSNA中，我们仅介绍涉及的密钥派生和缓存。
为什么要进行密钥派生呢？它涉及密码安全方面的问题，不过其目的并不难理解。在
W EP中，所有STA都使用同一个W EP Key进行数据加密，其安全性较差。而RSNA中要求
不同的STA和AP关联后使用不同的Key进行数据加密，这也就是RSNA中Pairwise（成
对）概念的来历。
图3-46 Pairwise的概念
图3-46展示了Pairwise Key的含义，不过该图是否表明AP需要为不同的STA设置不同
的密码呢？这显然和现实情况是违背的。因为现实生活中，我们关联多个STA到同一个AP
时使用的都是相同的密码。
如何解决不同STA使用不同密码的问题呢？原来，我们在STA中设置的密码叫
PMK（Pairwise Master Key，成对主密钥），其来源有两种。
·在SOHO网络环境中，PMK来源于预共享密钥（Pre-Shared Key，PSK）。
Shared Key概念在3.3.7节介绍W EP身份验证时提到过，即在家用无线路由器里边设置的密
码，无须专门的验证服务器，对应的设置项为"W PA/ W PA2-PSK"。由于适用家庭环境，所
以有些无线路由器设置界面中也叫"W PA/ W PA2-个人"（W FA认证名为"W PA/ W PA2-
Personal"）。
·在企业级环境中，PMK和Authenticator Server（如RADIUS服务器）有关，需要
通过EAPOL消息和后台AS经过多次交互来获取。这种情况多见于企业级应用。读者可在无
线路由器设置界面中见到"W PA/ W PA2-企业"（有时叫“W PA或W PA2”，W FA认证名
为"W PA/ W PA2-Enterprise"）的安全类型选项，并且会要求设置RADIUS服务器地址。
Personal模式和Enterprise模式中PMK的来源如图3-47所示。
图3-47 PMK来源
图3-47中：
·Personal模式不需要RADIUS服务器参与。AP和STA双方的Key属于PSK，即事先
就配置好了。
·Enterprise模式下，STA、AP和RAIDUS的PMK通过多次EAPOL消息来获取。获
取的方法和具体的EAP Method有关。显然，相比Personal模式，这种方式更加安全，但
其耗费的时间也较长。
·STA和AP得到PMK后，将进行密匙派生以得到PTK。最后，PTK被设置到硬件中，
用于数据的加解密。
·由于AP和STA都需要使用PTK，所以二者需要利用EAPOL Key帧进行信息交换。
这就是4-W ay Handshake的作用。其详情见下文。
有了PMK后，AP和STA将进行密钥派生，正是在派生的过程中，AP和不同STA将生
成独特的密钥。这些密钥用于实际的数据加解密。由于STA每次关联都需要重新派生这些
Key，所以它们称为PTK（Pairwise Transient Key，成对临时Key），PTK如图3-47所
示。
提示 W FA要求目前生产的无线设备必须通过W PA2认证。
RSNA中，针对组播数据和单播数据有不同的派生方法，即单播数据和组播数据使用不
同的Key进行加密。本书仅介绍单播数据密钥的派生方法，如图3-48所示。输入PMK长256
位（如果用户设置的密钥过短，规范要求STA或AP将其扩展到256位），通过
PRF（Pseudo Random Function，伪随机数函数）并结合
S/ A（Supplicant/ Authenticator）生成的Nonce（这两个Nonce将通过4-W ay
Handshake协议进行交换）以及S/ A MAC地址进行扩展，从而派生出TKIP和CCMP用的
PTK。
图3-48 单播数据密钥派生方法
图3-48中分别描述了TKIP PTK和CCMP PTK的组成。
·EAPOL KCK（Key Confirmation Key）用于计算密钥生成消息的完整性校验值。
·EAPOL KEK（Key Encryption Key）用来加密密钥生成消息。
这两个EAPOL Key将用于后续EAPOL Key帧中某些信息的加密。TKIP TK和CCMP
TK就是TKIP和CCMP算法中用到的密钥。
明白密钥派生的作用了吗？简单来说，W EP中，网络中传输的是用同一个Key加密后的
数据，其破解的可能性较大。而TKIP和CCMP则把PMK保存在AP和STA中，实际数据加
密解密时只是使用PMK派生出来的Key，即PTK。
提示关于TKIP PTK和CCMP PTK等其他信息，请读者阅读参考资料[30]。
由于密钥派生时需要STA和AP双方的Nonce等其他一些信息，所以二者还需通过4-
W ay Handshake以交换双方的信息，其过程如图3-49所示 [24] 。
图3-49 4-W ay Handshake流程
注意 4-W ay Handshake除了用于交换STA和AP信息外，还可用于AP和STA之间相
互判断对方是否有正确的PMK。
图3-49所示的4-W ay Handshake工作过程如下。
1）Authenticator生成一个Nonce（ANonce），然后利用EAPOL-Key消息将其发
给Supplicant。
2）Supplicant根据ANonce、自己生成的一个Nonce（SNonce）、自己所设置的
PMK和Authenticator的MAC地址等信息进行密钥派生。Supplicant随后将SNonce以及
一些信息通过第二个EAPOL-Key发送给Authenticator。Message 2还包含一个MIC值，
该值会被图3-48中的KCK加密。接收端Authenticator取出Message 2中的SNonce后，也
将进行和Supplicant中类似的计算来验证Supplicant返回的消息是否正确。如果不正确，
这将表明Supplicant的PMK错误，于是整个握手工作就此停止。
3）如果Supplicant密钥正确，则Authenticator也进行密钥派生。此
后，Authenticator将发送第三个EAPOL-Key给Supplicant，该消息携带组临时密码
（Group Transient Key，GTK，用于后续更新组密钥，该密钥用图3-48中的KEK加
密）、MIC（用KCK加密）。Supplicant收到Message 3后也将做一些计算，以判断AP的
PMK是否正确。注意，图中的IGTK（Integrity GTK）用于加解密组播地址收发的管理
帧，本书不讨论。
4）Supplicant最后发送一次EAPOL-Key给Authenticator用于确认。
5）此后，双方将安装（Install）Key。Install的意思是指使用它们来对数据进行加
密。
Supplicant和Authenticator就此完成密钥派生和组对，双方可以正常进行通信了。
提示由于篇幅原因，请读者阅读参考资料[38]以了解GTK的产生和作用。另
外，4.5.5节“EAPOL-Key交换流程分析”将结合wpa_supplicant的代码详细介绍4-W ay
Handshake相关的内容。
另外，802.11还支持“混合加密”，即单播和组播使用不同的加密方法，例如单播数据
使用CCMP而组播数据使用TKIP进行加密。注意，有些加密方法不能混合使用，例如组播
数据使用CCMP加密，单播数据就不能使用TKIP。详情见参考资料[39]。
提示混合加密的主要目的是为了解决新旧设备的兼容性问题。它对应的应用场景如
下。
1）AP支持TKIP和CCMP，属于新一代的设备。
2）一些老的STA只支持TKIP，而一些新的STA支持TKIP和CCMP。
对于单播数据来说，AP和STA的密钥是成对的。所以对于老STA，AP和它们协商使用
TKIP。对于新STA，AP和它们协商使用CCMP。而对于组播数据来说，所有STA、AP都
使用同一个密钥，加解密方法也只能是一样的。在这种情况下，大家只能使用TKIP而不能
使用CCMP对组播数据进行加解密了。
下面我们来介绍密钥缓存。
根据前述内容可知，PMK是密钥派生的源，如果认证前，STA没有PMK，它将首先利
用图3-47右图所示的802.1X协商步骤以获取PMK（当然，对于SOHO环境中所使用的PSK
而言，则不存在这种情况）。由于802.1X协商步骤涉及多次帧交换，故其所花费时间往往
较长。在这种情况下，STA缓存这个得来不易的PMK信息就可消除以后再次进行802.1X协
商步骤的必要，从而大大提升整个认证的速度。
根据802.11规范，PMK缓存信息的名称叫PMKSA（PMK Security Association），
它包括AP的MAC地址、PMK的生命周期（lifetime），以及PMKID（PMK IDentifier，
用于标示这个PMKSA，其值由PMK、AP的MAC地址、STA的MAC地址等信息用Hash计
算得来）。
当STA和AP进行关联（或重关联）时：
·STA首先根据AP的MAC地址判断自己是否有缓存了的PMKSA，如果有则把PMKID
放在RSNE中然后通过Association/ Reassociation Request发送给AP。
·AP根据这个PMKID再判断自己是否也保持了对应的PMKSA。如果是，双方立即进
入4-W ay Handshake过程，从而避免802.1X协商步骤。
5.无线网络安全相关知识总结
本节对无线网络安全技术进行一个总体介绍，其中所涉及的概念、缩略词较多，这里给
读者简单总结一下其中的逻辑关系。
无线网络安全要解决的是数据的Confidentiality和Integrity以及使用者的
Authentication这三个问题。
·规范最早定义的W EP本来目的是解决数据完整和机密性的问题，后来W EP中附带完
成了Authentication检查。不过整体保护机制非常弱。
·在802.11i正式出台前，W FA提供了安全机制比W EP强的TKIP。注意，TKIP本身只
能解决数据完整和机密性问题。而802.11i出台后，又增加了一个更强健的加密算法
CCMP（有时候也叫AES）。AES和TKIP都用于解决数据完整和机密性问题。
·为了解决Authentication问题，规范借鉴802.1X，从而引出RSNA，它包括密钥派
生、缓存等内容。
提示无线网络安全的内容非常多，读者不妨阅读参考资料[37][38]以加深理解。区分
W PA/ W PA2企业和个人用法的简单公式如下。
W PA-企业=802.1X+EAP+TKIP
W PA2-企业=802.1X+EAP+CCMP
W PA-个人=PSK+TKIP
W PA2-个人=PSK+CCMP
① RFC3748中也叫Peer，不过本文统一用Supplicant表示。
3.4 Linux Wi-Fi编程API介绍
前面一直在介绍W i-Fi规范方面的内容。从本节开始，将向读者介绍Linux平台中W i-
Fi编程方面的知识。
提示相比前文而言，本节内容较为轻松。但编程只不过是规范的某种实现，掌握规范
才是理解无线网络技术的核心。这也是本书内容组织和编排的指导原则，希望读者能认真体
会。
Linux平台上目前常用的专门针对无线网络设备编程的API有两套 [40] 。
·最早的一套API由HP公司员工Jean Tourrilhes于1997年开发，全称为Linux
W ireless Extensions。一般缩写为wex或wext。这套API使得用户空间的程序能通过
ioctl函数来控制无线网卡驱动。
·由于利用ioctl开展编程的方式不太符合Linux驱动开发的要求，后来Linux又提供了
cfg80211和nl80211两套编程接口用于替代wext。其中，cfg80211用于驱动开发，而
nl80211 API供用户空间进程使用以操作那些利用cfg80211 API开发的无线网卡驱动。
注意 ioctl不符合Linux驱动开发要求主要体现在以下两方面。
1）ioctl的原型为int ioctl（int fd，unsigned long cmd，…），最后省略号代表它
支持可变个数的参数。但对于一个经过严格定义的系统调用来说，支持可变个数参数的做法
似乎显得有些随性。
2）ioctl的参数不仅个数不固定，其参数类型也无法通过函数原型来加以说明。这同样
对于一个严谨的系统调用来说，也是不可接受的。
本节将重点介绍用户空间中的W i-Fi API，wext和nl80211。不过在介绍之前，请读者
思考一个问题：为什么W i-Fi需要在用户空间进行编程呢？
答案目前的无线网卡分为两种，一种为SoftMAC。这类网卡中，MLME的处理基本
上在软件层（即驱动或用户空间），这样可带来较大的灵活性。另外，一些认证相关的操
作，也可由软件来控制。另一种网卡称为FullMAC。这类网卡的MLME全在硬件处理。相
比SoftMAC而言，其灵活性很小。所以目前市面上SoftMAC网卡占绝大多数，而
cfg80211就仅支持SoftMAC类型的网卡。
3.4.1 Linux Wireless Extensions介绍
从开发者角度来说，wext的用法相当简单。Linux平台中，wext API定义于
wireless.h文件。Android平台上，其文件位置在external/ kernel-
headers/ original/ linux目录下，主要供驱动开发者使用。
注意 bionic/ libc/ kernel/ common/ linux目录中也有一个wireless.h，不过此文件由
工具程序根据Kernel中的wireless.h自动生成而来，供用户空间使用。两个文件的区别主
要是bionic下的wireless.h包含很少的注释。所以本节将分析Kernel中的wireless.h。
Android 4.2中的wext版本为20，由wireless.h中的宏W IRELESS_EXT定义。
虽然前面提到说ioctl函数的一个缺点是其没有指明参数类型，但wext却比较严谨，提
供了自己的数据类型。
1.常用数据结构
首先，所有用户空间发起的请求都统一包括在struct iwreq中，其原型如下。
[–>wireless.h：：struct iwreq]
/*
wext API在设计时参考了系统中现有数据结构及命名方式。作为区分，wext中几乎所有数据结构、类型、宏
等名字中都带一个w以代表wireless。如下面的iwreq结构体，其对应的普通数据结构类型是ifreq。
该结构体专门用于往socket句柄传递ioctrl控制参数。
/
struct iwreq
{
union
{
char ifrn_name[IFNAMSIZ]; // 用于指定要操作的网卡设备名，如wlan0
} ifr_ifrn;
union iwreq_data u; // 用于存储具体的参数信息
};
如iwreq结构所示，具体的参数信息存储在另外一个联合体iwreq_data中，其原型如
下。
[–>wireless.h：：union：iwreq_data]
/
iwreq_data是一个联合体，其最大size为16字节。
wext还自定义了一些小的数据结构，如iw_point、iw_param、iw_freq等。它们的作用如下。
iw_point：当参数信息的长度超过16字节时，就只能通过iw_point指向另外一块内存区域，而参数就存储
在那个区域中。这个就是我们常用的指针方式。
iw_param：当参数信息不超过16字节时，可以把信息存储在iw_param中。
iw_freq：用于存储频率或信道值。其原型的介绍见本小节最后。
/
union iwreq_data
{
char name[IFNAMSIZ];
struct iw_point essid; // 存储essid，也就是ssid
struct iw_param nwid; // network id
// 频率或信道。取值为0-1000时代表channel，大于1000则代表频率，单位为Hz
struct iw_freq freq;
struct iw_param sens; // 信号强度阈值
struct iw_param bitrate; // 码率
struct iw_param txpower;
struct iw_param rts; // RTS阈值时间
struct iw_param frag;
__u32 mode; // 操作模式
struct iw_param retry;
struct iw_point encoding;
struct iw_param power;
struct iw_quality qual;
struct sockaddr ap_addr; // AP地址
struct sockaddr addr; // 目标地址
struct iw_param param; // 其他参数
struct iw_point data; // 其他字节数超过16的参数
};
当参数字节超过16的时候，wext还定义了和功能相关的参数类型，下面来看专门用于
触发无线网卡发起扫描请求的数据结构iw_scan_req，其原型如下所示。
[–>wireless.h：：struct iw_scan_req]
struct iw_scan_req
{
_u8 scan_type; // 可取值为IW_SCAN_TYPE{ACTIVE,PASSIVE}
// 代表主动或被动扫描
__u8 essid_len; // essid字符串长度
__u8 num_channels; // 指明信道个数，如果为0，则表示扫描所有可允许的信道
__u8 flags; // 目前仅用于字节对齐
// bssid用于指明BSS的地址。如果全为FF则为广播BSSID，即wildcard bssid
struct sockaddr bssid;
__u8 essid[IW_ESSID_MAX_SIZE];// essid
/
min_channel_time:指示扫描过程中在每个信道等待到第一个回复的时间。如果在此时间内没有等
到回复，跳到下一个信道等待。如果等到一个回复，则一共在该信道等待的最大时间为max_channel_time。
所有时间单位均为TU（Time Units），即1024ms。
*/
__u32 min_channel_time;
__u32 max_channel_time;
struct iw_freq channel_list[IW_MAX_FREQUENCIES];// IW_MAX_FREQUENCIES值为32
};
下面来看最后一个常见的数据结构iw_freq，其原型如下。
[–>wireless.h：：struct：iw_freq]：
// 当频率小于109，m直接等于频率。否则m=f/(10e)
struct iw_freq
{
__s32 m;
__s16 e;
__u8 i; // 该值表示此频率对象在channel_list数组中的索引
__u8 flags; // 固定或自动
};
提示 wext中的数据结构和定义还有许多，建议读者结合实际需要去学习
wireless.h。wext API虽然简单，但相信读者已经体会到其背后所依赖的和802.11规范密
切相关的理论知识了。
下面通过一个实际的例子来看看用户空间如何通过wext API来触发无线网卡扫描工作
的。
2.wext API使用实例
本例来源于wpa_supplicant，它是一个运行于用户空间的专门和无线网卡进行交互的
程序。其详情将在下一章节进行介绍。本节仅通过一个函数看看wpa_supplicant如何利用
wext API和无线网卡交互。
[–>driver_wext.c：wpa_driver_wext_scan]
int wpa_driver_wext_scan(void *priv, struct wpa_driver_scan_params *params)
{
struct wpa_driver_wext_data *drv = priv;
struct iwreq iwr; // 定义一个iwreq对象
int ret = 0, timeout;
struct iw_scan_req req; // 定义一个iw_scan_req对象
// 获取调用者传递的ssid等参数
const u8 ssid = params->ssids[0].ssid;
size_t ssid_len = params->ssids[0].ssid_len;
…
os_memset(&iwr, 0, sizeof(iwr));
// 为iwr的ifr_name传递需操作的网卡设备名
os_strlcpy(iwr.ifr_name, drv->ifname, IFNAMSIZ);
if (ssid && ssid_len) {
os_memset(&req, 0, sizeof(req));
// 设置iw_scan_req的信息
req.essid_len = ssid_len;
req.bssid.sa_family = ARPHRD_ETHER;
// 设置bssid的MAC地址全为0XFF，代表这是一个wildcard BSSID搜索
os_memset(req.bssid.sa_data, 0xff, ETH_ALEN);
os_memcpy(req.essid, ssid, ssid_len);
// 通过data域指向这个iw_sca_req对象
iwr.u.data.pointer = (caddr_t) &req;
iwr.u.data.length = sizeof(req);
// IW_SCAN_THIS_ESSID表示只扫描指定ESSID的无线网络
iwr.u.data.flags = IW_SCAN_THIS_ESSID;
}
/
ioctl_sock指向一个socket句柄，其创建时候的代码如下：
ioctl_sock = socket(PF_INET,SOCK_DGRAM,0)
SIOCSIWSCAN用于通知驱动进行无线网络扫描。
/
if (ioctl(drv->ioctl_sock, SIOCSIWSCAN, &iwr) < 0) {
// 返回错误
}
…// 其他处理
return ret;
}
提示 wext相对简单，但其内部的数据结构定义、变量命名等都和规范中定义的原语
有着莫大的关系。建议读者结合规范去阅读wireless.h以加深理解。
3.4.2 nl80211介绍
如上文所述，目前Linux平台中用于替代wext框架的是nl80211和cfg80211。其中
cfg80211供Kernel网卡驱动开发使用，而nl80211 API则供用户空间进程使用。
相比wext，nl80211的使用难度较大，因为在nl80211框架中，用户进程和Kernel通信
的手段没有使用wext中的ioctl，而是采用了netlink机制。所以，虽然nl80211.h仅是定义
了一些枚举值和有限的数据结构，但其操作却比较复杂。netlink是Linux平台上一种基于
socket的IPC通信机制，它支持：
·用户空间进程和Kernel通信。
·用户空间中进程间的通信。
不过，相比其他IPC机制，netlink最常用之处还是用户空间进程和kernel模块间的通
信。鉴于netlink的复杂性，开源世界提供了几个较为完备的基于netlink编程的框架，其中
最著名的就是libnl。而Android也充分发扬拿来主义，在其system/ core/ libnl_2目录中移
植并精简了libnl项目的代码，得到一个小巧的libnl_2工程。
本节首先介绍netlink基本知识，然后介绍libnl开源库的内容，最后结合实例介绍
nl80211的用法。
1.netlink编程 [41]
netlink是一种基于socket的IPC通信机制，所以它需要解决如下两个问题。
·寻址：即如何定位通信对象。
·双方通信的数据格式：socket编程中，通信双方传递的数据格式是由应用程序自己
决定的。那么netlink是否有其自定义的数据格式呢？
（1）netlink socket创建及绑定
netlink使用前，需要通过socket调用创建一个socket句柄，而socket函数的原型如
下。
int socket（int domain，int type，int protocol）；
对于netlink编程来说，注意以下事项。
·domain：必须设置为AF_NETLINK，表示此socket句柄将用于netlink。
·type：netlink是基于消息的IPC通信，所以该值为SOCK_DGRAM。注意，对
netlink编程来说，内核并不区分type的值是SOCK_DGRAM还是SOCK_RAW 。
·protocol：该值可根据需要设为NETLINK_ROUTE、NETLINK_NETFILTER。
不同的协议代表Kernel中不同的子系统。例如NETLINK_ROUTE代表通信对象将是
Kernel中负责route的子系统，而NETLINK_NETFILTER代表通信对象将是Kernel中负
责Netfilter的子系统，而第2章碰到的NETLINK_KOBJECT_UEVENT则代表应用程序希
望接收来自Kernel中的uevent消息。
使用netlink通信时，如何保证确保通信双方能正确定位对方呢？原来，在netlink中，
通信的另一方地址由一个数据类型为sockaddr_nl的结构体来唯一标示。该结构体的原型如
下。
[–>netlink.h]
struct sockaddr_nl {
// nl_family取值必须为AF_NETLINK或PF_NETLINK
sa_family_t nl_family;
unsigned short nl_pad; // 该值暂时无用，必须设为0
/
nl_pid看起来是用于存储进程pid的，但实际上它只是用于标示一个netlink socket。所以，用户空间
只要保证进程内该值的唯一性即可。另外，如果该值为0，表示通信的目标是Kernel。
/
__u32 nl_pid;
/
每一个netlink协议都支持最多32个多播组，加入多播组的成员都能接收到对应的多播消息。
例如NETLINK_ROUTE协议就有RTMGRP_LINK和RTMGRP_IPV4_IFADDR等多个多播组。每个多播组对应
不同的消息。之所以采用多播的方式，是因为它能减少消息发送/接收的次数。
nl_groups为0，表示只处理单播消息。
/
__u32 nl_groups;
};
设置好地址后，通过bind函数将该地址和socket句柄绑定，这样通信的另一方就正式
确定了。
关于socket创建以及bind的使用，读者可参考下面的例子。
struct sockaddr_nl sa;
memset(&sa, 0, sizeof(sa));
sa.nl_family = AF_NETLINK;
sa.nl_groups = RTMGRP_LINK | RTMGRP_IPV4_IFADDR;
// sa.nl_pid已经通过memset函数置为0了，代表此次netlink通信的目标是Kernel
fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE);
bind(fd, (struct sockaddr ) &sa, sizeof(sa));
netlink中关于protocol和多播group的取值比较分散，而且Linux的man手册更新赶
不上代码的更新速度。建议读者通过netlink.h寻找protocol的取值。通过protocol对应的
头文件去寻找多播group的定义。例如rtnetlink.h就定义了RTMGRP_LINK等多播组。
（2）netlink消息类型和标志
netlink的消息及处理是netlink编程中较为复杂的一部分。netlink中，所有消息都有
一个消息头，该头由结构体nlmsghdr表达，原型如下。
struct nlmsghdr {
__u32 nlmsg_len; // 整个消息的长度，包括消息头
__u16 nlmsg_type; // 消息类型，详情见后文
__u16 nlmsg_flags; // 附加标志
__u32 nlmsg_seq; // 消息序列号
__u32 nlmsg_pid; // 发送该消息的nl_pid。该值为0,表示数据来自内核
};
netlink定义了三种消息类型（type），分别如下。
·NLMSG_NOOP：无操作，程序可直接丢弃这类消息。
·NLMSG_ERROR：代表错误消息。这类消息携带的信息由结构体struct nlmsgerr
表达。
·NLMSG_DONE：如果某个信息的数据量较大，需要分成多个netlink消息发送的
话，NLMSG_DONE表示这是此信息最后一个消息分片包。
说实话，笔者觉得单从type值来区分netlink的消息有些不太好理解。如果从C/ S角度
来看，netlink消息可分为另外三种类型。
·Request消息：代表客户端向服务端发起的请求。这类消息必须为nlmsg_flags设置
NLM_F_REQUEST标志位。同时，客户端最好为nlmsg_seq设置一个独一无二的值，以区
分自己发送的不同请求。
·Response消息：该类消息作为服务端对客户端请求的回应。对应的消息类型是
NLMSG_ERROR。注意，如果服务器处理请求成功，也返回该值。只不过nlmsgerr的
error变量值为0。
·Notification消息：用于服务端向客户端发送通知。由于它不对应任何请求，故
nlmsg_seq一般取值为0。
基于上述讨论，读者会发现对于Response消息，无论服务端处理请求是否成功，都会
返回NLMSG_ERROR消息，其对应的数据类型是nlmsgerr，原型如下。
struct nlmsgerr {
int error; // 值为负代表错误码，值为0表示请求处理成功
// 携带对应请求消息的消息头
// 由于只返回消息头，故客户端必须根据消息头中的nlmsg_seq找到具体的消息
struct nlmsghdr msg;
};
下面来看参数nlmsg_flags，它比type复杂，常设的位值有（通过“|”运算符将不同
值“或”在一起）。
·NLM_F_REQUEST：代表请求消息。
·NLM_F_MULTI：代表消息分片中的一个。理论上说，由于nlmsghdr中的
nlmsg_len为32位，其最大消息长度可达4GB，但内核实现时，最大消息的长度只有一个页
面（一般为4KB）。如果有大于4KB的信息要传递，就需将其分成多个消息发送。除最后一
个分片消息外，其余消息都需置NLM_F_MULTI位。当然，结合上文所述，最后一个分片
消息需要设置nlmsg_type为NLMSG_DONE。
·NLM_F_ACK：该标志将强制服务端接收并处理完请求后回复ACK给客户端。
提示 netlink中nlmsg_flags的取值还有很多，感兴趣的读者可利用man 7 netlink命
令阅读相关知识。
（3）netlink消息的处理
对于socket编程来说，一般客户端会分配一个buffer用于接收数据，而后续解析该
buffer中的netlink消息其实也是一件比较麻烦的事情。另外，由于netlink对消息的大小有
字节对齐的要求，所以应用程序在构造自己的netlink消息时，也比较麻烦。不过好在
netlink为我们提供了一些帮助宏，利用这些宏，netlink消息就不再麻烦了。以下代码为
netlink消息处理时常用的一些宏。
NLMSG_ALIGN(len)// 获取len按4字节补齐后的长度。例如，如果len为1，则该宏返回的值应是4
// 整个消息包的长度，包括消息头和数据长度len。该值用于填充消息头中的nlmsg_len参数
NLMSG_LENGTH(len)
// 返回按4字节对齐后整个消息包的长度。它和NLMSG_LENGTH最大的不同是该宏将长度按4字节对齐
NLMSG_SPACE(len) // 该宏等于NLMSG_ALIGN(NLMSG_LENGTH(len))
NLMSG_DATA(nlh) // 获取消息中的数据起始地址
// 用于分片消息的处理。可获取下一条分片消息。其用法见下文例子
NLMSG_NEXT(nlh,len)
NLMSG_OK(nlh,len) // 用于判断接收到的数据是否包含一个完整的netlink消息
// 用于返回数据的长度。注意，由于netlink消息在创建时会按4字节补齐
// 所以其数据真正的长度不能通过nlms_len来判断
NLMSG_PAYLOAD(nlh,len)
下面来看一个netlink消息解析的例子，读者以后有需要，可以把它作为参考。
// 本例基于linux netlink手册。可通过man 7 netlink查阅
int len;
char buf[4096];
struct iovec iov = { buf, sizeof(buf) };
struct sockaddr_nl sa;
struct msghdr msg; // 用于recvmsg系统调用，和netlink没关系
struct nlmsghdr nh;
msg = { (void )&sa, sizeof(sa), &iov, 1, NULL, 0, 0 };
len = recvmsg(fd, &msg, 0); // recvmsg返回，可能存储了多条netlink消息
// 开始接受接收buffer，注意NLMSG_NEXT宏，其内部会对len长度进行修改，以调整到下一个消息的起始
for (nh = (struct nlmsghdr ) buf; NLMSG_OK(nh, len);
nh = NLMSG_NEXT (nh, len)) {
/ The end of multipart message. /
if (nh->nlmsg_type == NLMSG_DONE){
return; // 分片消息处理
}
if (nh->nlmsg_type == NLMSG_ERROR){
struct nlmsgerr pError = （struct nlmsgerr）NLMSG_DATA(nh);
// 获取nlmsgerr的内容
… / 错误或ACK处理/
}
void data = NLMSG_DATA(nh); // 获取数据的起始地址
…// 处理数据
}
netlink的消息收发和普通的socket消息收发一样，这里不赘述。
（4）netlink编程小结
netlink强制要求每个netlink消息都包含消息头，其实它还定义了一个名为nlattr的结
构体，用于规范载荷（Payload）的数据类型。其目的是希望Payload以属性（attribute）
的方式来描述自己。struct nlattr结构非常简单，如下所示。
struct nlattr {
__u16 nla_len; // 属性长度
__u16 nla_type; // 属性类型
};
netlink虽然复用了socket编程以方便应用程序和内核通信，但因为其文档很少，而且
不同protocol往往还有自己特定的数据结构，所以实际使用过程中难度较大。
本书不讨论nlattr及netlink其他的内容。建议读者考虑下文介绍的文档更加丰富的
libnl开源库。
2.libnl开源库
根据前文介绍，netlink API用起来相对麻烦，建议读者考虑采用libnl开源库，其官方
网站为http:/ / www.infradead.org/ ~ tgr/ libnl/ 。libnl的内容也不少，其架构如图3-50所
示。
图3-50 libnl架构
由图3-50可知，以下三个库都基于其核心库libnl。
·libnl-route：用于和Kernel中的Routing子系统交互。
·libnl-nf：用于和Kernel中的Netfilter子系统交互。
·libnl-genl：用于和Kernel中的Generic Netlink模块交互。
提示从图也可看出netlink使用的复杂性。
Android平台移植并精简了libnl和libnl-genl中的部分内容，得到了libnl_2（2表示
libnl工程的版本号，最新版为3），目录在system/ core/ libnl_2文件夹下。
本节介绍libnl中的一些常用API。详细内容还请读者参考其官方网站中的文档，地址为
http:/ / www.infradead.org/ ～tgr/ libnl/ doc/ core.html。
（1）nl_sock结构体的使用
libnl以面向对象的方式重新封装了netlink原有的API。其使用时必须分配一个
nl_sock结构体。下面展示了和它相关的一些API及使用方法。
#include
// 分配和释放nl_sock结构体
struct nl_sock *nl_socket_alloc(void)
void nl_socket_free(struct nl_sock *sk)
// nl_connet内部将通过bind函数将netlink socket和protocol对应的模块进行绑定
int nl_connect(struct nl_sock *sk, int protocol)
linbl还可为每个nl_sock设置消息处理函数，相关API如下。
// 为nl_sock对象设置一个回调函数，当该socket上收到消息后，就会回调此函数进行处理
// 回调函数及参数封装在结构体struct nl_cb中
void nl_socket_set_cb(struct nl_sock *sk, struct nl_cb *cb);
// 获取该nl_sock设置的回调函数信息
struct nl_cb *nl_socket_get_cb(const struct nl_sock sk);
注意，以上两个函数没有文档说明。建议使用另外一个控制力度更为精细的API。
/
此API对消息接收及处理的力度更为精细，其中：
type类型包括NL_CB_ACK、NL_CB_SEQ_CHECK、NL_CB_INVALID等，可用于处理底层不同netlink消息的情况。
例如，当收到的netlink消息无效时，将调用NL_CB_INVALIDE设置的回调函数进行处理。
nl_cb_kinds指定消息回调函数的类型，可选值有NL_CB_CUSTOM，代表用户设置的回调函数，NL_CB_DEFAULT
代表默认的处理函数。
回调函数的返回值包括以下。
NL_OK:表示处理正常。
NL_SKIP：表示停止当前netlink消息分析，转而去分析接收buffer中下一条netlink消息（消息分
　片的情况）。
NL_STOP：表示停止此次接收buffer中的消息分析。
*/
int nl_socket_modify_cb(struct nl_sock *sk,
enum nl_cb_type type, enum nl_cb_kind kind,
nl_recvmsg_msg_cb_t func, void *arg);
另外，netlink还可设置错误消息（即专门处理nlmsgerr数据）处理回调函数，相关
API如下。
#include // 必须包含此头文件
// 设置错误消息处理
int nl_cb_err(struct nl_cb cb, enum nl_cb_kind kind,
nl_recvmsg_err_cb_t func, void * arg);
typedef int( nl_recvmsg_err_cb_t)(struct sockaddr_nl *nla,
struct nlmsgerr *nlerr, void *arg);
（2）libnl中的消息处理
libnl定义了自己的消息结构体struct nl_msg。不过它也提供API直接处理netlink的
消息。常用的API如下。
#include // 必须包含这个头文件
// 下面这两个函数计算netlink消息体中对应部分的长度
int nlmsg_size(int payloadlen); // 请参考图来理解这两个函数返回值的意义
int nlmsg_total_size(int payloadlen);
关于netlink消息的长度如图3-51所示。
图3-51 nlmsg消息长度的计算
其他可直接处理netlink消息的API如下。
struct nlmsghdr *nlmsg_next(struct nlmsghdr *hdr, int *remaining);
int nlmsg_ok(const struct nlmsghdr *hdr, int remaining);
/*定义一个消息处理的for循环宏，其值等于
for (int rem = len, pos = head; nlmsg_ok(pos, rem);
pos = nlmsg_next(pos, &rem))
*/
#define nlmsg_for_each(pos,head,en)
开发者也可以通过libnl定义的消息结构体nl_msg进行相关操作，和nl_msg有关的API
如下。
struct nl_msg *nlmsg_alloc(void);
void nlmsg_free(struct nl_msg *msg);
// nl_msg内部肯定会指向一个netlink消息头实例，下面这个函数用于填充netlink消息头
struct nlmsghdr *nlmsg_put(struct nl_msg *msg,
uint32_t port, uint32_t seqnr,
int nlmsg_type, int payload, int nlmsg_flags);
（3）libnl中的消息发送和接收
netlink直接利用系统调用（如send、recv、sendmsg、recvmsg等）进行数据收发，
而libnl封装了自己特有的数据收发API。其中和发送有关的几个主要API如下。
// 直接发送netlink消息
int nl_sendto (struct nl_sock *sk, void *buf, size_t size)
// 发送nl_msg消息
int nl_send (struct nl_sock *sk, struct nl_msg *msg)
int nl_send_simple(struct nl_sock *sk, int type,
int flags,void *buf, size_t size);
常用的数据接收API如下。
// 核心接收函数。nla参数用于存储发送端的地址信息。creds用于存储权限相关的信息
int nl_recv(struct nl_sock *sk, struct sockaddr_nl *nla,
unsigned char **buf, struct ucred **creds)
// 内部通过nl_recv接收消息，然后通过cb回调结构体中的回调函数传给接收者
int nl_recvmsgs (struct nl_sock *sk, struct nl_cb *cb)
（4）libnl-genl API介绍 [41]
由图3-50可知，libnl-genl封装了对generic netlink模块的处理，它基于libnl。
Linux中关于generic netlink的说明几乎没有，建议大家参考libnl中的说明。一条genl消
息的结构如图3-52所示。
图3-52 genl消息结构
其中，genlmsghdr的原型如下。
struct genlmsghdr {
__u8 cmd; // cmd和version都和具体的案例有关
__u8 version;
__u16 reserved; // 保留
};
genl常用的API如下。
// 和libnl的nl_connect类型，只不过协议类型为GENERIC_NETLINK
int genl_connect (struct nl_sock sk)
// genlmsg_put用于填充图中的nlmsghdr、genlmsghder和用户自定义的消息头。详细内容见下文
void genlmsg_put (struct nl_msg msg, uint32_t port,
uint32_t seq, int family, int hdrlen,
int flags, uint8_t cmd, uint8_t version)
// 用于获取genl消息中携带的nlattr内容
struct nlattr genlmsg_attrdata(const struct genlmsghdr *gnlh,int hdrlen)
另外，genl还有几个比较重要的API，它们和genl机制的内核实现有关，这里仅简单介
绍其中几点内容。为实现genl机制，内核创建了一个虚拟的Generic Netlink Bus。所有
genl的使用者（包含内核模块或用户空间进程）都会注册到此Bus上。这些使用者注册时，
都需要填充一个名为genl_family的数据结构，该结构是一种身份标示。所以某一方只要设
置好genlmsg_put中的family参数，数据就能传递到对应的模块。
family是一个整型，可读性较差，所以genl使用者往往会指定一个字符串作为family
name。而family name和family的对应关系则由genl中另外一个重要模块去处理。这个模
块就是genl中的Controller，它也是Generic Bus使用者。其family name为"nlctrl"，只
不过它的family是固定的，目前取值为16（一般为它定义一个NETLINK_GENERIC
宏）。Controller的一个重要作用就是为其他注册者建立family name和family之间关系，
也就是动态为其他注册者分配family编号。另外，Controller也支持查询，即返回当前
Kernel中注册的所有genl模块的family name和family的值。
对用户空间程序来说，只要知道family的值，就可和指定模块进行通信了。libnl-genl
封装了上述操作，并提供了几个常用的API。
// 根据family name字符串去查询family，该函数内部实现将发送查询消息给Controller
int genl_ctrl_resolve (struct nl_sock *sk, const char name)
/
如果每次都向Controller去查询family编号将严重影响效率，所以libnl-genl会把查询到的信息
缓存起来。
下面这个函数将分配一个nl_cache列表，其内容存储了当前注册到Generic Netlink Bus上所有注
册者的信息。
*/
int genl_ctrl_alloc_cache (struct nl_sock *sk, struct nl_cache **result)
// 根据family name从缓存中获取对应的genl_family信息
struct genl_family * genl_ctrl_search_by_name
(struct nl_cache *cache, const char *name)
提示相比直接使用netlink API，libnl对开发者更加友好，即使libnl封装得再
好，netlink编程依然不是一件轻松的事情。目前为止，笔者还没有找到一篇文档能全面描
述netlink中的protocol及对应的多播组、genl中Controller模块所支持的命令等至关重要
的知识点。当年在W indows平台做开发时，微软为开发者提供的编程文档中不仅有原理性
说明，还有很多编程技巧。这些内容对开发者而言都是无价之宝。不过，指望Linux重新修
订、增补文档无疑是一件异想天开的事情。在此笔者也只能希望读者们在学习过程中注意收
集资料并和大家一起分享了。
3.nl80211实例
了解netlink和libnl之后，现在来看nl80211。简单来说，nl80211的核心就是通过
netlink机制向Kernel中的无线网卡驱动发送特定的消息。只不过这些消息的类型、参数等
都由nl80211.h定义。此处通过一个案例，学习如何通过nl80211触发网卡进行无线网络扫
描。
[–>driver_nl80211.c：：wpa_driver_nl80211_scan]
static int wpa_driver_nl80211_scan(void *priv,
struct wpa_driver_scan_params *params)
{
struct i802_bss *bss = priv;
struct wpa_driver_nl80211_data *drv = bss->drv;
int ret = -1, timeout;
struct nl_msg *msg, *rates = NULL; // 定义两个nl_msg对象，rates和P2P有关，读者可忽略它
drv->scan_for_auth = 0;
// 创建nl80211消息，其中NL80211_CMD_TRIGGER_SCAN是Nl80211定义的命令，用于触发网络扫描
msg = nl80211_scan_common(drv, NL80211_CMD_TRIGGER_SCAN, params);
…// P2P 处理
// 发送netlink消息
ret = send_and_recv_msgs(drv, msg, NULL, NULL);
msg = NULL;
if (ret)
goto nla_put_failure;
…// wpa_supplicant其他处理
…// 错误处理
return ret;
}
上面代码中构造无线网络扫描nl_msg的重要函数nl80211_scan_common代码如下所
示。
[–>driver_nl80211.c：：nl80211_scan_common]
static struct nl_msg * nl80211_scan_common
(struct wpa_driver_nl80211_data *drv, u8 cmd,
struct wpa_driver_scan_params *params)
{
struct nl_msg msg;
int err;
size_t i;
// 分配一个nl_msg对象
msg = nlmsg_alloc();
/
调用nl80211_cmd函数填充nl_msg中的信息，其内部代码如下。
static void * nl80211_cmd(struct wpa_driver_nl80211_data *drv,
struct nl_msg *msg, int flags, uint8_t cmd){
return genlmsg_put(msg, 0, 0, drv->global->nl80211_id,0, flags, cmd, 0);
}
/
nl80211_cmd(drv, msg, 0, cmd);
/
nl80211消息的参数通过netlink中的nlattr来存储。NL80211_ATTR_IFINDEX代表
此次操作所指定的网络设备编号。
*/
nla_put_u32(msg, NL80211_ATTR_IFINDEX, drv->ifindex);
if (params->num_ssids) {
struct nl_msg *ssids = nlmsg_alloc();
for (i = 0; i < params->num_ssids; i++) {
nla_put(ssids, i + 1, params->ssids[i].ssid_len,params->ssids[i].ssid);
…
}
// netlink支持消息嵌套，即属性中携带的数据可以是另外一个nl_msg消息
err = nla_put_nested(msg, NL80211_ATTR_SCAN_SSIDS, ssids);
nlmsg_free(ssids);
…
}
…// 其他处理
return msg;
…// 错误处理
}
由上面的例子可知，nl80211其实就是利用netlink机制将一些802.11相关的命令和参
数发送给驱动去执行。这些命令和参数信息可通过nl80211头文件查询。
提示本书后续章节将分析wpa_supplicant8，读者可参考
external/ wpa_supplicant8/ wpa_supplicant/ src/ drivers/ nl80211_copy.h。
首先，nl80211_copy.h定义其支持的命令，如下所示。
[–>nl80211_copy.h]
enum nl80211_commands {
NL80211_CMD_UNSPEC,
NL80211_CMD_GET_WIPHY,
NL80211_CMD_SET_WIPHY,
…
NL80211_CMD_GET_INTERFACE,
NL80211_CMD_SET_INTERFACE,
…
NL80211_CMD_SET_BSS,
NL80211_CMD_SET_REG,
…// 一共定义了94条命令
}
然后定义属性的取值，如下所示。
enum nl80211_attrs {
NL80211_ATTR_UNSPEC,
NL80211_ATTR_WIPHY,
NL80211_ATTR_WIPHY_NAME,
NL80211_ATTR_IFINDEX,
NL80211_ATTR_IFNAME,
NL80211_ATTR_IFTYPE,
NL80211_ATTR_MAC,
…// 一共定义了155条属性
}
头文件中对命令、属性等信息的注释都非常详细。本节不赘述，请读者自行阅读该文
件。
提示相比wext而言，nl80211的使用难度明显要复杂，其中重要原因是它是基于
netlink编程的。而且，如果没有libnl的支持，相信使用难度会更大。但从W i-Fi角度来
看，nl80211和wext到没有太大区别，二者都是紧紧围绕MAC层service来设计数据结构
的。
3.5 本章总结和参考资料说明
3.5.1 本章总结
本章是全书关于W i-Fi技术方面的一篇基础文章，涉及面很广，内容也很杂，需要读者
耐心阅读并理解。从大体上来说，本章按如下逻辑开展。
·首先简单介绍无线频谱资源和802.11发展历程。
·为了帮助读者真正看懂802.11规范，本章介绍了OSI/ RM模型以及其中关于Entity、
SAP、MIB等基本概念。
·接着正式介绍802.11规范中的一些重要内容，包括无线网络组件、网络结构、无线网
络提供的服务等。
·在上述基础上，着重对802.11 MAC层进行了介绍，包括MAC帧格式、MLME等。
这部分内容是理解后续章节关于wpa_supplicant介绍的核心。
·然后解决802.11的安全性问题。建议读者从机密性、完整性和身份验证三个方面来理
解其中的各种安全保护方法。
·本章最后对Linux W i-Fi API进行了介绍，目前用得最多的应该是nl80211。不过读
者可先从简单的wext开始学习。
提示本章是笔者从事Android写作以来耗时最长的一章（包括学习时间长达3个多
月，而且还有很多技术点未能覆盖）。在这个过程中，笔者也经历过烦恼和痛苦，感觉比纯
粹的代码分析难度要大。这也是笔者希望读者把注意力放到代码背后的理论上来的初衷。从
下一章开始，在分析wpa_supplicant的同时，通过背景知识介绍的方式来补充本节没有涵
盖的内容。
3.5.2 参考资料说明
1.概述
[1] 《Real 802.11 Security：W i-Fi Protected Access and 802.11i》7.1
节"Relationship Between W i-Fi and IEEE 802.11"
说明：本书是笔者找到的关于802.11无线网络安全技术方面知识面最完整的书籍。是英
文版，需要掌握W i-Fi的基础知识后才能真正理解。
2.无线电频谱知识
[2] 《802.11无线网络权威指南（第2版）》P16-P17，“无线电频谱：关键资源”
说明：此书是目前市面上关于802.11无线网络书籍的“圣经”。不过其排版奇特，连章
节号都没有，读起来着实有些费劲。读者可首先阅读这本书以对W i-Fi有个基本了解。另
外，该书涉及物理层的内容可以略去不读。
[3] 《802.11无线网络权威指南（第2版）》“无线网络导论”一节，P20-P22
[4] http:/ / baike.baidu.com/ view/ 345218.htm
说明：百度百科词条“802.11”。笔者对其内容做了必要的增删改。
3.OSI基本参考模型及相关基本概念
[5] ISO/ IEC 7498-1"Basic Reference Model：The Basic Model"
说明：OSI模型的官方文档，不过和其他官方文档一样，极难理清楚其间的逻辑关系，
做手册使用还可以。
[6] http:/ / baike.baidu.com/ view/ 486949.htm
说明：百度百科词条“开放系统互连参考模型”。
[7] ISO/ IEC 8802-2"Part 2 Logical Link Control"
说明：Logical Link Control层的官方标准。读者只需阅读第一节"Overview"。
4.CSMA/ CA介绍
[8] http:/ / baike.baidu.com/ view/ 645723.htm
说明：百度百科词条"CSMA/ CA"，以通俗的方式解释了CSMA/ CA的工作原理。也可
参考《802.11无线网络权威指南（第2版）》第3章，P47-P55。
5.MAC层Service及其他概念
[9] IEEE 802.1X-2010"Port-Based Network Access Control"，Annex D"Basic
architectural concepts and terms"
说明：大名鼎鼎的802.1X规范。不过这些规范引用的其他标准非常多，所以802.1X在
附录D中对一些基本概念和术语进行了一番介绍。建议读者阅读此文档。
[10] http:/ / www.doc88.com/ p-696270935777.html
说明：SO/ IEC 15802-1电子文档，由doc88提供。全名为"Part 1：Medium Access
Control（MAC）service definition"，定义了MAC service和相关的原语。
6.MIB介绍
[11] http:/ / en.wikipedia.org/ wiki/ Management_information_base
说明：维基百科词条"Management Information Base"。英文介绍，比较容易理解。
7.802.11组件
[12] 《802.11-2012》4.1节"General description of the architecture"、4.2
节"How W LAN systems are different"、4.3节"Components of the IEEE 802.11
architecture"
8.802.11 Service介绍
[13] 《802.11-2012》4.5节"Overview of the Services"
说明：注意，《802.11-2012》第4章非常重要，里边的许多基本概念都需要了解。该
节包括的内容非常多，读者应有选择地阅读。
9.802.11 MAC服务和帧
[14] 《802.11-2012》第5章"MAC service definition"
说明：对802.11 MAC服务进行了完整说明。
[15] 《802.11-2012》第8章"Frame formats"
说明：802.11 MAC帧完整说明。读者可当做手册来用。
[16] http:/ / technet.microsoft.com/ en-us/ library/ cc757419（v=ws.10）.aspx
说明：微软技术文章"How 802.11 W ireless W orks"。通俗易懂，包含的知识面也比较
全。读者可通过它对802.11有一个大致的认识。
[17] 《802.11无线网络权威指南（第2版）》第4章“802.11成帧细节”，P78-P127
[18] 《802.11无线网络权威指南（第2版）》第8章中的“节省电力”，P200-P208
说明：非常详细地介绍了Power Save的原理和过程。
[19] 《802.3-2008》“CSMA/ CD Access Method and Physical Layer
Specifications"3.2.3节"Address fields”
说明：LAN中MAC层的官方文档。其中有对MAC地址格式的说明。
[20] http:/ / www.doc88.com/ p-905531556977.html
说明：doc88上关于MAC组播地址的中文说明。建议读者阅读此文档。
[21] 《802.11无线网络权威指南（第2版）》第3章中的“802.11对上层协议的封
装”，P65-P66
10. 802.11 MAC管理实体
[22] 《802.11-2012》第6章"Layer management"
说明：MLME的官方说明，非常详细。请读者当手册使用。
[23] 《802.11无线网络权威指南（第2版）》第8章“管理操作”，P182-P224
说明：逻辑还算清晰，建议读者结合参考资料[22]一起阅读。
[24] 《802.11-2012》4.10节"IEEE Std 802.11 and IEEE Std 802.1X-2004"
说明：介绍802.1X如何与802.11相结合。
11. W EP介绍
[25] 《802.11无线网络权威指南（第2版）》第5章“有线等效加密”，P127-P142
说明：关于W EP的详细介绍。但有些内容用得非常少（例如关于动态W EP密匙的说
明）。
[26] 《802.11-2012》11.2.2节"W ired Equivalent Privacy（W EP）"
说明：官方对W EP的说明，非常详细。
[27] 《802.11-2012》11.2.3节"Pre-RSNA authentication"
说明：官方对W EP中身份验证方法的说明。
[28]
http:/ / documentation.netgear.com/ reference/ ita/ wireless/ pdfs/ FullManual.pdf
说明：“W ireless Networking Basics”，Netgear公司提供的关于W i-Fi安全方面的一
些简单介绍。
12. RSN数据加密及完整性校验
[29] 《802.11-2012》11.4节"RSNA confidentiality and integrity protocols"
说明：官方文档关于TKIP和CCMP的介绍。
[30] 《802.11无线网络权威指南（第2版）》第7章"802.11：RSN、TKIP与
CCMP"，P162-P176
说明：请读者结合参考资料[29]研究。
13. EAP和802.1X介绍
[31] RFC3748"Extensible Authentication Protocol（EAP）"
说明：EAP的官方文档，共68页，难度不是特别大，建议读者阅读全文。
[32] http:/ / en.wikipedia.org/ wiki/ IEEE_802.1X
说明：维基百科词条"IEEE 802.1X"。图文并茂，读者可仔细阅读此文。
[33] 《802.11无线网络权威指南（第2版）》第6章“802.1X用户身份验证”，P142-
P154
[34]
http:/ / www.h3c.com.cn/ Products___Technology/ Technology/ Security_Encrypt/ Other_technology/ Te
说明：H3C公司关于802.1X的介绍，非常详细，难度较小。读者可先阅读此文档。
[35] 《802.1X-2010》第11章"EAPOL PDUs"
说明：官方对EAPOL格式的详细说明。
14. RSNA介绍
[36] http:/ / www.docin.com/ p-439759696.html
说明：“一种针对RSNA无线网络的安全等级回滚攻击研究”，来自豆丁网。3页内
容，比较容易理解。
[37] 《Real 802.11 Security：W i-Fi Protected Access and 802.11i》第7
章"W PA，RSN，and IEEE 802.11i"和第9章"W PA and RSN Key Hierarchy"
说明：此书是目前笔者找到的关于W i-Fi安全性方面覆盖面最齐全的资料。建议读者深
入阅读。
[38] 《802.11-2012》11.6节"Keys and key distribution"
说明：官方文档关于密匙派生的说明。
[39] 《802.11无线网络权威指南（第2版）》第7章"802.11：RSN、TKIP与
CCMP"，P176-P182
说明：介绍了RSN的运作方式，对密匙派生和缓存有较为详细的说明。
15. Linux W i-Fi编程API
[40] http:/ / wireless.kernel.org/ en/ developers/ Documentation/ W ireless-
Extensions
说明：Linux W ireless Kernel官方网站，内容非常丰富。建议读者仔细阅读。
16. netlink编程
[41] http:/ / www.infradead.org/ ～tgr/ libnl/
说明：libnl官方网站，文档较为丰富。读者可阅读其中关于libnl的文档。

Android 系统 wifi基础知识

你可能感兴趣的:(android系统开发,android)