802.11s mesh is using 802.11b basic rates

[blocktrron]

Bug report

What is the problem?

The 802.11s mesh VAP uses 802.11b data-rates for it's beacon-rate as well as it's basic rates.

All regular client VAPs are working fine.

What is the expected behaviour?

802.11s mesh VAP should use basic-rates equal to it's mcast-rate.

Beacon should not be sent using 802.11b

Gluon Version:

v2023.2

Site Configuration:

freifunk-darmstadt/site-ffda@3ea1e1a

Custom patches:
None

[blocktrron]

A fix for this undesired behavior was submitted upstream here:

openwrt/openwrt#17332

i suspect this might also fix airtime-related issues on MT79x6 based radios. At least this is one driver which sets the beacon-rate depending on the basic-rate and not the mcast-rate. Normally the beacon rate is determined by the rate for a frame with a non-unicast STA. This is the mcast-rate for drivers which do not implement their own handling.

ath10k also accesses this field (and i might have seen such cases in the past if my memory is correct). Grep for bss_conf.basic_rates access on the wireless driver.

This change brings two problems with itself. The specification states that the basic-rates of two partners (STA - STA / AP - STA) must match. This is not the case anymore if two mesh-participants "meet" each other on different revisions.

As we fully control the software ecosystem, we can develop mitigations. I'm unsure in how to handle this situation:

• softmac drivers should be easy, as mesh-establishment is controlled in software. We could override the basic-rate requirement for mesh-partners
  • we have to consider how to handle the case when the RC drops to a non-g rate on the receiving end.
• Full-MAC drivers need to be evaluated for

Alternatively, a scheduled-domain-switch approach could be leveraged to switch after date X in software.

[Djfe]

side note: Could be interesting to know whether ath10k-ct accesses bss_conf.basic_rates as well 😅

Don't we currently already have different revisions in the field? Depending on the wifi driver some chips probably avoid 802.11b already by choosing their rate based on mcast, don't they? And they still mesh with each other, right? Simply makes me wonder whether we actually require mitigation?

Great work, thanks for finding a fix for the config. ❤️
I'm curious what others think about your suggestions. I don't have a preference but a domain switch sounds doable.

though there are always cases where there are devices that don't receive an update out there. If we implement mitigations: how long do we want to carry them for?