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?

[rotanid]

should be fixed in main Gluon branch now due to the changes merged by @blocktrron in #3411 ?

[blocktrron]

@rotanid I think so, only combination i have not tested is {mt7915,ath9k} <--> ath10k as I'm lacking ath10k 2.4G devices at home.

If anybody got his hand on these, please report if meshing from v2023.2.x with current master still works!

[maurerle]

@blocktrron should the ath10k device be running current main or the mt7915/ath9k for this test?

Or do we need to verify both directions?

[blocktrron]

@maurerle as the software version is part of the constellation - yes, both directions.

[maurerle]

I think I now understand the behavior better.
Following a paraphrasing from your commit messages:
All gluon devices support 802.11b and 802.11n - so they can handle receiving incompatible basic rates.
To not ignore "wrong" basic rates, d6e74f0 is implemented.

Gluon main devices announce a basic rate of > 1 MBit/s, though the counterpart does not support this.
That's why patch always pretend 1 Mbit/s as mesh basic rate 06e421e fixes this by always pretending the basic rate is 1MBit/s but are actually using the mcast set value..?

That way, a ignoring basic rate mismatch is always triggered, as both devices communicate with a basic rate of > 1 MBit/s but communicate that they would use 1MBit/s to others to be backwards compatible.
Which was fixed now in #3416

when can we remove these additional patches?
So we can remove the 06e421e when support for mesh with gluon < v2025 is not required anymore? But would have to keep d6e74f0 until meshing with this release is not required anymore..?
Or never

Missing link: why is 912527a required? Does this mean, that the basic rate was not properly selected before as we are not using wpa_supplicant?

Maybe this helps others to get a better unterstanding, eventually this is plain wrong, so please correct me if I am missing something @blocktrron

[maurerle]

Hi @blocktrron

I just tested this on a FB7520/ipq40xx-generic/ath10k device on main in combination with various v2023.2.3 devices:

While it somehow sees the other devices, it does not establish a mesh link to them over 5GHz wifi as seen in batman:

root@ffac-7520-002:~# batctl n
[B.A.T.M.A.N. adv 2024.3-openwrt-3, MainIF/MAC: primary0/b2:dc:da:05:27:43 (bat0/2c:3a:fd:d7:94:03 BATMAN_IV)]
IF             Neighbor              last-seen
        mesh1	  22:6a:92:51:f8:c5    3.960s

(here mesh on radio0, 2.4GHz was deactivated, so we only see one other device on gluon main successfully, but none of the devices running v2023.2.3 on 5GHz)

while there are other mt76, ath10k and ath9k devices on v2023.2.3 around, which should be seen on 5GHz.

Things are working fine on 2.4GHz - though I have the feeling, that name resolution on the status page is taking much longer (or forever).

[maurerle]

The same behavior as for the FB7520/ath10k device can be seen for a Cudy WR3000/mt76.

So mesh links on 2.4GHz are working fine between gluon main and v2023.2.6, but mesh on 5GHz does only see other devices on gluon main.

Behavior is the same in the other direction (looking from a ath10k Extreme Networks WS-AP3915i on stable to the WR3000 on main)

[blocktrron]

@maurerle thanks for testing. I rework the basic rate announcement override patch to only fake the basic rate on 2.4 GHz radios.

I highly assume this is currently the problem there.

Good catch!

[blocktrron]

@maurerle please test #3419