802.11s mesh + channel auto-discovery

Experimenting with mesh (SO's new computer doesn't have a wifi built in and dongle is crap) and I got everything working as per guide in the wiki: https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s#mesh11sd_-_setting_parameters_and_options

However if I change the channel on the main mesh device, the mesh node disconnects. I'm wondering what's a good way to auto-discover the new channel for the main mesh device:

  1. Is there a way to scan it from the mesh node?
  2. Should I iterate over available (2g) channels and see if I can connect to a station on them?
  3. Anything else?


1 Like
  1. You should probably switch to WDS. Mesh is used when you have specific requirements (multipath+automatic failover). And there is no point to use mesh with just 2 nodes.

Yes. In fact the next version of mesh11sd should be able to do this autonomously, but unfortunately not the current version.

It is quite simple. On the gateway meshnode (the one cable connected to your router, or the router itself if configured that way, use mesh11sd to set the parameter mesh_connected_to_gate.

Then on other meshnode(s) scan for meshnodes with the same mesh id and find the one that shows "connected to gate". Read its channel and set the channel accordingly.

Edit: The full protocol involves the parameter mesh_connected_to_as as well, but when you only have two or three meshnodes close-ish together, its fine just to use connected to gate.

This is only available from 22.03.0 onwards.

1 Like

That's not the point.

Since this is not affected by runtime is it something I can enable in the wireless interface settings to avoid using mesh11sd? On the main router/gateway connected node using mesh11sd is not an issue, however on the other end it's a low-end GL-Inet box and I've monitored resource consumption on it with htop and installing/running mesh11sd causes extra memory usage which I'd like to avoid.

How? I'd be grateful if you hold my hand thru it, not very familiar with iw.

1 Like

No. Most mesh parameters cannot be set in the wireless settings.

Mesh11sd is tiny. It should be almost unnoticeable. ....
I regularly run mesh11sd on gl-mt300n-v2, quite large numbers in some cases - neigbourhood mesh type of deployments. Ideal for the job.
What else do you have running on your gl box?

I'll see if i can send you a script snippet tomorrow -- it's late here..


Would appreciate it.

1 Like

Sorry for the long delay!

First for this to work you need to remove the package iw and install iw-full in its place.
It seem only slightly bigger so should not be a problem. I have it on a gl-mt300n-v2 along with a full suite of PHP and still have 2.8MB free flash.

Second, on the meshnode (the one with the Internet feed) do the following:

uci set mesh11sd.mesh_params.mesh_connected_to_gate='1'
uci commit mesh11sd

For a basic scan the syntax is iw dev mesh0 scan where mesh0 is the mesh ifname.

But this gives everything in range, so we need to filter the output. Given the mesh id is something we set then (assuming it is for example "mymesh"):

iw dev mesh0 scan | grep -A 20 "MESH ID: mymesh"
BSS 94:83:c4:09:44:64(on mesh0)
	last seen: 29059.933s [boottime]
	TSF: 46389555619 usec (0d, 12:53:09)
	freq: 2412
	beacon interval: 100 TUs
	capability: Privacy (0x0010)
	signal: -25.00 dBm
	last seen: 910 ms ago
	Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0* 9.0 12.0* 18.0 
	DS Parameter set: channel 1
	TIM: DTIM Count 0 DTIM Period 2 Bitmap Control 0x0 Bitmap[0] 0x0
	Extended supported rates: 24.0* 36.0 48.0 54.0 
	RSN:	 * Version: 1
		 * Group cipher: CCMP
		 * Pairwise ciphers: CCMP
		 * Authentication suites: SAE
		 * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)
	HT capabilities:
		Capabilities: 0x1fe
			SM Power Save disabled
			RX Greenfield
			RX HT20 SGI
			RX HT40 SGI
			RX STBC 1-stream
			Max AMSDU length: 3839 bytes
		Maximum RX AMPDU length 65535 bytes (exponent: 0x003)
		Minimum RX AMPDU time spacing: No restriction (0x00)
		HT TX/RX MCS rate indexes supported: 0-15
	HT operation:
		 * primary channel: 1
		 * secondary channel offset: above
		 * STA channel width: any
		 * RIFS: 0
		 * HT protection: no
		 * non-GF present: 0
		 * OBSS non-GF present: 0
		 * dual beacon: 0
		 * dual CTS protection: 0
		 * STBC beacon: 0
		 * L-SIG TXOP Prot: 0
		 * PCO active: 0
		 * PCO phase: 0
	MESH ID: mymesh
	MESH Configuration:
		 * Active Path Selection Protocol ID: 1
		 * Active Path Selection Metric ID: 1
		 * Congestion Control Mode ID: 0
		 * Synchronization Method ID: 1
		 * Authentication Protocol ID: 1
		 * Mesh Formation Info:
			 Number of Peerings: 1
			 Connected to Mesh Gate
		 * Mesh Capability
			 Accepting Additional Mesh Peerings

Now a few lines down from the top you will see (in this case:
freq: 2412 (this is channel 1)

This is the frequency used in MHz.
You can make a lookup table from the data here:

A quick bit more filtering strips out the actual frequency value:
iw dev mesh0 scan | grep -B 50 -A 20 "MESH ID: mymesh" | grep "freq:" | awk -F "freq: " '{print $2}'

Now you can use uci command line to change the local channel as required, issuing a wifi command at the end.

You could make a daemon using your perfected script and have it check the channel very minute or so....

Of course if you have lots of meshnodes over a wide area it will need something more complex to propagate the channel change out from the gateway node, but the scanning and updating principle is the same.


Thanks @bluewavenet this is gold!

1 Like

The plan is to implement this in an upcoming version of mesh11sd... "soon" :wink:

1 Like

A few follow-up questions if you don't mind.

Can I not use this rather than decipher frequencies?

Also, if I switch the channel on the main router (the main/gateway connected mesh node), what tool can I use to detect the disconnection on the secondary node? Even with the channel mismatch, the iw dev mesh0 station dump still shows the other station.

1 Like

Yes of course, I've just jumped ahead of myself a bit for large area mesh scenario.

You have to wait for the various timeouts to expire, the most important being mesh_holding_timeout if I remember correctly. This is in seconds I think...

It has usually gone from mpath dump after a couple of minutes anyway.

1 Like

You don't really need to detect it, the second node scans for the new channel....

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.