Poll - what is the oldest level of 2.4Ghz Wifi currently in use

[Tech9]

This is what option I have on UniFi per SSID, but it clearly states for higher density deployments.

 

[sfx2000]

This is what option I have on UniFi per SSID, but it clearly states for higher density deployments.

View attachment 66450

Again - you're change 80211_MCAST, not 80211_BCAST - I've seen this very behavior on UNFI and others (it's a feature, right?? - most professional AP's (and course OpenWRT) - going legacy free is the default

Another thought here is the whole CellDensity thing, where we can limit association requests based on the minimum basic rate - that's fine, but again, if you don't disable legacy support in the driver - the beacon and management frames are still going at on 1Mbps, not 6, 12, whatever...

Ideally you want to ensure that the HR-DSSS mentioned below is disabled...

 

[Tech9]

Disabling Wi-Fi standard has to be based on some collective agreement. We as users can't do much. Most consumer routers around don't even have such settings, most users don't know what 802.11b is. Device manufacturers give priority to compatibility.

 

[sfx2000]

Disabling Wi-Fi standard has to be based on some collective agreement. We as users can't do much. Most consumer routers around don't even have such settings, most users don't know what 802.11b is. Device manufacturers give priority to compatibility.

Consensus in WIfi-Alliance, IEEE 802.11 WG, and the Broadband Forum have all agreed to deprecate 802.11 legacy support for both wireless connectivity along with auth/encryption - e.g. let us remove 801.11b legacy rates - as OFDM rates have a much higher level of access - and getting rid of another WPA and lower...

And then we have the whole multicast to unicast thing - it's likely good, but it breaks the spec as this is not allowed at the network level - and there's some handwaving that say's we can get away with it.

We are at a point where the new normal is as follows

1) WPA2 or newer
2) 802.11g/a/n or newer
3) Multicast Allowed on WiFi - and let the router handle IGMP snooping/proxy

Anyways - I'm still in the industry, and this is where things are headed...

 

[user114514]

Again - you're change 80211_MCAST, not 80211_BCAST - I've seen this very behavior on UNFI and others (it's a feature, right?? - most professional AP's (and course OpenWRT) - going legacy free is the default

Another thought here is the whole CellDensity thing, where we can limit association requests based on the minimum basic rate - that's fine, but again, if you don't disable legacy support in the driver - the beacon and management frames are still going at on 1Mbps, not 6, 12, whatever...

Ideally you want to ensure that the HR-DSSS mentioned below is disabled...

View attachment 66452

Not sure about the original OpenWRT, but at least on QSDK, mgmt, mcast, bcast, rtscts can all be adjusted independently of the basic rate, of course this only changes TX, RX is still determined by the STA. This fact is useful, on 5GHz, I set the AP's mgmt to 54Mbps, and the STA with lower txpower will still send at a more reliable 24Mbps.

 

[user114514]

Consensus in WIfi-Alliance, IEEE 802.11 WG, and the Broadband Forum have all agreed to deprecate 802.11 legacy support for both wireless connectivity along with auth/encryption - e.g. let us remove 801.11b legacy rates - as OFDM rates have a much higher level of access - and getting rid of another WPA and lower...

We are at a point where the new normal is as follows

1) WPA2 or newer
2) 802.11g/a/n or newer
3) Multicast Allowed on WiFi - and let the router handle IGMP snooping/proxy

Anyways - I'm still in the industry, and this is where things are headed...

I highly doubt these powerless organizations can actually change this. The fact that everyone is ignoring the WiFi7 security requirements shows that these "enforced" specifications just don't work.

And then we have the whole multicast to unicast thing - it's likely good, but it breaks the spec as this is not allowed at the network level - and there's some handwaving that say's we can get away with it.

I think 802.11v DMS allows for multicast to unicast, but few products seem to actually advertise it.

 

[sfx2000]

I highly doubt these powerless organizations can actually change this. The fact that everyone is ignoring the WiFi7 security requirements shows that these "enforced" specifications just don't work.

Key point though - with Carrier Gateways - it does have impact, and at present, they're doing a better job about it...

I think 802.11v DMS allows for multicast to unicast, but few products seem to actually advertise it.

Meh - most folks never implemented 11v as it was generally unworkable...

Most vendors have gone up a layer using IGMP snooping at the NIC interface...

 

[sfx2000]

Not sure about the original OpenWRT, but at least on QSDK, mgmt, mcast, bcast, rtscts can all be adjusted independently of the basic rate, of course this only changes TX, RX is still determined by the STA. This fact is useful, on 5GHz, I set the AP's mgmt to 54Mbps, and the STA with lower txpower will still send at a more reliable 24Mbps.

They can be adjusted - that's openwrt, not QSDK or the MediaTek SDK - both of which are built on OpenWRT...

You can play with things - but remember, there are rules to be followed - play around, and suddenly find out your IP cameras seem to have problems staying connected...

 

[sfx2000]

I highly doubt these powerless organizations can actually change this. The fact that everyone is ignoring the WiFi7 security requirements shows that these "enforced" specifications just don't work.

Good thing that you're not in charge, eh?

This is likely a good situation for a FOFA response for the vendors - frack around and find out what does not work...

 

[user114514]

Good thing that you're not in charge, eh?

This is likely a good situation for a FOFA response for the vendors - frack around and find out what does not work...

I mean, unlike Bluetooth's "mandatory" certification and strict scrutiny, WFA certification is optional and tacitly allows cheating.
Qualcomm and MediaTek know exactly why OEMs choose to cheat, otherwise there wouldn't be some workarounds in the drivers to do so.

Key point though - with Carrier Gateways - it does have impact, and at present, they're doing a better job about it...

ISPs clearly have their own ecosystems. 802.11s and easymesh have been popularised on a variety of ISP variant models since they were introduced, but they have never appeared on any general models. mesh and reduced customer support frequency is clearly one of the bottom lines for OEMs, and ISPs can change this within their own ecosystems, but again have no influence outside of that.

Meh - most folks never implemented 11v as it was generally unworkable...

Most vendors have gone up a layer using IGMP snooping at the NIC interface...

This again shows that WFA and 802.11 are just a dead letter.

 

[sfx2000]

Similarly, I force 11ax and WPA3 on 2.4GHz and set the bss basic rate to 24, 36, 48, 54. this keeps my bssload within 20% most of the time, even at 40MHz bandwidth.

Just wanted to circle back here - one doesn't need to force 11ax - going 11 g/n/ax/be is generally good enough - this puts the minimum basic rate to 6Mbit/Sec, but as you've mentioned, there are places where the min basic rate can be set higher, all depends on the AP density when running multiple AP's...

The Basic Rate is generally used for broadcast and multicast frames - this includes the management frames outside of the data frames which can be whatever the client and AP can use that are above the Basic Rate.

In a residential environment - basic rate of 6 is good enough for most - and mixed g/n/ax/be is generally kinder to neighbors, and actually can help with co-channel interference...

Getting rid of 11b support is huge for everyone - this even benefits older 11n clients...

 

[user114514]

Just wanted to circle back here - one doesn't need to force 11ax - going 11 g/n/ax/be is generally good enough - this puts the minimum basic rate to 6Mbit/Sec, but as you've mentioned, there are places where the min basic rate can be set higher, all depends on the AP density when running multiple AP's...

The Basic Rate is generally used for broadcast and multicast frames - this includes the management frames outside of the data frames which can be whatever the client and AP can use that are above the Basic Rate.

In a residential environment - basic rate of 6 is good enough for most - and mixed g/n/ax/be is generally kinder to neighbors, and actually can help with co-channel interference...

Getting rid of 11b support is huge for everyone - this even benefits older 11n clients...

Yes, I agree that 6Mbps is still an improvement, but 11ax-only will be a bigger step.

11ax is necessary for me because 11ac does not support 2.4GHz, and although most vendors support 2.4GHz VHT nowadays, you still need 11ax if you want reliable explicit TXBF. MU-MIMO is a gimmick in environments where AP MIMO capabilities are generally not enough to perform MU-TXBF and MU-MIMO simultaneously to provide sufficient spatial isolation, but other things introduced by 11ax are very useful for improving coexistence capabilities, such as OFDMA, bss color/SR. In my experiments, OFDMA does effectively control peak latency in concurrent scenarios, and NON-SRG SR does allow ignoring other weak BSS to improve utilization. In addition, the txpower of my AP is high enough that 1024QAM and higher basic rates can be achieved at a considerable distance, which in turn further reduces air-time occupancy.

11ax only does not remove the legacy preamble, so legacy devices can still recognize 11ax-only BSSs and do CSMA/CA, although due to SR, 11ax-only BSSs may ignore their existence, but this complies with ATF.

I bet that if every 2.4GHz device was 11ax, 2.4GHz would not be so crowded at all, and 40MHz would always be a reliable choice. Eliminating 11b will indeed reduce congestion, but I think 11ax is the way to go.

 

[sfx2000]

Yes, I agree that 6Mbps is still an improvement, but 11ax-only will be a bigger step.

11ax is necessary for me because 11ac does not support 2.4GHz, and although most vendors support 2.4GHz VHT nowadays, you still need 11ax if you want reliable explicit TXBF. MU-MIMO is a gimmick in environments where AP MIMO capabilities are generally not enough to perform MU-TXBF and MU-MIMO simultaneously to provide sufficient spatial isolation, but other things introduced by 11ax are very useful for improving coexistence capabilities, such as OFDMA, bss color/SR. In my experiments, OFDMA does effectively control peak latency in concurrent scenarios, and NON-SRG SR does allow ignoring other weak BSS to improve utilization. In addition, the txpower of my AP is high enough that 1024QAM and higher basic rates can be achieved at a considerable distance, which in turn further reduces air-time occupancy.

11ax only does not remove the legacy preamble, so legacy devices can still recognize 11ax-only BSSs and do CSMA/CA, although due to SR, 11ax-only BSSs may ignore their existence, but this complies with ATF.

I bet that if every 2.4GHz device was 11ax, 2.4GHz would not be so crowded at all, and 40MHz would always be a reliable choice. Eliminating 11b will indeed reduce congestion, but I think 11ax is the way to go.

Surprisingly - MU UL/DL and OfDMA generally don't apply for 2.4 in 11ax (I'll have to check for 11be) - there's upside for 2.4 with 11ax, which is the higher order modulation scheme, along with TWT which is good for IoT.

Explicit TxBF can still apply - but there's legacy concerns - and with 2*2:2 radios, it's kind of moot... not a lot of upside there with the increased level of management frames and most clients actually being 11n or 11g (and 11b)...

As mentioned - disabling 11b is huge in 2.4 - we get rid of ERP protection for 11b/g, and if we do g/n/ax/be - we also remove 11n greenfield mode with protections there (this is a bit of a thing with folks that worked on 11n - greenfield was a compromise that folks have regretted ever since that spec was approved)

 

[user114514]

Surprisingly - MU UL/DL and OfDMA generally don't apply for 2.4 in 11ax (I'll have to check for 11be) - there's upside for 2.4 with 11ax, which is the higher order modulation scheme, along with TWT which is good for IoT.

Explicit TxBF can still apply - but there's legacy concerns - and with 2*2:2 radios, it's kind of moot... not a lot of upside there with the increased level of management frames and most clients actually being 11n or 11g (and 11b)...

As mentioned - disabling 11b is huge in 2.4 - we get rid of ERP protection for 11b/g, and if we do g/n/ax/be - we also remove 11n greenfield mode with protections there (this is a bit of a thing with folks that worked on 11n - greenfield was a compromise that folks have regretted ever since that spec was approved)

The 11ax spec doesn't appear to claim that OFDMA doesn't work on 2.4GHz. The RU counts for 20MHz and 40MHz are a bit low, but they still work, and in practice they do: even the Pixel 8 Pro's BCM4398 supports 2.4GHz OFDMA. The only downside is that there don't seem to be any devices that support OFDMA RA.

My AP is 4x4 on all bands, so TXBF works great, making 1024QAM and 256QAM almost always work.

If I understand correctly, HT-GF does not apply to mgmt and beacon, which is really stupid. They should have designed Greenfield to be similar to HE on 6GHz today, and even mgmt and beacon should become HT-GF with R field, any device should support it, but it does not have to be enabled by default. In this way, people in the future can choose to enable Greenfield in a clean enough environment, just like we choose to disable 11b today. Both data frames with legacy preambles and legacy mgmt are a more terrible historical burden.

 

[sfx2000]

The 11ax spec doesn't appear to claim that OFDMA doesn't work on 2.4GHz. The RU counts for 20MHz and 40MHz are a bit low, but they still work, and in practice they do: even the Pixel 8 Pro's BCM4398 supports 2.4GHz OFDMA. The only downside is that there don't seem to be any devices that support OFDMA RA.

Most AP chipsets are avoiding OFDMA in 2.4 due to legacy issues...

OFDMA-RA - again there are issues - mostly around IP conflicts with LTE/5G patent holders that claim to have SEP, so they have to be paid...

Anyways - in 802.11 - OFMDA, along with UL-MU-MIMO is mostly some vendors getting their IP into the spec - that's always been the game, and years back, I was part of that unholy mess...

My AP is 4x4 on all bands, so TXBF works great, making 1024QAM and 256QAM almost always work.

That's fine - I've always been in favor in more spatial streams - but more spatial streams will not overcome basic physics - in 2.4 QAM256/1024 are very noise limited, but QAM64 is more robust across generations...

If I understand correctly, HT-GF does not apply to mgmt and beacon, which is really stupid. They should have designed Greenfield to be similar to HE on 6GHz today, and even mgmt and beacon should become HT-GF with R field, any device should support it, but it does not have to be enabled by default. In this way, people in the future can choose to enable Greenfield in a clean enough environment, just like we choose to disable 11b today. Both data frames with legacy preambles and legacy mgmt are a more terrible historical burden.

With HT-GF - remember this is 2.4 only - 5GHz never had that problem as it was always OFDM...

From a practical perspective - HT-Mixed was always the best bet in 2.4, and disabling the pre-11g modes was a win...