为什么我的 ath9k 生成的 RadioTap 标头格式错误？答案

【问题标题】：Why do my ath9k generated RadioTap headers seems malformed?为什么我的 ath9k 生成的 RadioTap 标头格式错误？
【发布时间】：2016-02-26 02:29:22
【问题描述】：

我在 Ubuntu 16.04（4.4 内核）上使用 scapy 收集 802.11 数据包。我的数据包的 RadioTap 标头具有以下当前标志：

present=TSFT+Flags+Rate+Channel+dBm_AntSignal+b14+b29+Ext

鉴于 RadioTap 的描述，我希望 Channel 从标头和前面的字段之后的第 10 个字节开始（8 个用于 TSFT + 1 个用于标志和速率）。通道的对齐方式为 2，因此不需要填充。然而，这就是数据包未解码部分中的内容：

notdecoded=' \x08\x00\x00\x00\x00\x00\x00f\xc0 \x02\x00\x00\x00\x00\x10\x02l\t\xa0\x00\xa9\x00\x00\x00\xa9\x00'

在这种情况下，通道号实际上出现在字节 18-19 ('l\t' = 2412)，我不确定哪个字节包含 dBm 信号强度。

有人知道我缺少什么吗？

【问题讨论】：

我刚刚嗅探到的数据包的notdecoded 属性是'\xd5q\x01\x00\x00\x00\x00\x00\x10\x02l\t\xa0\x00\xfa\x01\x00\x00'，因为notdecoded[10:12] = 'l\t' 是有意义的。您能否编辑问题以包含完整的数据包，而不仅仅是 notdecoded 部分？当使用这个数据包时，wireshark 会显示什么？
我使用英特尔无线网卡得到了相同的结果，一切都在正确的位置。 tcpdump 能够解码数据包，我需要在这里回答的是理解那些额外的 8 个字节是什么的人。我将尝试登录系统并稍后抓取一个数据包并更新我的问题。

【解决方案1】：

在深入研究规范后找到了答案：

Scapy 不解析 bit-32 所表示的 扩展标头（尽管它确实通过上面的说明 +Ext 告诉了我它们）。这些额外的标头填充在数据包的“未解码”部分的前面。我认为 scapy 至少应该从未解码中删除那些扩展的标头以避免将来的混乱。

在这种特殊情况下，有两个额外的 32 位扩展位图头，占额外的 8 个字节。

如果有人想写一个更详细的答案，我会接受它，否则我会清理这个答案并永久接受它。

【讨论】：