1. 建链流程全景一次Wi-Fi连接背后的四次握手很多人调试无线网络时习惯用“连不上”三个字概括一切问题。但如果你真正想搞懂802.11必须建立一个基本认识一次看似简单的连接实际上是一条被协议严格规定好的流水线。从手机打开Wi-Fi开关到右上角出现小扇子图标中间经历的是“扫描—认证—关联—安全握手”这四个阶段任何一步出错结果都不同。以我自己调试AP的体会来说绝大多数“连不上”的问题其实都能在某个具体阶段找到对应的失败信号。比如搜不到SSID问题基本出在扫描阶段能搜到但一直转圈大概率卡在认证或关联阶段能连上但拿不到IP问题在DHCP而不是802.11建链连上几分钟就掉线则多半跟加密握手后的密钥管理有关。换句话说如果你能把802.11建链这条链路拆解清楚排障思路就会非常清晰先定位到阶段再分析该阶段对应的帧交互远比随机改信道、重启路由器高效得多。下面我用一整篇文章把“从发现网络到安全建链”这条802.11入门主干拆开揉碎。内容覆盖扫描机制、帧类型、状态机、四次握手与WPA3的SAE流程最后还会分享实际抓包排错的经验。无论你是刚接触无线协议的学生还是需要排查企业级无线问题的网工这条主线吃透了再去看漫游、Mesh、802.11ax这些进阶内容都会觉得顺理成章。要理解整条链路先记住802.11定义的一个状态机。站点STA和接入点AP之间的通信严格遵循四个状态迁移State 1未认证、未关联。这时站点只能发认证帧或者去被动收听Beacon。State 2已认证、未关联。认证通过后站点可以和AP交换关联请求但还不能传业务数据。State 3已认证、已关联。此时802.11层面的链路已经建立但如果是受保护网络还需要完成安全握手才能发数据。State 4已认证、已关联且完成了安全建链。这才是真正可以收发业务数据的完整状态。搞清楚这个状态机你就有了贯穿全文的线索。后面的扫描、认证、关联、安全建链本质上是让站点在这四个状态之间逐级推进的过程。2. 发现网络Beacon广播与Probe主动探测的协同机制2.1 被动扫描Beacon就是AP在喊话先从一个最常见的场景出发你打开手机Wi-Fi列表几秒钟内看到一堆SSID。这些名字是怎么被手机知道的两种方式被动扫描和主动扫描。被动扫描的门槛最低手机不需要发任何帧只需要把自己调到某个信道上持续监听该信道上的Beacon帧。Beacon帧是AP周期性地向周围广播的管理帧默认每100ms发一次里面携带了网络的核心信息。我抓包时最爱看Beacon帧因为它的信息密度非常高。一个典型的Beacon帧里至少包含SSID网络名字最长32字节BSSIDAP的MAC地址支持的速率从1Mbps到若干百Mbps的速率集合信道信息DS参数集告诉站点自己在哪个信道能力信息是否启用加密、是否启用短前导码、是否支持802.11n/ac/ax等RSN信息如果有WPA/WPA2/WPA3这里会列出加密套件和认证套件。被动扫描最大的好处是省电因为站点只需要开着接收机监听即可。但它的缺点也很明显一是AP必须持续发送Beacon才能被发现。企业级AP的Beacon间隔默认是100TUTU 1024微秒约0.1秒如果某台AP配置了Beacon间隔为500TU手机经过时就要等更久才能听到。二是存在隐藏SSID的情况。有些网络管理员喜欢把自己家的SSID设为“不广播”也就是Beacon帧里的SSID字段置空。这就导致被动扫描根本看不见它。记住隐藏SSID并不能真正防蹭网它最多算“对普通人隐藏”因为主动扫描可以直接把它挖出来。2.2 主动扫描Probe Request和Probe Response主动扫描是手机主动发出的“找人”过程。站点在每个信道上发送Probe Request帧AP收到后回复Probe Response帧。Probe Request有两种玩法带SSID的定向扫描手机知道自己要连的SSID直接广播“谁是XXX网络”只有匹配的AP会回复。不带SSID的广播扫描手机发送空SSID的Probe Request相当于“有哪些AP在”所有听到的AP都会回复。这里有个有意思的细节即使AP配置了隐藏SSID只要站点在Probe Request里填了那个SSIDAP依然会回Probe Response并且带SSID信息。所以隐藏SSID在网络层面就是个“通过诚实方式藏起来、遇到追问就坦白”的设置安全价值极其有限。Probe Response帧里携带的信息跟Beacon差不多区别在于它是主动应答更具针对性。从排障视角看主动扫描能更快发现AP因为站点不用等一个完整Beacon周期。2.3 扫描阶段的实用要点我在实际调试中扫描阶段有几个经验值得说一下。第一个是信道切换速度与省电模式的冲突。站点做主动扫描时需要从一个信道跳到另一个信道而这段时间里它无法正常接收正在使用的信道上的帧。所以很多驱动会先把待机状态挂起快速扫一圈再回到原信道。如果你发现某台终端信道切换特别慢可以检查驱动是否支持background scan机制。第二个是被动扫描接收Beacon时的信号强度参考。Beacon帧的RSSI是你判断信号覆盖是否达标的最直接依据。如果手机在某个位置根本收不到Beacon或者收到但RSSI低于-85dBm那问题大概率出在覆盖上而不是关联握手。我见过很多人死磕密码和加密参数结果最后发现把AP挪个位置就全好了这就是没有先做扫描阶段定位的典型症状。第三个是Probe Request中携带的能力集会被AP纳入是否允许接入的决策。比如只支持802.11b的终端连接一个仅开放802.11n/ac的APAP可能不回复Probe Response。企业环境里遇到“明明SSID存在却连不上”先看终端能力和AP配置是否匹配这一点很多人会忽略。3. 认证与关联开放系统Authentication到底认了什么3.1 先搞清楚认证不等于输密码很多刚接触802.11的人会被“Authentication”这个词带偏。这里必须先纠正一个误区802.11协议里的Authentication认证步骤并不负责验证你输入的Wi-Fi密码。那这一步到底做了什么在早期802.11标准里Authentication有两种模式开放系统认证Open System Authentication过程极其简单站点发一个Authentication帧AP回一个成功状态码完事。它不验证任何身份。共享密钥认证Shared Key AuthenticationAP发送一个挑战文本站点用WEP密钥加密后发回AP解密比对。严格说这才算有“验证”的味道但因为WEP本身的加密算法已经被攻破这种方式现在基本绝迹。所以现实中的WPA/WPA2/WPA3网络建链流程里有Authentication步骤但它本质上是“打个招呼”真正的密码校验全部留到后面的安全握手阶段。这在抓包里非常明显你会看到Authentication帧只有寥寥几个内容简单到几乎没有信息量状态码为0表示成功。如果这一步失败往往是AP对客户端做了MAC过滤或者糟糕的配置导致AP直接拒绝一切认证请求。3.2 状态迁移从State 1到State 2当站点发出Authentication RequestAP回复Authentication Response成功状态就由State 1迁移到State 2。此时站点具备“继续往下走”的资格但它还不能发送任何数据帧。有个细节值得注意Authentication帧的接收方地址是AP的BSSID发送方是站点的MAC地址。如果你在抓包里看到连续的Authentication重传retry位为1说明AP根本没收到请求或者没来得及应答最常见的原因是远端信号太弱或者AP正忙到无暇处理管理帧。3.3 关联告诉AP我要加入接下来是Association Request/Response这一步的意义是让站点正式加入AP管理的BSS。站点把自己的能力信息、支持的速率、监听间隔Listen Interval告诉APAP评估后决定是否允许。关联请求里有几个字段值得关注能力信息Capability Info声明站点是否支持短前导码、是否支持频谱管理等支持速率AP会拿站点支持的速率跟自己的配置比对如果有交集才能关联监听间隔站点告诉AP自己在省电模式下多久醒来一次AP据此决定暂存下行帧的时间。关联成功后状态从State 2迁移到State 3。此时802.11链路算是“连上”了你会在手机通知栏看到Wi-Fi图标出现但这不代表能上网。在802.11标准里关联其实有两种形式关联Association适用于BSS这是家用路由器的场景。重关联Reassociation站点从一个AP漫游到另一个AP时使用网络侧需要完成上下文的迁移。企业里如果碰到漫游掉线问题抓包时看到的就是Reassociation相关帧这个以后可以单独展开。3.4 认证与关联失败的常见原因老实说认证和关联这两个阶段本身逻辑简单失败原因更多集中在外围因素。我从实际碰到的案例里整理一下第一MAC过滤。AP端启用MAC白名单站点不在名单内时Authentication Request会直接收到失败响应。这类问题在协议帧里看得很清楚——状态码是非零值。第二Rate过速问题。站点支持的速率与BSS速率策略完全不匹配时关联阶段会被AP拒绝。尤其是某些老物联网设备只支持802.11b的1Mbps遇到AP已经关闭低速率支持后关联帧直接被丢弃。第三管理帧干扰。信道里如果有大量别的干扰源Authentication/Association这类管理帧因为没有任何保护机制一旦被干扰就重传重传多了站点就放弃。很多人遇到“能扫到但连不上”的问题去检查是不是存在同频干扰比怀疑AP本身坏了更靠谱。4. 安全建链从PMK到四次握手的完整密钥旅程4.1 为什么WEP沦为历史而WPA2采用了四次握手进入安全建链阶段才有真正的密码学运算。前提是你连的是一个受保护网络WPA/WPA2/WPA3如果连的是完全开放的AP那State 3就已经到头了但这在安全上极其危险我不建议任何场景下使用纯开放网络。在这一阶段核心问题是站点和AP如何在没有预置共享密钥分发通道的情况下协商出一把用于加密数据的会话密钥。如果我们回到WEP时代设计者犯的错误是预共享密钥也就是你的Wi-Fi密码和IV拼接后直接做RC4加密密钥流被重用很快就被破解。WPA2从根上改变了思路用四次握手生成的**成对临时密钥PTK**加密数据而不是直接用预共享密钥。预共享密钥只作为“种子”参与计算不直接参与数据加密。这套机制的完整术语是这样的PSK/PMK预共享密钥Pre-Shared Key或成对主密钥Pairwise Master Key。在家用场景中用户输入的密码通过PBKDF2派生成了PMK通常长度为256比特。PTK成对临时密钥Pairwise Transient Key由PMK、ANonce、SNonce和双方的MAC地址一起通过伪随机函数生成。GTK组临时密钥Group Temporal Key用于AP向组播/广播数据加密每个关联站点共享同一把。4.2 四次握手的每一步在保护什么四次握手是整个WPA2流程中最重要也最好玩的部分我们一句一句拆第一步AP发送EAPOL-Key帧包含ANonceAP生成一个随机数ANonce发送给站点。此时双方都没有足够信息生成PTK因为还缺站点选择的SNonce。第二步站点回复EAPOL-Key帧包含SNonce MIC站点收到ANonce后自己生成一个随机数SNonce。现在站点手里有PMK、ANonce、SNonce、双方MAC地址。它可以用这些计算出PTK。然后在回复帧中附带MIC消息完整性校验码这个MIC是拿PTK的KCK部分算出来的用来证明“我知道PMK”。这里正好是密码验证的时点。如果站点输错密码它生成的PTK就跟AP端不一致MIC校验就无法通过。第三步AP发送EAPOL-Key帧带GTK和MICAP收到SNonce后也能算出PTK。它验证第二步的MIC确认站点确实知道PMK。然后AP把自己维护的GTK发下来并用KEK加密、用KCK计算MIC。第四步站点确认站点解密得到GTK回发一个确认帧。AP验证MIC后整个四次握手完成双方进入State 4随后就可以用PTK中的TK部分加密数据流量了。这四次握手设计得相当精妙。每一步都有明确目的步数发送方关键载荷保护目标1AP → STAANonce让站点能计算PTK2STA → APSNonce MIC让AP能计算PTK同时证明自己知道PMK3AP → STAGTK MIC下发组密钥保护组播通信4STA → AP确认防止第三步未送达你会发现整个过程中PMK从来没上线传输口令验证是间接通过MIC完成的。这就是为何抓包软件只看得到EAPOL帧却拿不到你的Wi-Fi密码——密码没有被直接发送过它只存在于双方各自的内存里以PMK的形式参与运算。4.3 WPA3带来的变化SAE替代PSK如果你关注新协议一定听过WPA3最大的变化是引入了SAESimultaneous Authentication of Equals也就是常说的Dragonfly握手。为什么需要替代方案因为WPA2的PSK模式有一个致命弱点离线字典攻击。攻击者只要抓到你四次握手的包就能拿到ANonce、SNonce、MIC。由于PMK直接由密码派生他可以离线拿一个字典对每个候选密码都生成PMK再验证MIC是否匹配。这个攻击不需要和AP有任何交互抓包一次就能慢慢算普通八位数字密码在GPU下几小时内就会失守。SAE的思路完全不同。它基于椭圆曲线密码学让客户端和AP在都不知道对方是否“正确”的情况下先通过一小轮交互得到一个共享的秘密。关键是中途任何一次交互都不是可离线验证的信息。如果你猜错密码握手根本走不到结果。攻击者必须在线的场景下不断尝试而AP可以对失败的SAE尝试做限速这大大提高了破解门槛。WPA3个人版的建链流程比WPA2多了一个阶段完成802.11关联后先进行SAE握手再进入四次握手其实SAE握手的目标是协商出PMK。抓包时你会看到明显的区别WPA2直接进入EAPOL四次握手而WPA3先看到SAE Commit和SAE Confirm这两组帧。我个人对WPA3的建议是能用则用。即便是家用路由器只要终端支持开启WPA3能显著提升抗破解能力代价只是个别老旧设备连不上而已。5. 用抓包把整条链路看穿过滤技巧与排障实例5.1 抓包前的准备监听模式与信道固定理解了原理之后最有效的学习方式就是自己抓一次完整的建链过程。这里直接给你一套可操作的方法。准备一个支持监听模式的无线网卡很多USB网卡都可以但注意部分网卡驱动不支持在Linux下执行sudo ip link set wlan0 down sudo iw dev wlan0 set type monitor sudo ip link set wlan0 up sudo iw dev wlan0 set channel 6然后启动Wireshark抓包。抓完后首先设置一个显示过滤器wlan.fc.type_subtype 0x08 || wlan.fc.type_subtype 0x04 || wlan.fc.type_subtype 0x0b || wlan.fc.type_subtype 0x0c || eapol这串过滤器的意思是只显示0x08Beacon帧0x04Probe Request0x05Probe Response0x0bAuthentication0x0cAssociation Request/Response注意0x0d也有关联响应的情况eapol四次握手在Wireshark里你会看到完整的建链序列Authentication Request - Authentication Response - Association Request - Association Response - EAPOL 1/4 - EAPOL 2/4 - EAPOL 3/4 - EAPOL 4/4这一串跑完你的站点就进入了State 4。5.2 一次实战排障WPA2连不上卡在EAPOL 2/4我分享一个很典型的案例。有同事说某个AP用手机能连但用一台旧笔记本就是连不上而且一直提示“密码错误”。可是密码确定没输错。抓包后发现四次握手的第1步正常发出笔记本回复了第2步但紧接着AP没有回第3步而是直接重复第1步。这是典型的MIC校验失败场景AP认为笔记本第2步带回来的MIC不正确判定密码错误于是重新发起握手。最后查到原因笔记本的无线网卡驱动默认启用了WPA2-PSK的TKIP套件兼容模式而AP配置的是CCMPAES加密。两边在套件协商上出现了问题。把笔记本网卡驱动的加密设置强制改成AES后问题立刻消失。这个案例说明四次握手里第2步是客户端密码验证的分水岭卡在这里要先排查加密套件是否一致再怀疑密码本身。5.3 被动等待还是主动请求排障时怎么选另一个排障经验是看扫描阶段不要一上来就把网卡设成监听模式等Beacon这样效率太低因为Beacon每100ms才来一次。更高效的做法是主动发送Probe Request。很多抓包工具里可以直接构造一个广播Probe Requestairodump-ng wlan0这个工具其实是在监听模式下持续扫描信道并记录Beacon和Probe Response适合用来排查附近有哪些AP以及信号质量。如果你想看某个特定AP回应站点Probe的整个交互还是建议配合Wireshark做定向抓包。5.4 关联阶段隐藏的坑Assoc拒绝与802.11n能力不匹配还有一种常见的“连不上”是扫描正常、Authentication正常、但Association Request发出去后AP直接回了一个拒绝状态码。我在一个老AP上遇到过一次原因是站点声明支持802.11ac但AP的固件在Mixed模式下的关联处理有bug导致关联请求中的VHT能力元素被错误解析为非法值。解决方式是给AP升级固件或者把无线模式锁定在802.11n。这种问题在抓包里最容易识别Association Response帧中的状态码非0且包含reason code。记住状态码和reason code的对应关系能省很多时间。常见的reason code包括1未指定原因2之前的认证已失效6站点非认证实际发生在重关联时17站点已离开BSS23站点不被允许关联如果你看到reason code 6或17首先要去查AP端是不是启用了基于连接数的限制或者漫游策略。6. 把建链成功之后的事也算进链路写到这里主线已经覆盖了“从扫描到四次握手”的完整过程。但我想额外提一句容易被忽略的事情建链成功并不代表用户上网体验正常。一个健壮的无线网络除了完成802.11建链之外还要关注DHCP获取这是“能连上但不能上网”的第一嫌疑。手机连上Wi-Fi后拿不到IP问题几乎总在DHCP流程里而不是802.11。DNS解析如果IP能拿到但打开网页很慢先看DNS别急着改无线参数。漫游稳定性802.11建链本身没问题但站点在不同AP之间移动时重关联的流畅度直接影响视频通话的体验。速率与重传很多“信号满格但网卡”的情况实际上是因为RSSI高但SNR很低导致调制速率上不去数据帧重传率极高。换言之建链只是入场券后续的握手、DHCP、漫游决策才是决定体验的关键。我在开头提到状态机从State 1走到State 4那是802.11协议的完整建链流程但真正让用户满意的是从State 4之后一直保持数据畅通的能力。如果这篇文章能帮你建立一条清晰的脉络——扫描发现—认证关联—安全握手—后续排障——那么我对802.11入门主干的拆解就算完成了。接下来你可以顺着这条线去研究漫游时的重关联机制、802.11ax中的OFDMA资源调度、或者企业级环境中802.1X认证与动态PMK下发那些都是建立在这条主干上的分支。