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

Hi. I set up my Wi-Fi USB dongle EDUP AC1200 2.4 GHz / 5 GHz (the 
Realtek RTL8812BU chipset inside, driver 
https://aur.archlinux.org/packages/rtl88x2bu-dkms-git/ ) as a Wi-Fi 
access point in the 5 GHz band. After upgrading hostapd from version 
2.10 to version 2.11 the AP stopped working. I see the AP in 
WiFiAnalyzer, but with a narrower channel (20 MHz instead of 80 MHz). 
The first smartphone sees the AP, but can't connect. The second 
smartphone see the AP, says that it uses WEP (which isn't correct), and 
asks for a password. It shouldn't ask for a password because it 
remembers the password. I can't enter my password anyway probably 
because WEP restricts its length too much. When I switch to the old 
version of hostapd, all smartphones connect without asking for a 
password. I can make the 2.11 version of hostapd work in the 2.4 GHz 
band though.

I bisected to the commit |8056b79ff1e5d746a82c2ea12011e69e99c11d3d |. 
Applying the patch below solves the problem. My `hw_mode` is `a` as you 
can see in my hostapd configuration file below.

{{{
      *eid++ = WLAN_EID_DS_PARAMS;
}}}

The hostapd configuration file "hostapd.conf":

{{{
interface=wifiap
driver=nl80211
logger_syslog=-1
logger_syslog_level=2
logger_stdout=-1
logger_stdout_level=2
ctrl_interface=/run/hostapd
ctrl_interface_group=0
ssid={{{skipped}}}
country_code=UA
country3=0x49
ieee80211d=1
ieee80211h=1
hw_mode=a
channel=52
beacon_int=100
dtim_period=2
max_num_sta=255
rts_threshold=-1
fragm_threshold=-1
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wmm_enabled=1
wmm_ac_bk_cwmin=4
wmm_ac_bk_cwmax=10
wmm_ac_bk_aifs=7
wmm_ac_bk_txop_limit=0
wmm_ac_bk_acm=0
wmm_ac_be_aifs=3
wmm_ac_be_cwmin=4
wmm_ac_be_cwmax=10
wmm_ac_be_txop_limit=0
wmm_ac_be_acm=0
wmm_ac_vi_aifs=2
wmm_ac_vi_cwmin=3
wmm_ac_vi_cwmax=4
wmm_ac_vi_txop_limit=94
wmm_ac_vi_acm=0
wmm_ac_vo_aifs=2
wmm_ac_vo_cwmin=2
wmm_ac_vo_cwmax=3
wmm_ac_vo_txop_limit=47
wmm_ac_vo_acm=0
ieee80211n=1
ht_capab=[HT40+][SHORT-GI-20][SHORT-GI-40]
ieee80211ac=1
vht_oper_chwidth=1
vht_oper_centr_freq_seg0_idx=58
eapol_key_index_workaround=0
eap_server=0
own_ip_addr=127.0.0.1
wpa=2
wpa_passphrase={{{skipped}}}
wpa_key_mgmt=WPA-PSK-SHA256 WPA-PSK
wpa_pairwise=CCMP
}}}

On Fri, Nov 08, 2024 at 02:09:32PM +0200, me@beroal.in.ua wrote:
> Hi. I set up my Wi-Fi USB dongle EDUP AC1200 2.4 GHz / 5 GHz (the Realtek
> RTL8812BU chipset inside, driver
> https://aur.archlinux.org/packages/rtl88x2bu-dkms-git/ ) as a Wi-Fi access
> point in the 5 GHz band. After upgrading hostapd from version 2.10 to
> version 2.11 the AP stopped working. I see the AP in WiFiAnalyzer, but with
> a narrower channel (20 MHz instead of 80 MHz). The first smartphone sees the
> AP, but can't connect. The second smartphone see the AP, says that it uses
> WEP (which isn't correct), and asks for a password. It shouldn't ask for a
> password because it remembers the password. I can't enter my password anyway
> probably because WEP restricts its length too much. When I switch to the old
> version of hostapd, all smartphones connect without asking for a password. I
> can make the 2.11 version of hostapd work in the 2.4 GHz band though.

Would you happen to have means for capturing a full Beacon frame from
that AP? I'd like to see what exactly it ends up including, i.e.,
whether this truly is just because of the DSSS Parameter Set element
being removed or whether there could be something else involved with
this.

> I bisected to the commit |8056b79ff1e5d746a82c2ea12011e69e99c11d3d |.
> Applying the patch below solves the problem. My `hw_mode` is `a` as you can
> see in my hostapd configuration file below.

That commit ('Add DSSS Parameter Set element only for 2.4 GHz') removed
the DSSS Parameter Set element from all other bands than 2.4 GHz which
makes this match what the IEEE 802.11 standard has defined for over 20
years. It is interesting if there are numerous deployed STAs that do not
handle that..

The history on this change in the standard is such that there was
actually a period between IEEE Std 802.11a-1999 and IEEE Std
802.11g-2003 amendments when the standard could have been interpreted to
include the DSSS Parameter Set element (called the DS Parameter Set
information element at the time) in Beacon frames and Probe Response
frames since IEEE Std 802.11a-1999 did not define any changes to the
Beacon frame format and IEEE Std 802.11-1999 did not limit this element
to be included only on the 2.4 GHz band. As such, there could be
theoretically some 20 year old IEEE 802.11a STAs that would be compliant
with the standard at the time they were manufactured but that would have
been unable to accept Beacon frames from APs that follow the newer (but
still over 20 years old..) version of the standard.

Taken into account this change in hostapd is only from a year ago, I
guess one could justify reverting it if it does indeed result in
interoperability issues. I would just want to make sure that this is
indeed the sole reason for the issues and nothing else (e.g., the driver
changing something else in Beacon frames based on this) could be at play
here.

26.12.2024 11:42, Jouni Malinen пишет:
> On Fri, Nov 08, 2024 at 02:09:32PM +0200,me@beroal.in.ua wrote:
>> Hi. I set up my Wi-Fi USB dongle EDUP AC1200 2.4 GHz / 5 GHz (the Realtek
>> RTL8812BU chipset inside, driver
>> https://aur.archlinux.org/packages/rtl88x2bu-dkms-git/ ) as a Wi-Fi access
>> point in the 5 GHz band. After upgrading hostapd from version 2.10 to
>> version 2.11 the AP stopped working. I see the AP in WiFiAnalyzer, but with
>> a narrower channel (20 MHz instead of 80 MHz). The first smartphone sees the
>> AP, but can't connect. The second smartphone see the AP, says that it uses
>> WEP (which isn't correct), and asks for a password. It shouldn't ask for a
>> password because it remembers the password. I can't enter my password anyway
>> probably because WEP restricts its length too much. When I switch to the old
>> version of hostapd, all smartphones connect without asking for a password. I
>> can make the 2.11 version of hostapd work in the 2.4 GHz band though.
> Would you happen to have means for capturing a full Beacon frame from
> that AP? I'd like to see what exactly it ends up including, i.e.,
> whether this truly is just because of the DSSS Parameter Set element
> being removed or whether there could be something else involved with
> this.

I'm afraid I do not. Can you describe these means in more detail? The 
only Wi-Fi cards that can work in the 5 GHz band that I have are 
embedded into these two Android smartphones. AFAIK, Android restricts 
what you can run very much.

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

> 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.

Oh yes it's a driver bug. rtl8812au contains the following gem in 
update_BCNTIM() (https://github.com/zebulon2/rtl8812au-driver-5.2.9/blob/
601ccd117168c37ff93daecab75ed9581d412371/core/rtw_ap.c#L103):

/*calculate head_len*/
offset = _FIXED_IE_LENGTH_;

/* get ssid_ie len */
p = rtw_get_ie(pie + _BEACON_IE_OFFSET_, _SSID_IE_, &tmp_len, 
(pnetwork_mlmeext->IELength - _BEACON_IE_OFFSET_));
if (p != NULL)
    offset += tmp_len + 2;

/*get supported rates len*/
p = rtw_get_ie(pie + _BEACON_IE_OFFSET_, _SUPPORTEDRATES_IE_, &tmp_len, 
(pnetwork_mlmeext->IELength - _BEACON_IE_OFFSET_));
if (p !=  NULL)
    offset += tmp_len + 2;

/*DS Parameter Set IE, len=3*/
offset += 3;

So it basically expects DSSS params to always be there and will write the TIM 
3 bytes out of place otherwise.

Of course that logic is positively bonkers and the driver should be fixed, but 
that's often more easily said than done. Could hostapd perhaps get a config 
option to force adding DSSS to work around broken drivers?

2T