为什么我的ath9k生成的RadioTap头文件看起来格式错误？

我在Ubuntu 16.04（4.4内核）上使用scapy收集802.11数据包。我的包的RadioTap头有以下现时标志：为什么我的ath9k生成的RadioTap头文件看起来格式错误？

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

鉴于RadioTap的描述，我希望频道开始在第10字节以下的报头和先前场（8 TSFT + 1各为标志和费率）。 Channel的对齐方式为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信号强度。

任何人都有一个想法，我失踪了？

来源

2016-02-26 Rich Henry

我刚刚嗅过的数据包的'notdecoded'属性是''xd5q \ x01 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x00 \ x10 \ x02l \ t \ xa0 \ x00 \ xfa \ x01 \ x00 \ x00' '，这是有道理的，因为'未解码[10:12] ='l \ t''。你可以编辑这个问题来包含整个数据包，而不仅仅是'notdecoded'部分吗？当用这个数据包喂食时，wireshark会显示什么？ – Yoel

使用我的英特尔无线网卡可以获得相同的结果，一切都在正确的位置。 tcpdump能够解码数据包，我需要的答案是有人理解那些额外的8字节。我会尝试登陆系统并抓取一个数据包并更新我的问题。 –

找到了答案挖成的说明之后深一点：

Scapy的不解析扩展头由作为标志着位32（虽然它没有告诉我他们通过陈述+分机上面的）。那些额外的头文件塞满了数据包'未解码'部分的前面。我认为scapy应至少从未解码的文件中移除这些扩展头文件以避免将来的混淆。

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

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

来源

2016-03-02 14:07:43

为什么我的ath9k生成的RadioTap头文件看起来格式错误？

回答

相关问题