802.11s-related changes between 21.02.2 and 21.02.3? Problems with mesh after upgrade

[p.p]

mesh11sd doesn't seem to add anything useful logging-wise:

Sat Jul 16 12:56:01 2022 daemon.debug mesh11sd[1698]: interface wlan1-1 is up
Sat Jul 16 12:56:01 2022 daemon.debug mesh11sd[1698]: interface wlan1 is up
Sat Jul 16 12:56:01 2022 daemon.debug mesh11sd[1698]: interface wlan0-1 is up
Sat Jul 16 12:56:01 2022 daemon.debug mesh11sd[1698]: interface mesh0 is up
Sat Jul 16 12:56:02 2022 daemon.info mesh11sd[1698]: Old value:mesh_fwding=1, Setting new value:mesh_fwding=0
Sat Jul 16 12:56:02 2022 daemon.info mesh11sd[1698]: Old value:mesh_rssi_threshold=-80, Setting new value:mesh_rssi_threshold=0
Sat Jul 16 12:56:02 2022 daemon.info mesh11sd[1698]: Old value:mesh_fwding=0, Setting new value:mesh_fwding=1
Sat Jul 16 12:56:02 2022 daemon.info mesh11sd[1698]: Old value:mesh_rssi_threshold=0, Setting new value:mesh_rssi_threshold=-80
Sat Jul 16 12:56:02 2022 daemon.debug mesh11sd[1698]: nodelist [DEST,ADDR ]
Sat Jul 16 12:56:07 2022 daemon.notice wpa_supplicant[2019]: mesh0: new peer notification for <REPEATERMAC>
Sat Jul 16 12:56:07 2022 daemon.notice wpa_supplicant[2019]: mesh0: Mesh MPM: failed to send peering frame
Sat Jul 16 12:56:07 2022 daemon.notice wpa_supplicant[2019]: mesh0: Mesh MPM: failed to send peering frame
Sat Jul 16 12:56:07 2022 daemon.notice wpa_supplicant[2019]: mesh0: Mesh MPM: failed to send peering frame
Sat Jul 16 12:56:07 2022 daemon.notice wpa_supplicant[2019]: mesh0: Mesh MPM: failed to send peering frame

[Lynx]

Why do you need mesh/batman btw?

I have the feeling this may be more hassle than necessary and you could just switch to WDS.

[p.p]

Because I want/need separate VLANs. Also, everything has been working fine up until 21.02.3

[Lynx]

More than two? If not you can just have two WDS access points - one on 2.4 and one on 5. I have set that up for guest WiFi and ordinary WiFi.

Alternatively this:

Trunking over wireless?

I own a main router, that serves several separate wireless networks. And I also own a wireless extender, connected to the main router using WDS. However, the wireless extender can only extend one single network from the main router, as it cannot be configured as a client for several wireless network. On a wired network, I would just trunk all networks over the same wire, using VLANs, but I do not know how to do this over wifi. Do you have any ideas?

[p.p]

I started out that way, but batman has been much more manageable than GRE tunnels for me. (I am separating IoT devices from "normal" clients and I have separate SSIDs for 2.4 GHz and 5 GHz.) The repeater has a separate 5 GHz radio for uplink which can only do channels >= 100 and I have to avoid the U-NII 1 channels anyway as they are very crowded (almost as bad as 2.4 GHz).

[p.p]

For the record, I am using the CT firmware for the ath10k, but I've also tried a build with the mainline version with the same symptoms. The radio works fine, but the mesh peer cannot connect while using a DFS channel on an ETSI domain.

[_bernd]

I cannot add that much but I too have 802.11s and batman-adv and encryption. I have never got the mesh running with the CT firmware. Have you tried the non CT firmware already? And maybe I missed that point but why are you trying to run the mesh on a DFS channel? I would suggest start with a non DFS channel maybe even one for indoor use only and if that works continue.
And if you run batman-adv then you must(?) Disable mesh forwarding for 802.11s because batman does this for you...
I have this running on wdr3700, wdr4900 and archer c7v5 in case it matters.

[p.p]

Yes, I tried both firmwares. The mesh works fine as long as any one of the following conditions is true (OR conjunction):

• OpenWRT 21.02.2 or earlier
• Non-DFS channel
• Non-ETSI domain

I need to use a DFS channel because the dedicated backlink radio of the AP only supports channels 100+. The non-DFS channels in that range have a very low TX power limit (which works, but results in a much worse SNR/lower bandwidth). Besides, no one uses channel 108 and I have had no problem with actual radar interference here.

Also, on principle, it is a regression in a bugfix release and I'd have thought at least the change causing it should be easy to pinpoint.

[_bernd]

I see your issue/forum topic is mentioned in https://github.com/openwrt/openwrt/issues/10098. If you have a Github account I would suggest to raise your voice and issue again in this issue ticket, as it seams nobody here has any glues.
Sorry I can't help either.
(I assume that just using an "invalid" country code is not the best of all options? BUT I'm really no expert if this is even ever enforced/prosecuted by any radio agency or not and I don't want to be really that dude who says "just ignore the local regulations".)

[p.p]

Actual enforcement by the relevant authorities is unlikely (probably impossible even), but using the wrong regdom could degrade wireless networking for my neighbors (and introduce really hard to track incompatibilities with other devices), so I would not want to go down that route.

[p.p]

Still looking for more information on what changed between those revisions.

[_bernd]

Thanks for the reminder. I'm close to lift my setup to the latest release.... I maybe should setup a testbed first.

[p.p]

So I've now updated both the R7800 and the AVM3000 to the latest 22.03 snapshot and things have started to deteriorate even more. With the AVM on 22.03, the mesh doesn't even work with option country 'US' anymore. At least not reliably. Every once in a while when poking various parameters, everything would start to work miraculously, until the next boot. Maybe I should have a look at the mainline ath10k firmware again?

Anyway, on the R7800, iw dev if-mesh mesh_param dump has stopped working, it just lists the help text instead. Getting and setting individual parameters (e.g. iw dev if-mesh get mesh_param mesh_ttl) works fine however.

[theMan]

Cant you use channel 149 and up for the backhaul? Or can't you just switch around the two 5G radios?

I have my R7800 on channel 48 (Since it just have 1 5g radio I use the same radio as AP and Mesh). Asus Lyra dedicated backhaul on 48, and the other radio as AP on channel 149.

[p.p]

Those channels are limited to 25 mW, which barely works for the backhaul itself, but also limits coverage in other parts of the apartment.

Switching the radios would work, but the lower channels are pretty crowded already, so I'd much prefer fixing this regression

[shaman79]

Are there any news on this? I hit the same problem. Due to having mesh points far away from each other I need that higher channels for more power.

[p.p]

Unfortunately, no. I eventually switched the radios in my config, even though it is suboptimal (because the second 5 GHz radio has a limited throughput).