发送802.11帧的“帧控制字段"数据的顺序? [英] Order of sending "Frame Control field"data of an 802.11 frame?

问题描述

以下是QoS数据的FC字段的位格式:

Below is bit format for FC field for QoS Data:

00|01|0001  01000010

前2位代表版本，后2位类型，后4位子类型，ToDS = 0，FromDS = 1，保护位= 1.

The first 2 bits represent version, the next 2 bits type, the next 4 bits subtype, with ToDS=0, FromDS=1,Protection bit=1.

那么，以上数据通过空中接口以什么顺序发送? (即从左到右或从右到左)

我看到Wireshark捕获的数据为" 8842 "(在最后一个显示原始数据包数据的段中).

So, in what order is the above data sent through the interface on the air? (i.e left to right or right to left )

I see the wireshark catching the data as "8842"(in the last segment where it shows raw packet data).

但是，如果我编写以下代码来打印FC字段数据:

But, if I write the following code to print FC field data:

struct mgmt_header_t {
    u_int16_t    fc;          /* 2 bytes */
    u_int16_t    duration;    /* 2 bytes */
    u_int8_t     addr1[6];    /* 6 bytes */  
    u_int8_t     addr2[6];    /* 6 bytes */  
    u_int8_t     addr3[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)
{
    int radiotapheader_length = (unsigned short int)(*(packet+2));
    struct mgmt_header_t *mac_header = (struct mgmt_header_t *)  (packet+radiotapheader_length);
    printf("FC = %X\n", mac_header->fc);
}

输出为:

FC = 4288

所以我的第二个问题是，它应该打印 8842 而不是 4288 吗?

So my secondary question is, shouldn't it print 8842 instead of 4288?

更新: 我正在更新问题，以便更清楚我的疑问.

说，我要发送一个FC字段格式如下的QoS数据包:

Update: I am updating the question so as to be more clear about what my doubt is.

Say, I want to send a QoS Data packet whose FC field is in the format below:

00|01|0001  01000010

所以，我必须写:

mac_header->fc = 0x1142 /* value if read from left to right */

或

mac_header->fc = 0x4211

或

mac_header->fc = 0x4288 /* value if read from right to left */

或

mac_header->fc = 0x8842

我的是一台小端机.

推荐答案

IEEE 802.11标准(遗憾的是，当前尚未从

The IEEE 802.11 standard (which, unfortunately, is not currently available from the IEEE Get program) says:

MAC子层中的MPDU或帧以特定顺序描述为字段序列.条款7中的每个图都描述了在MAC帧中出现的字段/子字段，并按从左到右的顺序将它们传递到物理层会聚过程(PLCP).

The MPDUs or frames in the MAC sublayer are described as a sequence of fields in specific order. Each figure in Clause 7 depicts the fields/subfields as they appear in the MAC frame and in the order in which they are passed to the physical layer convergence procedure (PLCP), from left to right.

在图中，字段中的所有位都从0到k进行了编号，其中字段的长度为k +1位.字段内的八位位组边界可以通过对字段的位数取模8来获得.数字字段中比单个八位位组长的八位位组从低位编号到高位编号按重要性的升序排列.长度大于单个八位位组的八位位组按从编号最低的八位组到编号最高的八位组的顺序发送到PLCP.

In figures, all bits within fields are numbered, from 0 to k, where the length of the field is k + 1 bits. The octet boundaries within a field can be obtained by taking the bit numbers of the field modulo 8. Octets within numeric fields that are longer than a single octet are depicted in increasing order of significance, from lowest numbered bit to highest numbered bit. 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.

因此，发送到PLCP的帧控制字段的第一个八位位组是包含B0的八位位组，即包含协议版本，类型和子类型字段的八位位组.之后是八位位组，其中包含到DS"，从DS"，更多片段"等.因此，00|01|0001八位位组是发送的第一个八位位组.在内存中的一个字节中，从高位到低位变成10001000，而不是从低位到高位，因此为0x88.下一个八位位组是01000010一个八位位组，因此为0x42.

So the first octet of the Frame Control field sent to the PLCP is the one containing B0, i.e. the octet containing the protocol version, type, and subtype fields. After that comes the octet containing To DS, From DS, More Frag, and so on. The 00|01|0001 octet is, therefore, the first octet transmitted. That turns into 10001000 in a byte in memory, from high-order bit to low-order bit rather than low-order bit to high-order bit, hence 0x88. The next octet is the 01000010 one, hence 0x42.

因此它以00010001后跟01000010的形式出现在导线上，并在内存中显示为0x88后跟0x42. (顺便说一下，这意味着FC字段与802.11中的所有其他多八位字节整数字段一样，以 little-endian 字节顺序传输，而不是以 big-endian <字节顺序.网络字节顺序"是大端字节顺序；并非所有通过网络传输的数据都以网络字节顺序"-Internet协议标准(例如IPv4，IPv6，TCP和UDP)中的字段是网络字节顺序"，但其他协议，包括通过IP传输的协议和通过TCP或UDP传输的协议，可以使用小尾数字节顺序.)

So that goes over the wire as 00010001 followed by 01000010, and would appear in memory as 0x88 followed by 0x42. (This, by the way, means that the FC field, like all other multi-octet integral fields in 802.11, is transmitted in little-endian byte order, rather than in big-endian byte order. "Network byte order" is big-endian byte order; not all data transmitted over a network is in "network byte order" - fields in Internet protocol standards such as IPv4, IPv6, TCP, and UDP are in "network byte order", but other protocols, including some over which IP is transmitted and some that are transmitted over TCP or UDP, may use little-endian byte order.)

由低位字节序的机器接收，并被视为16位整数，即0x4288-在具有多字节八进制数的小字节序机器上，内存中的第一个八位字节为低位数量的八位字节.因此，您的代码在Little-endian机器上将其打印为0x4288.如果它运行在big-endian机器上，则会将其打印为0x8842.

As received by a little-endian machine, and treated as a 16-bit integral quantity, that would be 0x4288 - on a little-endian machine, with a multiple-octet integral quantity, the first octet in memory is the low-order octet of the quantity. Therefore, your code prints it as 0x4288 on your little-endian machine; if it were running on a big-endian machine, it would print it as 0x8842.

将其打印为0x4288是正确"的.打印方式，因为它是小尾数的在线"打印方式(或者，更确切地说，是空中"，因为这是802.11 :-)). Wireshark在数据包详细信息"框中将数据包的帧控制"字段显示为0x4288.窗格(默认情况下为中间窗格)；它在十六进制转储"中显示为88 42.窗格(默认情况下是底部窗格)，因为它只是按照每个八位字节在内存中的显示顺序显示它们.

Printing it as 0x4288 is the "correct" way to print it, as it's little-endian "on the wire" (or, rather, "on the air", as this is 802.11 :-)). Wireshark shows the Frame Control field for your packet as 0x4288 in the "packet details" pane (the middle pane, by default); it shows up as 88 42 in the "hex dump" pane (the bottom pane, by default) because it's just showing each individual octet in the order in which they appear in memory.

如果要在big-endian和little-endian机器上将其打印为0x4288，则需要将其从little-endian字节顺序转换为主机字节顺序.最简单的方法是使用诸如Wireshark中的pletohs()宏之类的东西:

You would need to convert it from little-endian byte order to host byte order if you want it to print as 0x4288 on both big-endian and little-endian machines. The easiest way to do that would be to use something such as the pletohs() macro from Wireshark:

#define pletohs(p) ((unsigned short)                       \
                    ((unsigned short)*((const unsigned char *)(p)+1)<<8|  \
                     (unsigned short)*((const unsigned char *)(p)+0)<<0))

并执行诸如

printf("FC = %X\n", pletohs(&mac_header->fc));

对于传输该值，以不管您计算机的字节顺序如何工作的方式 的最简单方法就是使用诸如Wireshark的phtoles()宏:

As for transmitting that value, the easiest way to do that in a way that works regardless of the byte order of your machine would be to use something such as the phtoles() macro from Wireshark:

#define phtoles(p, v) \
    {                 \
        (p)[0] = (unsigned char)((v) >> 0);    \
        (p)[1] = (unsigned char)((v) >> 8);    \
    }

然后做

pletohs(&mac_header->fc, 0x4288);

设置mac_header->fc.

这篇关于发送802.11帧的“帧控制字段"数据的顺序?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！