802.11r mobility domain byte order

[kdash]

Hi,
I am new user of openwrt and this looks grate software.
I am trying to join openwrt box on existing 802.11r network by CISCO WAP series.
FT seems not to work properly from cisco's log.
I capture beacon frame of both box and found that openwrt's mobility domain swaps byte order.
My mobility domain is 10000 as decimal and 0x2710 as hex.
CISCO sends it as little endian and wireshark recognize as 0x2710.
OpenWRT sends it as big endian and wireshark recognize as 0x1027.
Which endian is true ?

[IanC]

Not a direct answer but what platform / SoC is your device using? It may quickly highlight that you're on platform where the endian usually needs swapping for network-byte-order, and a missing hton() or similar in the code.

EDIT: First answer here (bold added by me) is saying that it'd be expected to be in little-endian form: https://stackoverflow.com/questions/11562036/order-of-sending-frame-control-fielddata-of-an-802-11-frame

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.

[IanC]

Perhaps as a quick hack, does setting the domain to 4135 (0x1027) get it to connect?

[jow]

I could also imagine that one side interprets the hexadecimal value in the configuration as binary byte string (essentially big endian) while the other side interprets the value numerically and sends it in platform endianess.

What exactly did you configure on the OpenWrt side? option mobility_domain 2710?

Edit:
Indeed, hostapd interprets the given value as binary string:

latelee/hostapd/blob/b97f32062c9a29fe6b12b5082832e34ed565b7de/hostapd/config_file.c#L2539

So I suppose your only choice is to simply swap the bytes manually in the OpenWrt side config to accommodate for Cisco’s implied byte swapping of the mobility domain value.

Edit 2:
Just seen that @IanC digged out the proper standards definition, seems that hostapd should interpret the value numerically (strtoul() instead of hexstr2bin() and then convert the value to little endian in order to match Cisco‘s and likely other vendors behavior).

[IanC]

@jow

Just seen that @IanC digged out the proper standards definition, seems that hostapd should interpret the value numerically (strtoul() instead of hexstr2bin() and then convert the value to little endian in order to match Cisco‘s and likely other vendors behavior).

Passing around the 10000 (from OPs scenario) may be important for any comparisons in network code. Then ensuring it is little-endian when put in an 802.11 frame. So I agree with you in general, but not necessarily doing both operations while reading config.

EDIT: Thinking about it a bit more I'm wondering if these should always be simply treated as a byte array, rather than a number. If people talk about "mobility domain 10000" then it is a number. If they say "mobility domain two-seven-one-zero" or "alpha-bravo-alpha-bravo" implying hex digits it is more of an array.

[hnyman]

@jow

seems that hostapd should interpret the value numerically (strtoul() instead of hexstr2bin() and then convert the value to little endian in order to match Cisco‘s and likely other vendors behavior).

I am wondering if that currently causes us interoperability issues between little-endian and big-endian OpenWrt devices.

Interesting if that flaw in hostapd has been undetected this long.

[kdash]

Hello guys,
Thank you for every quick responese.

I have changed OpenWRT's config to:

option mobiliy_domain 1027

I am investigating 802.11r at new config.
I will report result of this new config.

CISCO WAP runs hostapd and they may modify privately
this byte order problem.
Here is log of WAP station:

[IanC]

I think the consensus above is that Cisco have it correct.

On the OpenWRT side This may just be a config file interpretation issue (which can be fixed by reversing the bytes for now), or there may be other bits of code that will get it wrong on platforms depending on their endianness and / or what is read from config.

[hnyman]

@jow

Just seen that @IanC digged out the proper standards definition, seems that hostapd should interpret the value numerically (strtoul() instead of hexstr2bin() and then convert the value to little endian in order to match Cisco‘s and likely other vendors behavior).

@IanC

Thinking about it a bit more I'm wondering if these should always be simply treated as a byte array, rather than a number. If people talk about "mobility domain 10000" then it is a number. If they say "mobility domain two-seven-one-zero" or "alpha-bravo-alpha-bravo" implying hex digits it is more of an array.

@jow @nbd
This littleendian/bigendian/bytearray might be something to be fixed in the OpenWrt hostapd, and maybe also flagged to the upstream hostapd?

[hnyman]

This difference is apparently still there...

Is it possible to read NAS ID and Mobility Domain of third-party router?

It is likely a question byte order of numbers, of "little endian" vs. "big endian" CPUs. Is 0x0064 stored in two bytes as is "00 64" or as "64 00" ? That was something that I speculated three years ago at and like @jow summarized as Your other part about NASID is similar: Hexadecimal characters for 0-9 are 30 31 ... 39 So, if one takes ASCII string of "6334..." it is actually hexadecimal values as "36 33 33 34 ..." Apparently OpenWrt and your other router handle that aspect different…

I use a byte-symmetric Mobility ID myself for 802.11r...
something like "0D 0D"