IEEEE 802.15.4 FCF Format in "RIOT/sys/net/link_layer/ieee802154/ieee802154.c"

Hi all,

I am having a hard time understanding how the “ieee802154_set_frame_hdr” function, found in this link, sets the Frame Control Field (FCF) for 802.15.4 frame header. Following the IEEE 802.15.4 FCF format, frame version should be at the 12-13th bit of the 2-byte FCF, while in the function code, the frame version was set at the 11th bit. Does it uses different FCF format or am I missing something?

This is the first part of the function:

size_t ieee802154_set_frame_hdr(uint8_t *buf, const uint8_t *src, size_t src_len,

const uint8_t *dst, size_t dst_len,

le_uint16_t src_pan, le_uint16_t dst_pan,

uint8_t flags, uint8_t seq)

{

int pos = 3; /* 0-1: FCS, 2: seq */

uint8_t type = (flags & IEEE802154_FCF_TYPE_MASK);

buf[0] = flags;

buf[1] = IEEE802154_FCF_VERS_V1; // IEEE802154_FCF_VERS_V1 is defined as 0x10

if (((src_len != 0) && (src == NULL)) ||

((dst_len != 0) && (dst == NULL))) {

return 0;

}

The first two bytes of the *buf represent the FCF. I would appreciate it if someone explains or provides the FCF format that RIOT-OS uses.

Thank you, Ahed

I think you must have made a mistake in your calculations. buf[1] contains bits 8-15 of the fcf, bits 12-13 are the version bits. 12 - 8 = 4, 1 << 4 = 0x10, so the frame version is set to version 1, all other bits are zero at the beginning of that function.

Best regards, Joakim

Den tis 26 nov. 2019 22:59Aboodi Ahed Hussein Ali <aboodi@student.usm.my> skrev:

Thank you, Joakim, but I don’t think it is correct.

Starting from 0, bit No. 3 of the IEEE802154_FCF_VERS_V1 (Hex 0x10 or binary: 0001 0000) have the value 1, thus 0 to 3 represent 8 to 11 on buf[1]. therefor, the bit No. 3, in 0x10, is set on bit No. 11 of the FCF.

Not sure if the below illustration will be on a layout. —buf[0] buf[1] 0000 0000 0000 0000 <-- FCF

------------- 0001 0000 <-- IEEE802154_FCF_VERS_V1

This means that the Frame version is not really set probably or this file “RIOT/sys/net/link_layer/ieee802154/ieee802154.c” follows a different FCF format!!

Am I correct or did I misunderstand that?

Ahed

HI Ahed,

0x10 has _fourth_ bit set to 1.

1 << 0 = 0x01 1 << 1 = 0x02 1 << 2 = 0x04 1 << 3 = 0x08 1 << 4 = 0x10

So the code looks correct.

Best, Anton

I think you are confusing byte ordering with bit ordering, the IEEE 802.15.4 frame format uses little-endian _byte_ ordering, so the least significant byte comes first. But inside each byte, the least significant bit has number 0, the most significant bit has number 7. Therefore, a byte where only bit number 4 is set (written 1 << 4 in C), is equal to 0x10.

/Joakim

Thank you, Anton. Please bear with me if I misunderstood any programming fundamentals,

I agree that the 4th bit of buf[1] is set to 1, but according to FCF format the 13th and 14th bits, of buf[0-1], must be set for frame version, or if you start counting the FCF bits from 0 to 15, bit 12 and bit 13 are the frame version bits.

buf[1] = IEEE802154_FCF_VERS_V1 means the 12th bit is set to 1, or the 11th bit if we start counting FCF bits from 0 to 15.

Besides, when I did print buf[1] I get decimal 16, while I should get decimal 8 for the frame version to be set.

Ahed .

Thank you, Joakim, but according to table 3 in this https://os.mbed.com/media/uploads/cotigac/802154mpapirm.pdf , the second byte of FCF needs bit number 5 & 6 to be set for the frame version, not the bit number 4.

Ahed

Hi Ahed,

buf[1] = IEEE802154_FCF_VERS_V1 means the 12th bit is set to 1, or the 11th bit if we start counting FCF bits from 0 to 15.

Not quite, it sets 12th bit counting from 0 (or 13th counting from 1, but let's not count from 1 :slight_smile: ).

See https://pastebin.com/D29acwf4

Hope this helps.

Best, Anton

Thank Anton,

That really clarifies a lot of things, I did not know enough about the bit, byte, and field order of a network frame. I am new to this topic.

Thank you all for your help

Ahed