C pcap 802.11 标头
struct mgmt_header_t {
u_int16_t fc; /* 2 bytes */
u_int16_t duration; /* 2 bytes */
u_int8_t da[6]; /* 6 bytes */
u_int8_t sa[6]; /* 6 bytes */
u_int8_t bssid[6]; /* 6 bytes */
u_int16_t seq_ctrl; /* 2 bytes */
};
void my_callback(u_char *args, const struct pcap_pkthdr *header, const u_char *packet)
{
//printf("********* New Packet Arrived *********\n");
//printf("Jacked a packet with length [%d]\n", header->len);
struct mgmt_header_t *mac_header = (struct mgmt_header_t *) (packet+24);
if (mac_header->fc > 255 )
printf("comon");
我知道 mac_header 位于正确的位置,因为我从中获取了 mac 地址,它们是正确的,但问题是 fc 永远不会大于 255,所以左字节总是为零
更新:
我想我现在就得到了它谢谢盖伊和奥特—— 供参考,这是我的完整示例 http://pcap -wireless.blogspot.com/2011/11/post-2-80211-mac-header.html
struct mgmt_header_t {
u_int16_t fc; /* 2 bytes */
u_int16_t duration; /* 2 bytes */
u_int8_t da[6]; /* 6 bytes */
u_int8_t sa[6]; /* 6 bytes */
u_int8_t bssid[6]; /* 6 bytes */
u_int16_t seq_ctrl; /* 2 bytes */
};
void my_callback(u_char *args, const struct pcap_pkthdr *header, const u_char *packet)
{
//printf("********* New Packet Arrived *********\n");
//printf("Jacked a packet with length [%d]\n", header->len);
struct mgmt_header_t *mac_header = (struct mgmt_header_t *) (packet+24);
if (mac_header->fc > 255 )
printf("comon");
I know the mac_header is in the right place because i'm getting the mac addresses from it and they are correct but the problem is with fc it's never greater than 255 so always the left byte is zero
UPDATE:
I think i got it right now thanks for guy and ott--
for reference here's my complete example http://pcap-wireless.blogspot.com/2011/11/post-2-80211-mac-header.html
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
引用 IEEE Std 802.11-2007 第 7.1.1 节“约定”:
“长于单个八位位组的字段中的八位位组按照从包含最低编号位的八位位组到包含最高编号位的八位位组的顺序发送到 PLCP。”意味着字段以小端顺序传输,而不是大端顺序。因此,值为 0x0080 的 16 位字段将作为值为 0x80 的八位位组(字节)传输,后跟值为 0x00 的八位位组。
这意味着在 Wiretap 十六进制转储中,您将看到 80 00,但这意味着 0x0080,而不是 0x8000。
顺便说一句,请注意 radiotap header 不保证为 24 字节长;标头包含一个(小端)长度字段,指定标头的长度。
To quote section 7.1.1 "Conventions" of IEEE Std 802.11-2007:
"The octets in fields longer than a single octet are sent to the PLCP in order from the octet containing the lowest numbered bits to the octet containing the highest numbered bits." means that the fields are transmitted in little-endian order, not big-endian order. Therefore, a 16-bit field with the value 0x0080 would be transmitted as an octet (byte) with the value 0x80 followed by an octet with the value 0x00.
This means that in the Wiretap hex dump, you'll see 80 00, but that means 0x0080, not 0x8000.
BTW, note that a radiotap header is not guaranteed to be 24 bytes long; the header includes a (little-endian) length field specifying how long the header is.
fc
字段的前 8 位,如果是关联请求,则为零。但是,您不是通过分配(数据包+24)来跳过标头吗?您可以添加数据包前 32 个字节的十六进制转储吗?The first 8 bits of the
fc
field or zero when it's an Association Request. But, aren't you skipping the header by assigning (packet+24)? Can you add a hexdump of the first 32 bytes of the packet?