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:
Is there a way to scan it from the mesh node?
Should I iterate over available (2g) channels and see if I can connect to a station on them?
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.
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.
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..
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
Scan
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
SSID:
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
HT20/HT40
SM Power Save disabled
RX Greenfield
RX HT20 SGI
RX HT40 SGI
TX STBC
RX STBC 1-stream
Max AMSDU length: 3839 bytes
No DSSS/CCK HT40
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
Forwarding
........
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: https://en.wikipedia.org/wiki/List_of_WLAN_channels
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.
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.
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.
