简介这份抓包分析报告聚焦802.11无线局域网标准面向需要理解Wireshark抓包原理、进行无线网络故障排查或性能分析的网络工程师与学习者。资源以单个doc文档呈现大小630KB内容系统性拆解了MAC层数据帧格式从Frame Control中的Version、Type、Subtype到To DS/From DS方向标志、More Frag/Retry/Pwr mgt/More data等状态位再到Protected加密标志、Duration信道占用时间、Address字段、Sequence序列号及CRC校验逐一说明含义与判读方法。文档还进一步区分了数据帧、控制帧与管理帧重点讲解了RTS、CTS、ACK在协调信道访问中的作用以及Beacon、Authentication等管理帧的地址与BSSID结构。借助这些字段分析读者可以掌握通过Wireshark识别帧类型、追踪传输方向、判断重传与节能状态、定位网络异常的基本方法。文档已有115人学习浏览适合作为802.11协议入门与抓包实战的速查笔记。1. 802.11抓包为什么值得看从三个现场问题说起做无线网络维护的人大概率遇到过这种场面用户反馈“WiFi慢”你看信号强度、信道占用率全是绿色就是定位不到问题或者AP日志一切正常但终端频繁断流重启AP也没用。这时候唯一能做的事就是把802.11的MAC帧抓下来逐位看。802.11抓包不是玄学也不是“通信里面的解码”那种黑匣子——它就是把链路层的帧头字段一个个拆开判断重传、方向、节能和加密状态。这份报告用Ubuntu加Wireshark对数据帧、控制帧、管理帧做了完整拆解特别适合刚开始上手WiFi抓包分析、做协议测试或者被AP重传问题折磨过的工程师。读完你至少能回答三个问题一个十六进制字节怎么读出一帧的来龙去脉为什么Wireshark显示的字节顺序和协议文档对不上以及monitor mode抓包到底有哪些雷。2. 读懂MAC层帧格式Frame Control位域与三个地址位的分工2.1 从帧头布局看起2字节控制字加6字节地址怎么配合802.11 MAC帧头的固定部分不算长却承载了链路层几乎全部关键信息。以数据帧为例帧头依次是Frame Control2字节、Duration2字节、Address 16字节、Address 26字节、Address 36字节、Sequence Control2字节后面才是0到2312字节的Data最后跟4字节CRC校验。不少人第一次打开Wireshark看802.11帧会懵就是因为这个帧头里字节数不多但每个字段的语义都在变。字段长度数据帧中的含义Frame Control2字节版本、类型、方向、重传、加密等16个bitDuration2字节本帧与确认帧占用信道的时间微秒Address 16字节接收方地址recipientAddress 26字节发送方地址transmitterAddress 36字节远程端点地址按帧类型切换语义Sequence Control2字节4位段号 12位帧号Data0-2312字节有效载荷Check Sequence4字节CRC校验码Frame Control里的Type字段用两位区分三大类00管理帧、01控制帧、10数据帧。Subtype再往下细分数据帧里0000是普通Data1000是QoS Data控制帧里1011是RTS、1100是CTS、1101是ACK、1001是Block ACK管理帧里1000是Beacon信标帧。读帧的第一步永远是先确认Type和Subtype它们决定了后面所有字段怎么解释。三个地址位是最容易绕晕的地方。Address 1是接收方Address 2是发送方这是固定的Address 3在不同帧里含义不同——数据帧里它可能是BSSID也可能是一个远程终端地址。文档里给出的数据帧例子Address 1是00:22:69:8e:a7:44Address 2是06:11:b5:1a:0a:05APAddress 3是00:00:5e:00:04:0a这就是标准的“终端→AP→远端”三段地址。控制帧里通常只有Address 1和Address 2没有Address 3因为控制帧只在当前链路两端交互不需要关心远端。2.2 To DS / From DS一条帧的方向就藏在两个bit里To DS和From DS各占1位组合起来直接决定数据帧的流向。这也是抓包分析里最常用的判断依据先看方向再看地址最后看重传和序列号。To DS0、From DS0数据在无线终端之间直接传输也就是Ad Hoc模式不走AP。To DS0、From DS1帧来自AP是下行方向终端从AP收数据。To DS1、From DS0帧发往AP是上行方向终端向AP发数据。To DS1、From DS1AP到AP的桥接转发常见于WDS组网。文档里抓到的数据帧就是To DS0、From DS1说明这是AP发给终端的一帧。管理帧和控制帧的这两位固定为0——管理帧不参与数据转发控制帧是链路上的即时握手信号都不存在“发往AP”或“来自AP”的语义。实际排查时我习惯先用这两bit把抓包分成“上行”和“下行”两块看不然上下行混在一起重传率统计会被严重干扰。提示Wireshark的过滤语法里可以直接写wlan.fc.tods0 wlan.fc.fromds1过滤下行数据帧比在图形界面里一个个点字段快得多。2.3 Wireshark的字节序陷阱08 0a 不等于 0x080a这是整份文档里最值钱的一段也是新手人工读帧时翻车率最高的地方。Wireshark的Packet bytes面板直接显示抓到的原始字节比如数据帧的Frame Control原始字节是08 0a。按阅读习惯你会把它当成0x080a展开成二进制0000 1000 0000 1010结果字段全对不上。Wireshark的Packet detail面板实际按0x0a08来解释这两个字节。802.11帧头里多字节字段是小端传输低字节在前所以要先把两个字节交换再按位读。0x0a08 0000 1010 0000 1000从高位到低位拆开位区间bit15→bit0字段该帧取值含义bit15Order0不要求严格顺序bit14Protected0未加密bit13More Data0无更多缓存帧bit12Pwr Mgt0发送方未进入节能模式bit11Retry1重传帧bit10More Frag0最后一帧bit9From DS1来自APbit8To DS0非发往APbit7-4Subtype0000Databit3-2Type10数据帧bit1-0Version00版本0Duration字段同样是小端。文档里的数据帧Duration原始字节是d5 00低字节d5在前高字节00在后实际值是0x00d5 213微秒。但MAC地址不反转0022698ea744直接读成 00:22:69:8e:a7:44因为地址是字节序列不参与数值运算。这套规则不是我规定的是所有基于libpcap的抓包工具通用行为。记住一个口诀数值字段交换字节再读地址字段直接读。3. 三类帧的十六进制实战拆解RTS、CTS、ACK、Beacon和Block ACK3.1 数据帧0x080a怎么一步步读出重传、方向和时长文档里抓到的第一个数据帧Frame Control原始字节08 0a。经过上一章的字节序翻转得到0x0a08。逐位读出Version00Type10数据帧Subtype0000DataTo DS0From DS1More Frag0Retry1Pwr Mgt0More Data0Protected0Order0。这一帧是AP下发的、未加密的普通数据帧而且是重传帧。有这个判断之后再看地址就顺了。Address 100:22:69:8e:a7:44是接收终端Address 206:11:b5:1a:0a:05是发送方也就是APAddress 300:00:5e:00:04:0a是远端节点。Direction已经明确是下行所以Address 1是终端、Address 2是AP完全对得上。Sequence字段原始字节30 32按数值字段交换后是0x3230低12位是帧号803。紧跟着的下一个数据帧三个地址完全一致帧号变成804——这就是同一个AP发给同一个终端的连续两帧。文档还特意验证了CRCCheck Sequence字段检测结果为正确。这一步很多人忽略但抓包分析里CRC是判断无线链路是否出错的重要信号。如果大量帧的CRC是错的说明当前抓包位置信号质量差或者网卡驱动在丢数据。提示人工读帧时从Frame Control到Duration再到Sequence每一步都要问“这个值要不要交换字节”。只有地址和Data字段是直接读的。3.2 控制帧b4 / c4 / d4 / 94四种Byte对应的四种保护机制控制帧不携带上层数据它们的作用是协调无线介质访问。文档抓到了四种典型控制帧RTS、CTS、ACK、Block ACK。它们的Frame Control低字节分别是b4、c4、d4、94最高四位就是Subtype非常容易辨认。类型十六进制Subtype作用Duration示例RTSb41011请求发送预约信道0x0967 2407微秒CTSc41100清空发送响应RTS0x096f 2415微秒ACKd41101确认单播帧接收0x0000 0微秒Block ACK941001批量确认QoS帧0x0094 148微秒RTS帧的格式是Frame Control、Duration、Receiver Address、Transmitter Address、CRC。文档抓到的RTS中Receiver Address00:22:69:8e:a7:44Transmitter Address06:11:b5:1a:0a:05Duration0x09672407微秒。这个Duration值的意思是RTS发送方预约了接下来2407微秒的信道使用权用于完成后续CTS、Data和ACK的交换。CTS帧的Duration会比RTS略大一点因为CTS发出时它要把剩余时间重新计算一遍。文档里CTS Duration0x096f2415微秒就是这种倒计时机制的直接体现。ACK帧的Duration固定为0。因为ACK是帧交换的终点后面没有需要保护的信道时间了。Block ACK则是802.11e引入的批量确认机制一个Block ACK可以确认多个QoS数据帧在视频流和批量下载场景下能显著减少确认帧数量。它多了Block Ack Control和Starting Sequence Control字段用来指明确认的是哪一段序列号。文档里Block Ack Type02H、Control0005H、Starting Sequence9320H说明它确认的是从序列号0x9320开始的聚合帧。3.3 管理帧Beacon 0x80与广播地址的识别管理帧里最典型的信标帧Frame Control低字节是80二进制1000 0000Subtype1000即Beacon。管理帧的To DS和From DS固定为0所以Frame Control高字节通常都是00。Beacon帧的Destination Address是ff:ff:ff:ff:ff:ff广播地址Source Address和BSSID都是AP的MAC地址——文档里抓到的BeaconSA38:22:d6:77:05:d0BSSID也是38:22:d6:77:05:d0说明这个BSSID就是该AP自身的MAC属于基础型网络的标准配置。Beacon帧的作用是周期性宣告802.11网络的存在AP默认每100毫秒左右发一个。抓包时看到大量间隔均匀的Beacon说明AP活着信道配置正确如果Beacon间隔忽长忽短基本可以判断AP在忙或者驱动有问题。信标帧里还携带SSID、支持的速率、加密方式等信息但这些载荷字段是变长的需要按TLV格式解析。人工排查时用Wireshark自带的802.11解析器展开看即可不用自己去数偏移量。管理帧里另外几个常见值也值得记住Authentication1011Association Request0000Deauthentication1100。抓无线终端连不上AP的问题时重点盯这几个管理帧的交互时序。4. Ubuntu下开Monitor Mode抓WiFi包从网卡选型到五个高频踩坑4.1 网卡和驱动要求AX210这类卡能不能用于抓包先看清不是所有无线网卡都能抓802.11帧。普通网卡在managed模式下收到的帧已经被驱动过滤掉大部分MAC头信息Wireshark里看到的只是本机进出的数据。要抓到Beacon、RTS、CTS这类管理帧和控制帧必须让网卡进入monitor mode。选网卡之前先确认驱动支持情况。Intel AX210/AX200这类新卡在较新内核上能开monitor mode但部分驱动固件会过滤掉一些控制帧或者切换到monitor mode后无法同时保持正常上网抓包体验不太稳定。Realtek RTL8812BU这类芯片的老卡反而是WiFi抓包圈里常用的方案驱动成熟monitor mode支持完整很多人专门收一块USB网卡干这活。# 查看当前网卡接口名 iw dev # 查看网卡支持哪些接口模式确认列表里有 monitor iw phy phy0 info | grep -A 10 Supported interface modes第一条命令输出里找到无线接口名通常是wlan0。第二条命令输出里如果只有managed那这块卡基本告别原生抓包了要么换驱动要么换网卡。常见做法是拿一张USB网卡专门做抓包笔记本自带网卡保持正常上网两边互不干扰。4.2 开Monitor Mode三步iw命令切换、锁信道、Wireshark监听确认网卡支持monitor mode之后切换本身只需要几条命令。关键坑在于NetworkManager会自动把无线网卡拉回managed模式所以要先停掉它对抓包网卡的管理。# 停用NetworkManager对该接口的管理 sudo nmcli device set wlan0 managed no # 网卡down sudo ip link set wlan0 down # 切换monitor mode sudo iw dev wlan0 set type monitor # 再up sudo ip link set wlan0 up # 锁定信道6是2.4G常用信道按目标AP实际信道改 sudo iw dev wlan0 set channel 6 # 启动Wireshark sudo wireshark这段命令的逻辑是先让系统服务别再干预这张卡再down掉接口切换模式重新up。set channel 6这步特别容易被跳过——不锁信道的话无线网卡会在各信道间跳频扫描抓到的帧来自不同AP时序完全对不上分析毫无意义。另外Wireshark要有权限读取无线接口所以用sudo启动。如果iw切换报错可以试airmon-ng方案sudo airmon-ng check kill sudo airmon-ng start wlan0airmon-ng会把wlan0重命名为wlan0monWireshark里选这个接口抓包。这个老工具在某些环境下比纯iw命令更省事但它会停掉所有无线接口包括你正在用的网络。4.3 抓包过滤语法Beacon、数据帧和控制帧分别怎么筛monitor mode下抓包流量是海量的尤其在一个AP密集的写字楼里。我一般会先按帧类型过滤把分析范围缩小。想抓的内容Wireshark过滤语法所有管理帧wlan.fc.type 0只看Beacon信标wlan.fc.type_subtype 8所有数据帧wlan.fc.type 2只看重传帧wlan.fc.retry 1按BSSID过滤wlan.bssid 38:22:d6:77:05:d0按发送方过滤wlan.ta 06:11:b5:1a:0a:05只看上行数据wlan.fc.tods 1 wlan.fc.fromds 0注意802.11协议在Wireshark里的字段名是wlan.xxx不是wifi.xxx别写错。抓包时先用wlan.fc.type_subtype 8确认能稳定看到目标AP的Beacon再切换到数据帧过滤这样能快速验证monitor mode是否工作正常。4.4 避坑记录五条血泪经验现象1抓了半天全是自己网卡关联的帧看不到目标AP的流量。原因没锁信道。monitor mode默认在所有信道间跳抓到哪个信道算哪个。 解决先用iw dev wlan0 set channel 6锁到目标AP所在信道再用wlan.bssid过滤确认。现象2Frame Control显示08 0a按0x080a解析全是乱码。原因802.11多字节字段小端序人工读字节时没交换顺序。 解决按第2.3节做法先交换字节得到0x0a08再展开位字段。地址字段不需要交换。现象3只看到Beacon和空数据帧找不到任何应用层流量。原因目标网络开启了WPA2加密。monitor mode能收到加密帧的MAC头但看不到payload里的TCP/UDP内容。 解决抓包前先正常连接一次目标WiFi完成握手或者抓包时保留关联态只分析MAC层行为时不受影响因为方向、重传、序列号都在头部可见。现象4一开monitor mode系统网络瞬间掉线接口状态反复横跳。原因NetworkManager的接管机制把网卡拉回managed模式。 解决先执行nmcli device set wlan0 managed no停掉接管再切换模式。这步不做后面全白搭。现象5抓到的数据帧里Retry1比例特别高误判网络质量差。原因monitor mode会收到同一个帧的原始传输和重传副本两个都算进去了部分USB网卡驱动还会重复上交帧。 解决结合Sequence字段判断。真重传帧的Sequence和之前某帧相同而不同帧的新Sequence说明是新数据。统计重传率时按Sequence去重后再算。5. 一个验证技巧用Sequence和Duration判断帧的先后与归属5.1 序列号递增判断连续帧Sequence Control字段里12位是帧号4位是段号。同一发送方发出的每一帧帧号递增1到4095后回绕到0。文档里抓到的数据帧Sequence原始字节30 32交换后0x3230低12位帧号803紧接的下一帧三个地址完全一致帧号804。这说明它们是同一链路对的连续传输中间没有插入其他终端的帧。用这个特性可以验证很多事。比如怀疑某个终端在抢信道过滤它的wlan.ta看序列号是否连续跳跃如果帧号跳动幅度大说明中间还有别的帧插入或者抓包网卡丢了帧。判断重传也更准确wlan.fc.retry 1的帧如果Sequence和前面某帧一致才是真正的MAC层重传如果Sequence是新的那只是带Retry标记的新帧。5.2 Duration的倒计时逻辑还原信道时序Duration字段的值不是随机的它表示本帧和后续确认帧需要占用信道的总时间。RTS帧发出后接收方要等SIFS时间后回CTS然后发送方等SIFS再发Data接收方再等SIFS回ACK。RTS的Duration覆盖的是整段过程所以它一定大于后续每个单帧的Duration。看文档里RTS和CTS的Duration值就能感受到这个倒计时逻辑RTS的Duration小于CTS的Duration因为CTS发出时RTS占用的那部分时间已经消耗掉了CTS要重新计算剩余时间。ACK的Duration为0因为帧交换已经结束。实际分析时如果发现某条链路的Duration远大于正常值往往意味着对端没有及时回ACK发送方在按退避算法等待重传。这就是隐藏节点问题的一个典型信号。从那以后我每次拿到一份WiFi抓包都强制走三遍先把Frame Control的字节序翻过来读再核对Sequence的连续性最后才看Duration和重传标志。这个习惯帮我挡掉了至少十次误判也让我在看别人写的抓包分析时一眼就能分辨哪些是真正上手拆过帧的哪些只是照着Wireshark截图抄的。希望帮到你。本文还有配套的精品资源点击获取 802.11抓包实战：从MAC帧格式到monitor mode全解析
简介这份抓包分析报告聚焦802.11无线局域网标准面向需要理解Wireshark抓包原理、进行无线网络故障排查或性能分析的网络工程师与学习者。资源以单个doc文档呈现大小630KB内容系统性拆解了MAC层数据帧格式从Frame Control中的Version、Type、Subtype到To DS/From DS方向标志、More Frag/Retry/Pwr mgt/More data等状态位再到Protected加密标志、Duration信道占用时间、Address字段、Sequence序列号及CRC校验逐一说明含义与判读方法。文档还进一步区分了数据帧、控制帧与管理帧重点讲解了RTS、CTS、ACK在协调信道访问中的作用以及Beacon、Authentication等管理帧的地址与BSSID结构。借助这些字段分析读者可以掌握通过Wireshark识别帧类型、追踪传输方向、判断重传与节能状态、定位网络异常的基本方法。文档已有115人学习浏览适合作为802.11协议入门与抓包实战的速查笔记。1. 802.11抓包为什么值得看从三个现场问题说起做无线网络维护的人大概率遇到过这种场面用户反馈“WiFi慢”你看信号强度、信道占用率全是绿色就是定位不到问题或者AP日志一切正常但终端频繁断流重启AP也没用。这时候唯一能做的事就是把802.11的MAC帧抓下来逐位看。802.11抓包不是玄学也不是“通信里面的解码”那种黑匣子——它就是把链路层的帧头字段一个个拆开判断重传、方向、节能和加密状态。这份报告用Ubuntu加Wireshark对数据帧、控制帧、管理帧做了完整拆解特别适合刚开始上手WiFi抓包分析、做协议测试或者被AP重传问题折磨过的工程师。读完你至少能回答三个问题一个十六进制字节怎么读出一帧的来龙去脉为什么Wireshark显示的字节顺序和协议文档对不上以及monitor mode抓包到底有哪些雷。2. 读懂MAC层帧格式Frame Control位域与三个地址位的分工2.1 从帧头布局看起2字节控制字加6字节地址怎么配合802.11 MAC帧头的固定部分不算长却承载了链路层几乎全部关键信息。以数据帧为例帧头依次是Frame Control2字节、Duration2字节、Address 16字节、Address 26字节、Address 36字节、Sequence Control2字节后面才是0到2312字节的Data最后跟4字节CRC校验。不少人第一次打开Wireshark看802.11帧会懵就是因为这个帧头里字节数不多但每个字段的语义都在变。字段长度数据帧中的含义Frame Control2字节版本、类型、方向、重传、加密等16个bitDuration2字节本帧与确认帧占用信道的时间微秒Address 16字节接收方地址recipientAddress 26字节发送方地址transmitterAddress 36字节远程端点地址按帧类型切换语义Sequence Control2字节4位段号 12位帧号Data0-2312字节有效载荷Check Sequence4字节CRC校验码Frame Control里的Type字段用两位区分三大类00管理帧、01控制帧、10数据帧。Subtype再往下细分数据帧里0000是普通Data1000是QoS Data控制帧里1011是RTS、1100是CTS、1101是ACK、1001是Block ACK管理帧里1000是Beacon信标帧。读帧的第一步永远是先确认Type和Subtype它们决定了后面所有字段怎么解释。三个地址位是最容易绕晕的地方。Address 1是接收方Address 2是发送方这是固定的Address 3在不同帧里含义不同——数据帧里它可能是BSSID也可能是一个远程终端地址。文档里给出的数据帧例子Address 1是00:22:69:8e:a7:44Address 2是06:11:b5:1a:0a:05APAddress 3是00:00:5e:00:04:0a这就是标准的“终端→AP→远端”三段地址。控制帧里通常只有Address 1和Address 2没有Address 3因为控制帧只在当前链路两端交互不需要关心远端。2.2 To DS / From DS一条帧的方向就藏在两个bit里To DS和From DS各占1位组合起来直接决定数据帧的流向。这也是抓包分析里最常用的判断依据先看方向再看地址最后看重传和序列号。To DS0、From DS0数据在无线终端之间直接传输也就是Ad Hoc模式不走AP。To DS0、From DS1帧来自AP是下行方向终端从AP收数据。To DS1、From DS0帧发往AP是上行方向终端向AP发数据。To DS1、From DS1AP到AP的桥接转发常见于WDS组网。文档里抓到的数据帧就是To DS0、From DS1说明这是AP发给终端的一帧。管理帧和控制帧的这两位固定为0——管理帧不参与数据转发控制帧是链路上的即时握手信号都不存在“发往AP”或“来自AP”的语义。实际排查时我习惯先用这两bit把抓包分成“上行”和“下行”两块看不然上下行混在一起重传率统计会被严重干扰。提示Wireshark的过滤语法里可以直接写wlan.fc.tods0 wlan.fc.fromds1过滤下行数据帧比在图形界面里一个个点字段快得多。2.3 Wireshark的字节序陷阱08 0a 不等于 0x080a这是整份文档里最值钱的一段也是新手人工读帧时翻车率最高的地方。Wireshark的Packet bytes面板直接显示抓到的原始字节比如数据帧的Frame Control原始字节是08 0a。按阅读习惯你会把它当成0x080a展开成二进制0000 1000 0000 1010结果字段全对不上。Wireshark的Packet detail面板实际按0x0a08来解释这两个字节。802.11帧头里多字节字段是小端传输低字节在前所以要先把两个字节交换再按位读。0x0a08 0000 1010 0000 1000从高位到低位拆开位区间bit15→bit0字段该帧取值含义bit15Order0不要求严格顺序bit14Protected0未加密bit13More Data0无更多缓存帧bit12Pwr Mgt0发送方未进入节能模式bit11Retry1重传帧bit10More Frag0最后一帧bit9From DS1来自APbit8To DS0非发往APbit7-4Subtype0000Databit3-2Type10数据帧bit1-0Version00版本0Duration字段同样是小端。文档里的数据帧Duration原始字节是d5 00低字节d5在前高字节00在后实际值是0x00d5 213微秒。但MAC地址不反转0022698ea744直接读成 00:22:69:8e:a7:44因为地址是字节序列不参与数值运算。这套规则不是我规定的是所有基于libpcap的抓包工具通用行为。记住一个口诀数值字段交换字节再读地址字段直接读。3. 三类帧的十六进制实战拆解RTS、CTS、ACK、Beacon和Block ACK3.1 数据帧0x080a怎么一步步读出重传、方向和时长文档里抓到的第一个数据帧Frame Control原始字节08 0a。经过上一章的字节序翻转得到0x0a08。逐位读出Version00Type10数据帧Subtype0000DataTo DS0From DS1More Frag0Retry1Pwr Mgt0More Data0Protected0Order0。这一帧是AP下发的、未加密的普通数据帧而且是重传帧。有这个判断之后再看地址就顺了。Address 100:22:69:8e:a7:44是接收终端Address 206:11:b5:1a:0a:05是发送方也就是APAddress 300:00:5e:00:04:0a是远端节点。Direction已经明确是下行所以Address 1是终端、Address 2是AP完全对得上。Sequence字段原始字节30 32按数值字段交换后是0x3230低12位是帧号803。紧跟着的下一个数据帧三个地址完全一致帧号变成804——这就是同一个AP发给同一个终端的连续两帧。文档还特意验证了CRCCheck Sequence字段检测结果为正确。这一步很多人忽略但抓包分析里CRC是判断无线链路是否出错的重要信号。如果大量帧的CRC是错的说明当前抓包位置信号质量差或者网卡驱动在丢数据。提示人工读帧时从Frame Control到Duration再到Sequence每一步都要问“这个值要不要交换字节”。只有地址和Data字段是直接读的。3.2 控制帧b4 / c4 / d4 / 94四种Byte对应的四种保护机制控制帧不携带上层数据它们的作用是协调无线介质访问。文档抓到了四种典型控制帧RTS、CTS、ACK、Block ACK。它们的Frame Control低字节分别是b4、c4、d4、94最高四位就是Subtype非常容易辨认。类型十六进制Subtype作用Duration示例RTSb41011请求发送预约信道0x0967 2407微秒CTSc41100清空发送响应RTS0x096f 2415微秒ACKd41101确认单播帧接收0x0000 0微秒Block ACK941001批量确认QoS帧0x0094 148微秒RTS帧的格式是Frame Control、Duration、Receiver Address、Transmitter Address、CRC。文档抓到的RTS中Receiver Address00:22:69:8e:a7:44Transmitter Address06:11:b5:1a:0a:05Duration0x09672407微秒。这个Duration值的意思是RTS发送方预约了接下来2407微秒的信道使用权用于完成后续CTS、Data和ACK的交换。CTS帧的Duration会比RTS略大一点因为CTS发出时它要把剩余时间重新计算一遍。文档里CTS Duration0x096f2415微秒就是这种倒计时机制的直接体现。ACK帧的Duration固定为0。因为ACK是帧交换的终点后面没有需要保护的信道时间了。Block ACK则是802.11e引入的批量确认机制一个Block ACK可以确认多个QoS数据帧在视频流和批量下载场景下能显著减少确认帧数量。它多了Block Ack Control和Starting Sequence Control字段用来指明确认的是哪一段序列号。文档里Block Ack Type02H、Control0005H、Starting Sequence9320H说明它确认的是从序列号0x9320开始的聚合帧。3.3 管理帧Beacon 0x80与广播地址的识别管理帧里最典型的信标帧Frame Control低字节是80二进制1000 0000Subtype1000即Beacon。管理帧的To DS和From DS固定为0所以Frame Control高字节通常都是00。Beacon帧的Destination Address是ff:ff:ff:ff:ff:ff广播地址Source Address和BSSID都是AP的MAC地址——文档里抓到的BeaconSA38:22:d6:77:05:d0BSSID也是38:22:d6:77:05:d0说明这个BSSID就是该AP自身的MAC属于基础型网络的标准配置。Beacon帧的作用是周期性宣告802.11网络的存在AP默认每100毫秒左右发一个。抓包时看到大量间隔均匀的Beacon说明AP活着信道配置正确如果Beacon间隔忽长忽短基本可以判断AP在忙或者驱动有问题。信标帧里还携带SSID、支持的速率、加密方式等信息但这些载荷字段是变长的需要按TLV格式解析。人工排查时用Wireshark自带的802.11解析器展开看即可不用自己去数偏移量。管理帧里另外几个常见值也值得记住Authentication1011Association Request0000Deauthentication1100。抓无线终端连不上AP的问题时重点盯这几个管理帧的交互时序。4. Ubuntu下开Monitor Mode抓WiFi包从网卡选型到五个高频踩坑4.1 网卡和驱动要求AX210这类卡能不能用于抓包先看清不是所有无线网卡都能抓802.11帧。普通网卡在managed模式下收到的帧已经被驱动过滤掉大部分MAC头信息Wireshark里看到的只是本机进出的数据。要抓到Beacon、RTS、CTS这类管理帧和控制帧必须让网卡进入monitor mode。选网卡之前先确认驱动支持情况。Intel AX210/AX200这类新卡在较新内核上能开monitor mode但部分驱动固件会过滤掉一些控制帧或者切换到monitor mode后无法同时保持正常上网抓包体验不太稳定。Realtek RTL8812BU这类芯片的老卡反而是WiFi抓包圈里常用的方案驱动成熟monitor mode支持完整很多人专门收一块USB网卡干这活。# 查看当前网卡接口名 iw dev # 查看网卡支持哪些接口模式确认列表里有 monitor iw phy phy0 info | grep -A 10 Supported interface modes第一条命令输出里找到无线接口名通常是wlan0。第二条命令输出里如果只有managed那这块卡基本告别原生抓包了要么换驱动要么换网卡。常见做法是拿一张USB网卡专门做抓包笔记本自带网卡保持正常上网两边互不干扰。4.2 开Monitor Mode三步iw命令切换、锁信道、Wireshark监听确认网卡支持monitor mode之后切换本身只需要几条命令。关键坑在于NetworkManager会自动把无线网卡拉回managed模式所以要先停掉它对抓包网卡的管理。# 停用NetworkManager对该接口的管理 sudo nmcli device set wlan0 managed no # 网卡down sudo ip link set wlan0 down # 切换monitor mode sudo iw dev wlan0 set type monitor # 再up sudo ip link set wlan0 up # 锁定信道6是2.4G常用信道按目标AP实际信道改 sudo iw dev wlan0 set channel 6 # 启动Wireshark sudo wireshark这段命令的逻辑是先让系统服务别再干预这张卡再down掉接口切换模式重新up。set channel 6这步特别容易被跳过——不锁信道的话无线网卡会在各信道间跳频扫描抓到的帧来自不同AP时序完全对不上分析毫无意义。另外Wireshark要有权限读取无线接口所以用sudo启动。如果iw切换报错可以试airmon-ng方案sudo airmon-ng check kill sudo airmon-ng start wlan0airmon-ng会把wlan0重命名为wlan0monWireshark里选这个接口抓包。这个老工具在某些环境下比纯iw命令更省事但它会停掉所有无线接口包括你正在用的网络。4.3 抓包过滤语法Beacon、数据帧和控制帧分别怎么筛monitor mode下抓包流量是海量的尤其在一个AP密集的写字楼里。我一般会先按帧类型过滤把分析范围缩小。想抓的内容Wireshark过滤语法所有管理帧wlan.fc.type 0只看Beacon信标wlan.fc.type_subtype 8所有数据帧wlan.fc.type 2只看重传帧wlan.fc.retry 1按BSSID过滤wlan.bssid 38:22:d6:77:05:d0按发送方过滤wlan.ta 06:11:b5:1a:0a:05只看上行数据wlan.fc.tods 1 wlan.fc.fromds 0注意802.11协议在Wireshark里的字段名是wlan.xxx不是wifi.xxx别写错。抓包时先用wlan.fc.type_subtype 8确认能稳定看到目标AP的Beacon再切换到数据帧过滤这样能快速验证monitor mode是否工作正常。4.4 避坑记录五条血泪经验现象1抓了半天全是自己网卡关联的帧看不到目标AP的流量。原因没锁信道。monitor mode默认在所有信道间跳抓到哪个信道算哪个。 解决先用iw dev wlan0 set channel 6锁到目标AP所在信道再用wlan.bssid过滤确认。现象2Frame Control显示08 0a按0x080a解析全是乱码。原因802.11多字节字段小端序人工读字节时没交换顺序。 解决按第2.3节做法先交换字节得到0x0a08再展开位字段。地址字段不需要交换。现象3只看到Beacon和空数据帧找不到任何应用层流量。原因目标网络开启了WPA2加密。monitor mode能收到加密帧的MAC头但看不到payload里的TCP/UDP内容。 解决抓包前先正常连接一次目标WiFi完成握手或者抓包时保留关联态只分析MAC层行为时不受影响因为方向、重传、序列号都在头部可见。现象4一开monitor mode系统网络瞬间掉线接口状态反复横跳。原因NetworkManager的接管机制把网卡拉回managed模式。 解决先执行nmcli device set wlan0 managed no停掉接管再切换模式。这步不做后面全白搭。现象5抓到的数据帧里Retry1比例特别高误判网络质量差。原因monitor mode会收到同一个帧的原始传输和重传副本两个都算进去了部分USB网卡驱动还会重复上交帧。 解决结合Sequence字段判断。真重传帧的Sequence和之前某帧相同而不同帧的新Sequence说明是新数据。统计重传率时按Sequence去重后再算。5. 一个验证技巧用Sequence和Duration判断帧的先后与归属5.1 序列号递增判断连续帧Sequence Control字段里12位是帧号4位是段号。同一发送方发出的每一帧帧号递增1到4095后回绕到0。文档里抓到的数据帧Sequence原始字节30 32交换后0x3230低12位帧号803紧接的下一帧三个地址完全一致帧号804。这说明它们是同一链路对的连续传输中间没有插入其他终端的帧。用这个特性可以验证很多事。比如怀疑某个终端在抢信道过滤它的wlan.ta看序列号是否连续跳跃如果帧号跳动幅度大说明中间还有别的帧插入或者抓包网卡丢了帧。判断重传也更准确wlan.fc.retry 1的帧如果Sequence和前面某帧一致才是真正的MAC层重传如果Sequence是新的那只是带Retry标记的新帧。5.2 Duration的倒计时逻辑还原信道时序Duration字段的值不是随机的它表示本帧和后续确认帧需要占用信道的总时间。RTS帧发出后接收方要等SIFS时间后回CTS然后发送方等SIFS再发Data接收方再等SIFS回ACK。RTS的Duration覆盖的是整段过程所以它一定大于后续每个单帧的Duration。看文档里RTS和CTS的Duration值就能感受到这个倒计时逻辑RTS的Duration小于CTS的Duration因为CTS发出时RTS占用的那部分时间已经消耗掉了CTS要重新计算剩余时间。ACK的Duration为0因为帧交换已经结束。实际分析时如果发现某条链路的Duration远大于正常值往往意味着对端没有及时回ACK发送方在按退避算法等待重传。这就是隐藏节点问题的一个典型信号。从那以后我每次拿到一份WiFi抓包都强制走三遍先把Frame Control的字节序翻过来读再核对Sequence的连续性最后才看Duration和重传标志。这个习惯帮我挡掉了至少十次误判也让我在看别人写的抓包分析时一眼就能分辨哪些是真正上手拆过帧的哪些只是照着Wireshark截图抄的。希望帮到你。本文还有配套的精品资源点击获取