WiFi6 - new device in the neighbourhood

[sfx2000]

Nice - just observed a neighbour with a spanking new WiFi6 router - grabbed a capture of the beacon...

Note - looks like it's a 2*2:2 at least for 2.4GHz, and it's running in 40MHz wide channels in a dense suburban area -

Couple of things to note:

1) that's a big beacon frame - 495 bytes there - transmit this every 100 mSec, that's a fair amount of airtime
2) defaults as WPA2-AES - good - WPA3/WPA2 mixed/transitional would have been a better default, IMHO...
3) 802.11b legacy rates - enabled - which at this point, they're leaving a bit of bandwidth/latency on the table (goes towards preamble and slotting time - doing g/n/ax and removing b support does help here...)
4) Wide Channels in 2.4 - never been a big fan about this - note that even when forcing wide channels, this comes with overhead - the secondary channel always has to check there before using it - bit more latency added there - makes for big numbers if/when it works perhaps...
5) WiFi5 DL MU-MIMO is enabled, WiFi6 OFDMA disabled

Anyways - interesting to see this actually in the real world...

sfx

 

[El Mariachi]

Nice - just observed a neighbour with a spanking new WiFi6 router - grabbed a capture of the beacon...

Note - looks like it's a 2*2:2 at least for 2.4GHz, and it's running in 40MHz wide channels in a dense suburban area -

Couple of things to note:

1) that's a big beacon frame - 495 bytes there - transmit this every 100 mSec, that's a fair amount of airtime
2) defaults as WPA2-AES - good - WPA3/WPA2 mixed/transitional would have been a better default, IMHO...
3) 802.11b legacy rates - enabled - which at this point, they're leaving a bit of bandwidth/latency on the table (goes towards preamble and slotting time - doing g/n/ax and removing b support does help here...)
4) Wide Channels in 2.4 - never been a big fan about this - note that even when forcing wide channels, this comes with overhead - the secondary channel always has to check there before using it - bit more latency added there - makes for big numbers if/when it works perhaps...
5) WiFi5 DL MU-MIMO is enabled, WiFi6 OFDMA disabled


View attachment 27689

Anyways - interesting to see this actually in the real world...

sfx

SFX, I understand you are the resident chipset engineer. Referencing your suggestion to run WPA2/3 mixed mode. The devs over at openwrt say in their release notes for WPA2/3 mixed mode can cause connectivity issues for many WPA2 only devices. Is this the case for AsusWRT connected devices also?

 

[sfx2000]

SFX, I understand you are the resident chipset engineer. Referencing your suggestion to run WPA2/3 mixed mode. The devs over at openwrt say in their release notes for WPA2/3 mixed mode can cause connectivity issues for many WPA2 only devices. Is this the case for AsusWRT connected devices also?

Pretty much agree here - clients may have issues with WPA2/3 mixed mode...

Not sure on AsusWRT - I would experiment and try...

 

[RMerlin]

For reference, Asuswrt uses hostapd for WPA2/WPA3. I guess BCM didn't want to bother updating their own nas daemon for it.

 

[El Mariachi]

For reference, Asuswrt uses hostapd for WPA2/WPA3. I guess BCM didn't want to bother updating their own nas daemon for it.

Unfortunately this is beyond my technical knowledge @RMerlin. To enable WPA3 support on OpenWRT requires the wpad-openssl package which (to my knowledge) isn't BCM (broadcomm driver?) related. To that point I believe it is a software based limitation. hostapd might do a better job managing legacy devices than wpad-openssl.

 

[sfx2000]

To enable WPA3 support on OpenWRT requires the wpad-openssl package which (to my knowledge) isn't BCM (broadcomm driver?) related. To that point I believe it is a software based limitation. hostapd might do a better job managing legacy devices than wpad-openssl.

For OpenWRT - hostapd-openssl is all that is needed for WPA3 support - clientside, wpa-supplicant-openssl

Conversly - the wpad-openssl package pulls the needed dependencies for both client/AP - at a cost of extra flash space.

One of the challenges with WPA3 is the crypto offload that many wifi chips have internally - so that AES happens on the CPU cores, which can impact performance.

 

[sfx2000]

Another one - this is Asus/Broadcom...

2.4GHz is 20MHz channel, and looks like they have at least one legacy client attached (see ERP/Barker Mode)

this is a 3*3:3 config

DL MU-MIMO, OFDMA disabled...

WPA2-AES

 

[Fatawan]

I can't decide if I would want sfx2000 as my neighbor(resident IT support) or not(spying on me!)????

 

[sfx2000]

I can't decide if I would want sfx2000 as my neighbor(resident IT support) or not(spying on me!)????

this is all public broadcast from AP's in the neighborhood, and informed insight...

 

[sfx2000]

For reference, Asuswrt uses hostapd for WPA2/WPA3. I guess BCM didn't want to bother updating their own nas daemon for it.

BCM will likely configure the BSS as they see fit... but note the Asus/Broadcom defaults noted above.

Interesting that the VHT side - SU-MIMO, as opposed to QC-Atheros going with MU on their WiFi6 - this is similar to their WiFi5 second gen FW on IPQ40**/IPQ80** - arguably the IPQ40** did get more attention from QCA due to the meshy stuff compared to the BHR IPQ80** line for WiFi5...

 

[sfx2000]

2.4GHz is 20MHz channel, and looks like they have at least one legacy client attached (see ERP/Barker Mode)

I've seen this before with Realtek client sta's - unfortunate perhaps when the AP is broadcasting B/G/N...

ERP is 802.11g mode support for legacy.

 

[RMerlin]

Interesting that the VHT side - SU-MIMO, as opposed to QC-Atheros going with MU on their WiFi6

Depends whether the user decided to enable it or not.

 

[sfx2000]

Depends whether the user decided to enable it or not.

true that - we also know that requests can go to WL and it just says "yes" and not apply them for vendor/OEM compat reasons...

Broadcom's closed source WL driver does that... probably for the better

 

[sfx2000]

Anyways...

More focused on my project - bringing an old WiFi4 chipset up to current specs for IOT - it's a fairly cheap and available chip and one well understood and open on the WiFi driver side (as it's ath9k based)

And that's ok... 2.4GHz is a bit of a mess - but getting decent numbers per stream here...

See below.

 

[leerees]

Both my neighbor's have 40mhz broadcasters on 2.4ghz. In addition, they also have those Roku sticks that deliberately cause interference to sabotage everybody else. They are conspiracy theorists and are punishing me for having a femtocell, bobcat miners and various earials on my roof. 40mhz on 2.4g is definitely bad form and if your neighbor's will listen show them that 20mhz will actually be faster in most cases.

The 2.4ghz band for us is completely unusable. Normal 5ghz is saturated.

Luckily, my router uses DFS channels and the only devices we have on 2.4g are a few iots and a printer, all low bandwidth and immune to their roku attacks.