Can we change the "Legacy_rates" setting in development branch to enable option!?

Hi, Admin:

Thanks for great supporting this website.
We are one IOT IC design house with 802.11b capability.

Based on field feedback from customer, we found serveral Router OEM vendors use OpenWRT as their router carrier. That means OpenWRT is a very good solution.

But customer feedback that our device cannot connect to the router. After debugging, we found that OEM vendors doesn't support 11b PHY either they change to 802.11 b/g/n modes. After checking setting of OpenWrt, we found "Legacy_rates" may be set to "Disabled" in development branch. Most OEM vendors may pull one development branch and just use it for production.

Such OEM vendors, such as : ComFi B8220, Mecury D190/D196G , Mecury D191, Mercury YR1900MG, etc...

Thus, can we suggest to change the default setting for "Legacy_rates" to enabled either in stable or development branch.

Thanks for your great helping!!

(upload://88iDv58tLzm6Y5OS9n8ICWZ1s96.png)

The default was intentionally switched to "disabled" recently, in December last year. 802.11b is rare, and support for it degrades performance for generic WiFi traffic.

There was quite much discussion in the PR:

Commit itself
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=ce5bcff304e474d604ac0e25de7b6b124f764351

Note that as OEM vendors typically use some older OpenWrt branch as base, the OpenWrt default here has already been "enabled", and the OEM vendors have then changed it to disabled in their implementations. OEMs generally aim for best performance in soho usage, so performance degrading 802.11b support has been a natural disable target for them.

3 Likes

Hi smlin998,

There is a good explanation at the following link as to why the default for legacy_rates should not on the balance of equities be changed back in OpenWRT. The change is for the greater good and better health of the wider 802.11 ecosystem: https://divdyn.com/disable-lower-legacy-data-rates/

Instead, those who have a specific and unusual need for legacy 802.11b support should enable this at this point.

This means that if and where an OEM vendor has configured legacy_rates to disabled in their product and also does not offer a configurable option to enable 802.11b, they should be contacted with an enhancement request to add this as an option.

I looked around for IOT scope ICs that might be in scope and found Rockchip's RKi6000 https://www.anandtech.com/show/9329/rockchip-announces-rki6000

This product, for example, looks fundamentally misguided in that it depends on such an old 802.11 standard.

I suggest that your company looks to support 802.11g OFDM defined rates as a minimum for future development in a newer generation chips as these rates will be used for a long while, unlike the 802.11b DSSS and HR-DSSS rates which are rightly being phased out by default. Otherwise, Zigbee etc. would seem a better approach for IOT purposes.

The reason that OFDM data rates will have a long life is that by 802.11 specification, only DSSS (802.11), HR-DSSS (802.11b) and OFDM (802.11a/802.11g) defined data rates can be used as basic or supported rates. MCS rates are not used to transmit management and control frames.

Best,

Nick

1 Like

Hi, Nick:

Thanks for your explanation!! YES, we are developing 802.11 b/g/n/ax in our next generation chips to shoot for IOT segment to get better power management and compatibility.

As your suggestion, we will contact with OEM vendor if they don't provide an option to enable 802.11b rates. Though, we know the 802.11b will degrade the overall performance within Wi-Fi system. But it is a better technology to boost the power, extend the range and lower the SNR requirement. That's why we choose 802.11b as IOT carrier :slight_smile:

Finally, thanks for your help and explanation.

B/R,

Simon.