2

I am trying to implement a UWB ranging system using IEEE 802.15.4 standard data frame encoding, but the example I found only uses 16-bit addressing with a frame control byte of 0x8841, like this:

tx_poll_msg[] = {0x41, 0x88, 0, 0xCA, 0xDE, 'W', 'A', 'V', 'E', 0xE0, 0, 0};

What frame control bytes should I use for 32-bit addressing like this:

tx_poll_msg[] = {0x??, 0x??, 0, 0xCA, 0xDE, 'W', 'A', 'A', 'W', 'V', 'E', 'E', 'V', 0xE0, 0, 0};

I can't find references to what those first two bytes mean anywhere.

ocrdu
  • 8,705
  • 21
  • 30
  • 42
Spencer Brennessel
  • 25
  • 3

1 Answers1

1

Wireshark's IEEE 802.15.4 dissector does a good job of explaining the fields:

Frame Control Field: 0x8841
    .... .... .... .001 = Frame Type: Data (0x1)
    .... .... .... 0... = Security Enabled: False
    .... .... ...0 .... = Frame Pending: False
    .... .... ..0. .... = Acknowledge Request: False
    .... .... .1.. .... = PAN ID Compression: True
    .... .... 0... .... = Reserved: False
    .... ...0 .... .... = Sequence Number Suppression: False
    .... ..0. .... .... = Information Elements Present: False
    .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
    ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
    10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)

This shows that bits [15:14] are the source addressing mode, and bits [11:10] are the destination addressing mode.

Looking into the IEEE 802.15.4 dissector source, the mode strings are defined in ieee802154_addr_modes:

static const value_string ieee802154_addr_modes[] = {
    { IEEE802154_FCF_ADDR_NONE,     "None" },
    { IEEE802154_FCF_ADDR_RESERVED, "Reserved" },
    { IEEE802154_FCF_ADDR_SHORT,    "Short/16-bit" },
    { IEEE802154_FCF_ADDR_EXT,      "Long/64-bit" },
    { 0, NULL }
};

This implies that there isn't a 32-bit mode, or at least Wireshark is unaware of it. The associated header file defines these constants:

/* Address Mode Definitions */
#define IEEE802154_FCF_ADDR_NONE               0x0
#define IEEE802154_FCF_ADDR_RESERVED           0x1
#define IEEE802154_FCF_ADDR_SHORT              0x2
#define IEEE802154_FCF_ADDR_EXT                0x3

It's possible that the IEEE added a new 32-bit addressing mode in place of the reserved value (1), and it hasn't had any press, but I suspect you probably want the 64-bit extended address mode. I'm not familiar with "PAN ID compression" here, so perhaps that also has something to do with different length addresses.

In the case of the example frame control field above, 0x8841 would become 0xCC41 if both source and destination used extended addresses.

Polynomial
  • 10,562
  • 5
  • 47
  • 88