AP doesn't work at 5 GHz after upgrading hostapd from 2.10 to 2.11

[Tomáš Trnka]

Hello,

One of my APs just stopped working after an upgrade to 2.11 with the exact 
issue described in this thread. (Sorry for the noise if the issue already got 
fixed in the meantime.)

This is the "tagged parameters" section of the resulting beacon frame captured 
off the air:

0000  00 0a 4f 73 6c 69 48 6e  69 7a 64 6f 01 08 8c 12   ··OsliHn izdo····
0010  98 24 b0 48 60 6c 07 22  43 05 04 00 01 00 00 5a   ·$·H`l·" C······Z
0020  20 22 01 00 24 01 14 26  01 14 28 01 14 2a 01 14    "··$··& ··(··*··
0030  2c 01 14 2e 01 14 30 05  14 64 0b 14 95 05 14 00   ,··.··0· ·d······
0040  30 14 01 00 00 0f ac 04  01 00 00 0f ac 04 01 00   0······· ········
0050  00 0f ac 02 0c 00 2d 1a  6e 08 1f ff ff 00 00 00   ······-· n·······
0060  00 00 00 00 00 2c 01 01  00 00 00 00 00 00 00 00   ·····,·· ········
0070  00 00 3d 16 38 07 00 00  00 00 00 00 00 00 00 00   ··=·8··· ········
0080  00 00 00 00 00 00 00 00  00 00 bf 0c 00 00 00 00   ········ ········
0090  fa ff 63 03 fa ff 63 03  c0 05 00 00 00 fc ff c3   ··c···c· ········
00A0  03 01 28 28 dd 18 00 50  f2 02 01 01 81 00 03 a4   ··((···P ········
00B0  00 00 27 a4 00 00 42 43  5e 00 62 32 2f 00         ··'···BC ^·b2/·

Starting from offset 16h, there's a Country Information element (tag = 07h, 
len = 22h), with the first letter of the country code "C" suddenly interrupted 
by six bytes (05 04 00 01 00 00) that look like a perfectly valid TIM element 
in the wrong place, and only after that (offset 1fh) there's the second letter 
of the country code "Z" followed by the rest of the country info data. Because 
of the 6-byte insertion, the last two triplets of the country info element (64 
0b 14 95 05 14 starting at offset 39h) overrrun its announced length, throwing 
everything out of sync and making the decoding of the rest of the beacon fail.

For example, Android reports the AP as using WEP (probably because the RSN 
info can't be decoded) and wavemon on Linux reports the SSID as 
"\xac\x02\x0c\x00…" because it misinterprets a part of the RSN info as the 
SSID param set.

For comparison, this is the same section of a beacon from the same AP running 
2.10:

0000  00 0a 4f 73 6c 69 48 6e  69 7a 64 6f 01 08 8c 12   ··OsliHn izdo····
0010  98 24 b0 48 60 6c 03 01  38 05 04 00 01 00 02 07   ·$·H`l·· 8·······
0020  22 43 5a 20 22 01 00 24  01 14 26 01 14 28 01 14   "CZ "··$ ··&··(··
0030  2a 01 14 2c 01 14 2e 01  14 30 05 14 64 0b 14 95   *··,··.· ·0··d···
0040  05 14 00 30 14 01 00 00  0f ac 04 01 00 00 0f ac   ···0···· ········
0050  04 01 00 00 0f ac 02 0c  00 2d 1a 6e 08 1f ff ff   ········ ·-·n····
0060  00 00 00 00 00 00 00 00  2c 01 01 00 00 00 00 00   ········ ,·······
0070  00 00 00 00 00 3d 16 38  07 00 00 00 00 00 00 00   ·····=·8 ········
0080  00 00 00 00 00 00 00 00  00 00 00 00 00 bf 0c 00   ········ ········
0090  00 00 00 fa ff 63 03 fa  ff 63 03 c0 05 00 00 00   ·····c·· ·c······
00A0  fc ff c3 03 01 28 28 dd  18 00 50 f2 02 01 01 81   ·····((· ··P·····
00B0  00 03 a4 00 00 27 a4 00  00 42 43 5e 00 62 32 2f   ·····'·· ·BC^·b2/
00C0  00                                                 ·

Note it's three bytes longer, there's the DSSS param set (03 01 38) starting 
at offset 16h followed by the TIM element in the exact same spot as in the 
corrupted 2.11 beacon, followed by a valid country info element.

So it looks as if omitting the DSSS params shifts the country info by three 
bytes but the TIM is still written to the same place. Curiously enough, this 
confusion is not present in the data printed by the debug output of hostapd 
2.11:

nl80211: Beacon tail - hexdump(len=162): 07 22 43 5a 20 22 01 00 24 01 14 26 
01 14 28 01 14 2a 01 14 2c 01 14 2e 01 14 30 05 14 64 0b 14 95 05 14 00 30 14 
01 00 00 0f ac 04 01 00 00 0f ac 04 01 00 00 0f ac 02 0c 00 2d 1a 6e 08 1f ff 
ff 00 00 00 00 00 00 00 00 2c 01 01 00 00 00 00 00 00 00 00 00 00 3d 16 38 07 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 bf 0c 00 00 00 00 
fa ff 63 03 fa ff 63 03 c0 05 00 36 00 fc ff c3 03 01 28 28 dd 18 00 50 f2 02 
01 01 01 00 03 a4 00 00 27 a4 00 00 42 43 5e 00 62 32 2f 00

So something is badly confused. No idea if that's something in hostapd writing 
the TIM after the debug info is printed above, or the driver (8812au) messing 
the beacon up afterwards.

This is on a target for which I don't have a toolchain/build system set up 
(it's a TV set-top box running openATV) so I can't just poke around with a 
debugger or recompile hostapd with extra debug prints easily. I can do it in 
principle if absolutely necessary, but I'm quite short on time.

Full pcap of the beacons and full debug output from hostapd is available on 
request (I'm not sure the list likes attachments).

Hope this helps diagnose the issue.

Best,

2T