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

I'm currently running batman-adv VLANs over an 802.11s backlink (just two mesh nodes, with an R7800 as the router and an AVM 3000 as an additional access point to increase coverage in a physically difficult room). This works very well on 21.02.2(ish – both devices are running custom branch-builds including the necessary packages, including wpad-openssl).

Today I tried updating first the router and then both devices to 21.02.3ish builds using the same configs as the 21.02.2ish builds. However, as long as one of the devices is on a newer build, the mesh fails with wpa_supplicant[1853]: mesh0: Mesh MPM: failed to send peering frame.

The connection starts to happen on the physical level (according to iw dev if-mesh station dump and the Status view in LuCi), but somehow the connection process breaks down (flooding the log with the peering frame message above).

config wifi-iface 'wmesh'
	option device 'radio0'
	option ifname 'if-mesh'
	option mode 'mesh'
	option encryption 'sae'
	option mesh_id '<SSID>'
	option mesh_fwding '0'
	option mesh_rssi_threshold '0'
	option mesh_ttl '1'
	option mcast_rate '24000'
	option key '<password>'
	option network 'mesh'
	option skip_inactivity_poll '1'

Before reverting to the old firmware versions, I tried switching to wpad-wolfssl on both devices (without effect). I had no issues when going from 21.02.1 to 21.02.2 with the same config. The radios are set to channel 108, if that matters.

Hi, I have had the same problem. The solution for me was to change channel on the wireless interface. Seems like different country codes work.s with different channels, In my case I am using country code for Sweden and after upgrading to OpenWRT 21.02.3 I had to change from channel 64 to channel 48.

Here is some theoretic clues, that helped me find this solution:
Ubiquiti AP Mesh - OpenWrt Mesh over 5GHz https://github.com/openwrt/openwrt/issues/8042

/ Pj

Thank you. I saw those reports but assumed that the cause could not be related since e.g. 21.02.2 works fine, so the earlier issue evidently got fixed. Unfortunately, I cannot simply change the channel as the haul-back radio of the AP is limited to channels above 100.

I've now verified that the issue is indeed the regulatory domain. Setting it to US makes the mesh work again (although of course I'm not allowed to run the system that way). The question now is, what has changed? I've looked through the commits but could not find anything that looks likely (the hostapd changes appear to be unrelated to DFS).

Same here, did an upgrade yesterday to OpenWrt SNAPSHOT r19859-36e46c3c13 / LuCI Master git-22.167.28356-8effea5 and that breaks 802.11s Mesh with the same symptomes. Change to US makes it work but that's a kind of weird of course being in NL

Is just using WDS an option? I have the feeling for most use cases it is the better option. Certainly for me it has been stable across snapshots for the RT3200, whereas mesh has not been.

Unfortunately, no, I don't think WDS is an option as I'm using the mesh as the trunk for batman-adv.

So I don't need to try a master build. I had hoped that it really was a regression in 21.02.3 only :open_mouth:

There was an update to the latest DFS-ETSI standards. You are likely to have a quite long delay before a 5GHz radio will come up on high channel numbers, if at all and if it does come up it could shut down again at any time if the driver detects anything it thinks might be a radar.

Changing to US reg domain puts you on DFS-FCC which is much more relaxed, so will work - although not legal in ETSI areas.

While I'm interested in any information you have on that regdb change (I could not find any for the last year or so), I am pretty confident that this is not the issue here. The channel is coming up fine (i.e. I can connect to the other SSID running in AP mode, just the 802.11s connection fails when an ETSI domain is set. Also, this worked fine in 21.02.2.