There are lots of threads on this forum about it.
In my opinion it does not work reliably and is more trouble than it is worth.
In my experience, having different ssids and "training" your devices with each ssid, while reducing the transmitted power etc works much better, with devices generally switching from ssid to ssid according to signal strength.
Now to deal with unstable paths - or have you done so already by relocating peers?
Just trying to confirm, but by interference you mean these messages that i posted earlier right ?
gw_ip=192.168.0.1..
Wed May 15 20:34:12 2024 daemon.debug mesh11sd[1855]: Leaving check portal....
Wed May 15 20:34:13 2024 daemon.info mesh11sd[1855]: Path to station [ ] is stable
Wed May 15 20:34:13 2024 daemon.warn mesh11sd[1855]: Warning! Station [ ] is an immediate neighbour, but has had [ 5 ] path_change(s) detected
Wed May 15 20:34:13 2024 daemon.warn mesh11sd[1855]: Warning! Station [ ], consider its location or adjust txpower and/or rssi_threshold
Wed May 15 20:34:13 2024 daemon.debug mesh11sd[1855]: checkinterval 10 seconds
No, not interference. I mean path changes.
This means it has changed path at least once since the last checkinterval (10 seconds) and this will be bad for tcp/ip packets.
The layout of the nodes is important here. If there is one node in the middle of the overlapping coverage of the other two for example....
If I move the station a little closer to the portal then I stop getting the Warnings. Just to clarify, the warning means that the path to the portal for the station on question was constantly changing?
That being said how do I get to keep the station in the original location(I have some ethernet connected machines there which I don't want to move) and still not get the warning? lower the rssi_threshold to -80 for the mesh network for instance ?
Also, I have only one SSID across all three nodes(each node has the same SSID for 2g/5g) and the speed test is coming up really slow now. Is that a problem? is any tuning on tx-power required?(mentioning based on my reading of other discussions regarding that)
Also, can you please help to share the commands for switching the mesh to 5ghz band and testing it out?
Yes.
No, this is a "threshold" in dBm (a log scale meaning decibels relative to 1 milliwatt).
So lowering the threshold (making it more negative) will allow weaker signals to connect. What we would want is the opposite, ie block higher signal strengths.
But this would be what we would want if the 3 nodes were wider spread in distance from each other.
But as you want the intermediate node primarily to provide ethernet connections to fixed, wired devices, and not to contribute to mesh backhaul, we can change this intermediate node into "leech mode". Here it will connect to the mesh backhaul, but will not contribute to it.
On the intermediate node, do:
service mesh11sd stop
uci set mesh11sd.setup.mesh_gate_only='1'
uci commit mesh11sd
service mesh11sd start; exit
Now wait a little while for it to rejoin the mesh, monitoring on the portal node with logread -f if you wish, and see if the paths stabilise - may take a few minutes.
Yes we will do this, but first lest fix the intermediate node issue.
This is because of the constantly changing paths. For example, TCP connections will be constantly dropping packets and retrying.
I had actually already tried that.. that did not fix it. For some reason the portal is still connecting to it and classifying it as immediate neighbor in logs. I rebooted the portal and the intermediate node but still I see the same problem.
Another thing I have tried is to change the mesh_rssi_threshold to -55 but that also does not prevent the portal from connecting to the intermediate node(wich has mesh_gate_only=1).
let me try increasing the txpower(currently 21) to something like 25 and see if that makes a difference.
It depends on the actual layout of the nodes.
Set the intermediate back to mesh_gate_only='0' in the same way you did setting it.
Then set mesh_gate_only='1' on the furthest node.
It does sound like you have strong signals and loads of reflections everywhere.
Increasing mesh_rssi_threshold (towards zero) can help.
BUT increasing txpower can only make things much worse. You would have to reduce tx power on the node causing the problem.
On the portal, show me the output of mesh11sd stations...
I had set mesh_gate_only=1 in the node furthest from the portal. But still the portal and the other node were connecting to this and I could see logs similar to before about paths.
To simplify things I have remove the node in between and now i have two nodes:
- Portal
- Farthest node
Now i see no messages in the log.
mesh11sd stations shows signal strength as -62/64.
Threshold is -65
But the internet speed is very slow if i am connecting to furthest node and very fast i am connecting to portal.
I don’t really have any other things to try.. any ideas ?
I need to clarify what this means with respect to a leech node.
The important path is the path to the portal.
I will give an example from my test system. For this putpose I have set it up to be similar to yours, two nodes, widely spaced to give coverage, then a third node added between the first two. This intermediate node is set as a leech node (mesh_gate_only=1). Transmit power and mesh_rssi_threshold settings are left at default on all three nodes.
On the portal, the logs show:
Sat May 18 05:38:31 2024 daemon.debug mesh11sd[30501]: interface m-11s-0 is up
Sat May 18 05:38:31 2024 daemon.debug mesh11sd[30501]: node [DEST,ADDR]
Sat May 18 05:38:31 2024 daemon.debug mesh11sd[30501]: node [e6:95:6e:44:60:2e,e6:95:6e:44:60:2e]
Sat May 18 05:38:31 2024 daemon.debug mesh11sd[30501]: node [96:83:c4:06:71:50,96:83:c4:06:71:50]
Sat May 18 05:38:31 2024 daemon.debug mesh11sd[30501]: Entering check portal.... lan
Sat May 18 05:38:31 2024 daemon.debug mesh11sd[30501]: In get_portal_state. firstloop=0...
Sat May 18 05:38:32 2024 daemon.debug mesh11sd[30501]: default_gw=default via 192.168.8.1 dev eth0 src 192.168.8.242 ....
Sat May 18 05:38:33 2024 daemon.debug mesh11sd[30501]: leaving get_portal_state - is_portal=REACHABLE.. gwstatus=REACHABLE.. gw_ip=192.168.8.1..
Sat May 18 05:38:33 2024 daemon.debug mesh11sd[30501]: Leaving check portal....
Sat May 18 05:38:33 2024 daemon.info mesh11sd[30501]: Path to station [ e6:95:6e:44:60:2e ] is stable
Sat May 18 05:38:33 2024 daemon.info mesh11sd[30501]: Path to station [ 96:83:c4:06:71:50 ] is stable
Sat May 18 05:38:33 2024 daemon.debug mesh11sd[30501]: checkinterval 10 seconds
On the intermediate leech node:
Sat May 18 05:40:21 2024 daemon.debug mesh11sd[13259]: interface m-11s-0 is up
Sat May 18 05:40:23 2024 daemon.debug mesh11sd[13259]: node [DEST,ADDR]
Sat May 18 05:40:23 2024 daemon.debug mesh11sd[13259]: node [96:83:c4:06:71:50,96:83:c4:2c:c5:25]
Sat May 18 05:40:23 2024 daemon.debug mesh11sd[13259]: node [96:83:c4:2c:c5:25,96:83:c4:2c:c5:25]
Sat May 18 05:40:23 2024 daemon.debug mesh11sd[13259]: Entering check portal.... lan
Sat May 18 05:40:23 2024 daemon.debug mesh11sd[13259]: In get_portal_state. firstloop=0...
Sat May 18 05:40:23 2024 daemon.debug mesh11sd[13259]: default_gw=default via 192.168.1.1 dev br-lan ....
Sat May 18 05:40:24 2024 daemon.debug mesh11sd[13259]: leaving get_portal_state - is_portal=.. gwstatus=.. gw_ip=192.168.1.1..
Sat May 18 05:40:24 2024 daemon.debug mesh11sd[13259]: checking for working channel....
Sat May 18 05:40:24 2024 daemon.debug mesh11sd[13259]: Leaving check portal....
Sat May 18 05:40:26 2024 daemon.warn mesh11sd[13259]: Warning! Station [ 96:83:c4:06:71:50 ] is [ 2 ] hops away and [ 240 ] path_change(s) for station have been detected
Sat May 18 05:40:26 2024 daemon.warn mesh11sd[13259]: Warning! Station [ 96:83:c4:06:71:50 ], consider its location or adjust txpower and/or rssi_threshold
Sat May 18 05:40:26 2024 daemon.info mesh11sd[13259]: Path to station [ 96:83:c4:2c:c5:25 ] is stable
Sat May 18 05:40:26 2024 daemon.debug mesh11sd[13259]: checkinterval 10 seconds
Here "96:83:c4:2c:c5:25" is the portal, "96:83:c4:06:71:50" is the remote node, and "e6:95:6e:44:60:2e" is the leech (intermediate) node.
You can see the leech node has a stable connection with the portal as is required, but has an unstable path to the remote node, but it does not need to send packets to the remote so this does not matter.
If we look at mesh11sd stations on the portal:
root@meshnode-c525:/tmp# mesh11sd stations
===========================================================================
Stations connected to this node:
Station 96:83:c4:06:71:50 (on m-11s-0)
inactive time: 700 ms
rx bytes: 120828724
rx packets: 1371226
tx bytes: 40121008
tx packets: 62479
tx retries: 48145
tx failed: 48302
rx drop misc: 103835
signal: -71 [-76, -72] dBm
signal avg: -70 [-76, -71] dBm
Toffset: 66949007675 us
tx bitrate: 162.0 MBit/s MCS 12 40MHz
tx duration: 145344796 us
rx bitrate: 90.0 MBit/s MCS 10 40MHz short GI
rx duration: 31761294 us
last ack signal:-67 dBm
avg ack signal: -68 dBm
airtime weight: 256
mesh llid: 0
mesh plid: 0
mesh plink: ESTAB
mesh airtime link metric: 90
mesh connected to gate: yes
mesh connected to auth server: no
mesh local PS mode: ACTIVE
mesh peer PS mode: ACTIVE
mesh non-peer PS mode: ACTIVE
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: yes
TDLS peer: no
DTIM period: 2
beacon interval:100
connected time: 67283 seconds
associated at [boottime]: 62154.405s
associated at: 1715944052575 ms
current time: 1716011335190 ms
Station e6:95:6e:44:60:2e (on m-11s-0)
inactive time: 30 ms
rx bytes: 2170245
rx packets: 22974
tx bytes: 171496
tx packets: 1339
tx retries: 218
tx failed: 218
rx drop misc: 50
signal: -20 [-26, -21] dBm
signal avg: -19 [-26, -21] dBm
Toffset: 494846894186 us
tx bitrate: 270.0 MBit/s MCS 15 40MHz
tx duration: 1825372 us
rx bitrate: 300.0 MBit/s MCS 15 40MHz short GI
rx duration: 642477 us
last ack signal:-19 dBm
avg ack signal: -18 dBm
airtime weight: 256
mesh llid: 0
mesh plid: 0
mesh plink: ESTAB
mesh airtime link metric: 55
mesh connected to gate: yes
mesh connected to auth server: no
mesh local PS mode: ACTIVE
mesh peer PS mode: ACTIVE
mesh non-peer PS mode: ACTIVE
authorized: yes
authenticated: yes
associated: yes
preamble: long
WMM/WME: yes
MFP: yes
TDLS peer: no
DTIM period: 2
beacon interval:100
connected time: 1320 seconds
associated at [boottime]: 128117.920s
associated at: 1716010016090 ms
current time: 1716011335190 ms
===========================================================================
root@meshnode-c525:/tmp#
This shows good connectivity to both the leech and remote peer, with a low value of mesh "airtime link metric" and tx and rx bitrates up where should be expected.
In your setup, you should have the intermediate set to leech mode and ther remote in normal peer mode.
Once you are back to this, show what you get from mesh11sd stations.
This should give a good indication of what is happening.
Thanks for the explanation. I have to cover two floors with the three nodes I have. So I need to have a triangle topology, practically speaking. Also I reset all my nodes and did a simple test with two nodes meshed using 2g and measured the speed at the non portal node. Then I tried to do the same with 5g but it turned out to be harder with auto-config. mesh11sd seems to use all 5g radios and my router has 2 of them and they just thrash each other with interference and did not really work. So I wrote up some manual config and flashed all 3 nodes, measured signal strength, put all of them in a triangular shape at the edge of the threshold values. After a lot of tweaking/moving around, I have a setup that seems to work and results in +-10% of speed near mesh.
I am using 5G for the meash and the speeds are just crazy high(30 mbps/vs 180 mbps). I have stared at logread -f enough by now and I don't see any warnings.
Now I just need a guest network setup which I can try after testing these out for a week atleast.
Thank your help now!
Yes, that is the beta version you are using. This was fixed in a later beta, which is why I suggested we finish testing on 2g first - but never mind 
If possible the mesh_gate_only=1 nodes should probably not issue warning messages in case their paths are changing. That would be useful.
Another thing I have notice is that even after changing the threshold values, the associations would not be dropped for some time and the connections would still show up in mesh11sd stations. Is there a delay between changing the config and connections actually getting dropped ?
Remember you are using a beta version that has been superseded over the time since you installed it. Reactive stabilisation of paths has since been enabled along with some friendlier debug messages.
This is because the mesh_rssi_threshold only applies when a connection is attempted. Any changes do not effect existing connections.
In manual mode you will have to restart the wireless on the nodes after you make a change.
In auto mode you can use mesh11sd mesh_rssi_threshold + force to immediately enforce a 3dBm increase.
When satisfied you can use mesh11sd commit_changes commit to make it permanent.
gotcha.. I have started a new post for the guest network. Please chime in if you have the answer: