802.11s stopped working with DFS channels in ETSI domain between 21.02.2 and 21.02.3 - what changed?

For Developers
1

Crossposting 802.11s-related changes between 21.02.2 and 21.02.3? Problems with mesh after upgrade here because my question is really one for more experienced developers. Somehow, between 21.02.2 and 21.02.3 some commit has stopped the 802.11s network (with batman-adv, but the problem is on the 802.11s level) between my R7800 and my ACM 3000 from working.

I'm on an ETSI domain and I have to use a DFS channel (100+). Since 21.02.3 (and later), the mesh detects the new peer, but then errors out with Mesh MPM: failed to send peering frame (detailed logs in the other thread). Everything works fine if I either:

  • change to a non-DFS channel, or
  • change to a non-ETSI domain, or
  • move back to 21.02.2.

I have tried dissecting the commits in between manually, but my build foo and kernel/OpenWRT knowledge is not that great (and some commits simply don't compile by without further changes).

1 Like
2

FWIW, this also applies to 22.03.x and (probably) master. If someone with more knowledge could weigh in, it would be really helpful.

3

So no one has an idea what changed?

4

This problem is still open? Is there a GitHub issue?

5

I am assuming it is still not fixed, but I haven't tried with more recent main snapshots (I think I last tested about six months ago). The GItHub issue is https://github.com/openwrt/openwrt/issues/10098.

1 Like
6

And it won't be. In the ETSI region:

Channel access and occupation rules: WAS/RLANs operating in the band 5250–5350 MHz shall use mitigation techniques that give at least the same protection as the detection, operational and response requirements described in EN 301 893 to ensure compatible operation with radiodetermination systems (radars). Such mitigation techniques shall equalise the probability of selecting a specific channel for all available channels so as to ensure, on average, a near-uniform spread of spectrum loading. The equipment shall implement an adequate spectrum sharing mechanism in order to facilitate sharing between the various technologies and applications. The adequate spectrum sharing mechanism can be e.g. LBT (Listen Before Talk), DAA (Detect And Avoid) or any other mechanism providing a similar level of mitigation. EN 301 893 / ECC/DEC/(04)08 / ERC/REC 70-03, Annex A.

and

Channel access and occupation rules: WAS/RLANs operating in the bands 5470–5725 MHz shall use mitigation techniques that give at least the same protection as the detection, operational and response requirements described in EN 301 893 to ensure compatible operation with radiodetermination systems (radars). Such mitigation techniques shall equalise the probability of selecting a specific channel for all available channels so as to ensure, on average, a near-uniform spread of spectrum loading. The equipment shall implement an adequate spectrum sharing mechanism in order to facilitate sharing between the various technologies and applications. The adequate spectrum sharing mechanism can be e.g. LBT (Listen Before Talk), DAA (Detect And Avoid) or any other mechanism providing a similar level of mitigation. EN 301 893 / ECC/DEC/(04)08 /-.

The key words are:

Such mitigation techniques shall equalise the probability of selecting a specific channel for all available channels so as to ensure, on average, a near-uniform spread of spectrum loading.

An 802.11s mesh network is incompatible with this as it requires ALL nodes to be working on the same channel, ie by definition, there cannot be a near-uniform spread.

7

I am not sure what the channel selection algorithm has got todo with an 802.11s connection not coming up at all (with both nodes on the same channel and obviously communicating with each other according to the logs).

8

Make your mind up. The connection does not come up but nodes communicate with each other - somewhat of a contradiction.
What logs are you referring to?

You miss the point. According to the ETSI DFS "channel selection algorithm", if one radio sees another on its channel, it should jump to another channel, to spread the spectrum loading.
This of course will break the mesh link.

9

The nodes see each other ("new peer notification"), but don't finish the peering protocol.

I find it hard to believe that the interpretation of ETSI rules you are giving here is correct, as there would never be any WiFi connection at all, because even STA/AP mode must necessarily operate at least two radios on the same channel. However, I don't have the technical expertise here to argue this one way or another, so I'll stick to the fact that I have been answering @NinjaBreaker's question.

10

For clarification:
An unconnected STA radio will for the most part just listen in LBT mode (Listen Before Talk), and an AP or Mesh radio will actively be in DAA mode (Detect And Avoid).

The consequence of this is STA can connect to AP and stay connected as long as the AP does not have a "radar" detection, but Mesh cannot stay connected to Mesh when using DSA channels.
This does seem to apply only to ETSI, explaining why other regions are not effected.

1 Like