2

我正在使用 libtrace 来解析网络数据包，但我认为这是一个字节序问题。

这是 Radiotap 数据包的 libtrace 定义：

typedef struct libtrace_radiotap_t {
    uint8_t     it_version; /**< Radiotap version */
    uint8_t     it_pad; /**< Padding for natural alignment */
    uint16_t    it_len; /**< Length in bytes of the entire Radiotap header */
    uint32_t    it_present; /**< Which Radiotap fields are present */
} PACKED libtrace_radiotap_t;

所以我将 mylibtrace_packet_t转换为这个 Radiotap 结构并检查结果：

link = (char *) trace_get_packet_buffer(packet, &linktype, NULL);

if (linktype != TRACE_TYPE_80211_RADIO)
    return;

rtap = (libtrace_radiotap_t *) link;

printf("%d %d %d %d\n", rtap->it_present, rtap->it_pad, rtap->it_len,
       rtap->it_present);

在我的小端开发机器上，来自我的 pcap 文件中数据包的 Radiotap 数据是：

806959 0 72 806959

哪个是对的。我的开发机器正在成功解析我希望从 pcap 文件中看到的数据。

当在我的大端生产盒上运行时，我看到不同的值：

793775104 0 18432 793775104

同一个 pcap 文件中的同一个数据包。不同的 Radiotap 值。我怀疑问题出在两台机器的不同字节序上。但是，作为单字节rtap.it_version的uint8_t哪个不应该受到字节序问题的影响，不是吗？

4

2 回答 2

1

那应该是字节顺序问题。对于 72，十六进制是 0x48，它是一个 uint16_t，所以在不同的字节序中，0x4800 = 18432。没错。对于 806959 = 0xC502F，在不同的字节序中 0x2F50C000 = 793775104。

这可能会有所帮助：

#define T(x) (((x&0xff)<<24)|((x&0xff00)<<8)|((x&0xff0000)>>8)|((x&0xff000000)>>24))
于 2013-08-29T03:42:42.037 回答
0

libtrace 返回的标头结构指向出现在“线路”上的标头，即没有任何尝试转换为主机字节顺序的尝试。

Radiotap 标头字段始终是小端（与传统的网络字节顺序相反，它是大端），因此如果您要尝试手动解析标头，则需要对其进行补偿。仅仅使用ntohl是行不通的，因为这期望您转换为大端的值。

然而，更好的方法是使用内置的 libtrace 函数来访问各种 radiotap 字段，例如trace_get_wireless_rate和trace_get_wireless_signal_strength_dbm许多其他字段。这些函数将根据您的主机架构进行字节顺序转换，因此您不必担心。

至于你的问题struct ieee80211_frame_control，这看起来像一个错误。我建议向 libtrace 开发人员提交错误单。

于 2013-08-29T22:12:43.090 回答