Mesh wifi path changes with mesh11sd (r7800 + mi 3g)

Hi,
i've setup a 2.4G 40mhz mesh networt with the following devices:

Netgear R7800 build23.05.3 (Master with LAN) / 3rd floor
~63db to 3g 2nd floor
~85db to 3g 1st floor

Mi Router 3G v1 build23.05.3 (node) / 2nd floor
MAC: 7a:11:dc:4c:2d:e6
~ 60db to r7800 3rd floor
~ 60db to 3g 1st floor

Mi Router 3G v1 build23.05.3 (node) / 1st floor
MAC: 7a:11:dc:49:8c:3e
~56db to 3g 2nd floor
~86db to r7800

On all 3 routers i installed mesh11sd v4 beta 13 manually.
Then i created networks using luci, so the base network config is stored in /etc/config/wireless

The mesh network runs ok most of the time but sometimes it becomed pretty laggy.

Also the two 3g's regularly fail to login to r7800 mesh after some days. (mesh sae auth failure). i worked around by a reboot script if gw can not be reached on the two 3g's. it seems to be an unsolvable mt7621 bug, its ok for me with the script.

but what i see in the logs of r7800 and what i would like to solve now is that there seems to be direct connection between r7800 and 3g 1st floor although the signal strength is much too low.
i assumed mesh11sd should avoid the connection and stop these path changes.

Fri May 31 12:47:26 2024 daemon.warn mesh11sd[1432]: Warning! Station [ 7a:11:dc:49:8c:3e ] is [ 2 ] hops away and [ 7279 ] path_change(s) for station have been detected Fri May 31 12:47:26 2024 daemon.warn mesh11sd[1432]: Warning! Station [ 7a:11:dc:49:8c:3e ], consider its location or adjust txpower and/or rssi_threshold Fri May 31 12:47:26 2024 daemon.info mesh11sd[1432]: Path to station [ 7a:11:dc:4c:2d:e6 ] is stable

I setup mesh11sd with manual configuration and set the threshold parameter by commenting out in the mesh11sd config file like:
#option mesh_rssi_threshold '-70'
to:
option mesh_rssi_threshold '-75'

all other mesh11sd configs are still default/commented out.

do you have an idea how i can solve this and make the mesh respect the rssi threshold value?

mesh11sd status:

root@R7800-5B:~# mesh11sd status
{
  "setup":{
    "version":"4.0.0beta",
    "enabled":"1",
    "procd_status":"running",
    "portal_detect":"1",
    "portal_detect_threshold":"0",
    "portal_channel":"default",
    "mesh_basename":"m-11s-",
    "auto_config":"0",
    "auto_mesh_network":"lan",
    "auto_mesh_band":"2g40",
    "auto_mesh_id":"92d490daf46cfe534c56ddd669297e",
    "mesh_gate_enable":"1",
    "mesh_gate_only":"0",
    "mesh_gate_encryption":"0",
    "txpower":"20",
    "mesh_path_cost":"10",
    "checkinterval":"10",
    "interface_timeout":"10",
    "ssid_suffix_enable":"1",
    "debuglevel":"3"
  },
  "interfaces":{
    "mesh0":{
      "mesh_retry_timeout":"100",
      "mesh_confirm_timeout":"100",
      "mesh_holding_timeout":"100",
      "mesh_max_peer_links":"16",
      "mesh_max_retries":"3",
      "mesh_ttl":"31",
      "mesh_element_ttl":"31",
      "mesh_auto_open_plinks":"0",
      "mesh_hwmp_max_preq_retries":"4",
      "mesh_path_refresh_time":"1000",
      "mesh_min_discovery_timeout":"100",
      "mesh_hwmp_active_path_timeout":"5000",
      "mesh_hwmp_preq_min_interval":"10",
      "mesh_hwmp_net_diameter_traversal_time":"50",
      "mesh_hwmp_rootmode":"4",
      "mesh_hwmp_rann_interval":"5000",
      "mesh_gate_announcements":"1",
      "mesh_fwding":"1",
      "mesh_sync_offset_max_neighor":"50",
      "mesh_rssi_threshold":"-75",
      "mesh_hwmp_active_path_to_root_timeout":"6000",
      "mesh_hwmp_root_interval":"5000",
      "mesh_hwmp_confirmation_interval":"2000",
      "mesh_power_mode":"active",
      "mesh_awake_window":"10",
      "mesh_plink_timeout":"0",
      "mesh_connected_to_gate":"1",
      "mesh_nolearn":"0",
      "mesh_connected_to_as":"0",
      "mesh_id":"wrt-mesh",
      "device":"radio1",
      "channel":"1",
      "tx_packets":"423944",
      "tx_bytes":"196579617",
      "rx_packets":"463685",
      "rx_bytes":"74644549",
      "this_node":"cc:40:d0:49:87:57",
      "active_peers":"2",
      "peers":{
        "7a:11:dc:49:8c:3e":{
          "next_hop":"7a:11:dc:49:8c:3e",
          "hop_count":"1",
          "path_change_count":"7526",
          "metric":"265"
        },
        "7a:11:dc:4c:2d:e6":{
          "next_hop":"7a:11:dc:4c:2d:e6",
          "hop_count":"1",
          "path_change_count":"1165",
          "metric":"31"
        }
      },
      "active_stations":"19",
      "stations":{
        "00:1a:e8:60:e5:2e":{
          "proxy_node":"cc:40:d0:49:87:57"
        },
        "10:bf:67:e1:ff:9b":{
          "proxy_node":"cc:40:d0:49:87:57"
        },
        "b8:50:d8:4e:4c:6b":{
          "proxy_node":"cc:40:d0:49:87:57"
        },
        "54:ef:44:21:4b:7e":{
          "proxy_node":"cc:40:d0:49:87:57"
        },
        "92:54:30:73:4c:5e":{
          "proxy_node":"cc:40:d0:49:87:57"
        },
        "a0:68:1c:49:0f:d0":{
          "proxy_node":"cc:40:d0:49:87:57"
        },
        "40:31:3c:a8:7f:df":{
          "proxy_node":"cc:40:d0:49:87:57"
        },
        "d6:7c:64:1b:f5:07":{
          "proxy_node":"cc:40:d0:49:87:57"
        },
        "54:6c:eb:c6:ec:0b":{
          "proxy_node":"cc:40:d0:49:87:57"
        },
        "54:6c:eb:c6:ec:0b":{
          "proxy_node":"7a:11:dc:4c:2d:e6"
        },
        "b8:50:d8:53:e6:b7":{
          "proxy_node":"7a:11:dc:4c:2d:e6"
        },
        "b8:50:d8:52:b4:31":{
          "proxy_node":"7a:11:dc:4c:2d:e6"
        },
        "78:11:dc:49:8c:3c":{
          "proxy_node":"7a:11:dc:49:8c:3e"
        },
        "b8:50:d8:4e:42:04":{
          "proxy_node":"7a:11:dc:4c:2d:e6"
        },
        "b4:7c:9c:cd:e2:72":{
          "proxy_node":"7a:11:dc:4c:2d:e6"
        },
        "78:11:dc:4c:2d:e4":{
          "proxy_node":"7a:11:dc:4c:2d:e6"
        },
        "54:ef:44:31:e3:77":{
          "proxy_node":"7a:11:dc:4c:2d:e6"
        },
        "b8:50:d8:52:b6:0a":{
          "proxy_node":"7a:11:dc:4c:2d:e6"
        },
        "34:94:54:71:e8:db":{
          "proxy_node":"7a:11:dc:4c:2d:e6"
        }
      }
    }
  }
}

wireless config:

root@R7800-5B:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path 'soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '36'
        option band '5g'
        option htmode 'VHT80'
        option disabled '1'
        option country 'DE'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'GODZILLA-5G'
        option encryption 'psk2'
        option disabled '1'
        option key 'xxxxxxx'

config wifi-device 'radio1'
        option type 'mac80211'
        option path 'soc/1b700000.pci/pci0001:00/0001:00:00.0/0001:01:00.0'
        option channel '1'
        option band '2g'
        option htmode 'HT40'
        option country 'DE'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'GODZILLA'
        option encryption 'psk2'
        option key 'xxxxxxx'

config wifi-iface 'mesh'
        option device 'radio1'
        option mode 'mesh'
        option ifname 'mesh0'
        option network 'lan'
        option mesh_id 'wrt-mesh'
        option encryption 'sae'
        option key 'xxxxxxx'
        option mesh_fwding '1'
        option mesh_rssi_threshold '0'
        option macaddr 'CE:40:D0:49:87:5B'

thanks for any ideas :slight_smile
br zezinho

Why are you running this old and unofficial beta?
The current release is 4.0.1 and it has an option mesh_path_stabilisation that is on by default.

The default is -65dBm. Making the value a larger negative number makes the receiver more sensitive and therefore makes your problem worse.

The rssi threshold only takes effect when a peer node connects. Editing the config file directly should not be done (and won't work for an already connected peer), so you should use the mesh11sd cli to force a new value on all peers.

See the output of mesh11sd --help

You can increment and decrement the threshold 3dBm at a time and force a desired value on already connected peers.

But before you do anything, remove the old beta and install the current release, noting you need to delete the old config file as it is probably incompatible with the new version:

service mesh11sd stop
opkg remove mesh11sd
rm /etc/config/mesh11sd
opkg install mesh11sd

You should be good to go with this.

1 Like

Why are you running this old and unofficial beta?
The current release is 4.0.1 and it has an option mesh_path_stabilisation that is on by default.

Did not see this version yet. When i installed the system 2 weeks ago i think only 3.1.1 (which was not recommended) was in the repo !?

The default is -65dBm. Making the value a larger negative number makes the receiver more sensitive and therefore makes your problem worse.

Yes, i set it to 75 so that that the bad connection with 84db gets blocked and to have the same config file on alle 3 units. But as said without any effect.

I installed 4.0.1 now and will observe it, thank you already !

You mean you set it to MINUS 75 (-75 dBm).
This is MORE sensitive than the default.

If you change the value WHILE a peer is directly connected, it will make no difference. You have to change it using the mesh11sd command line with the "force" option to effect that already connected peer.

You can also change the transmit power with the mesh11sd command line.

Changing both rssi threshhold and transmit power on all the nodes can be used for optimisation of performance, but even without, the paths should be stabilised.

Read:

Yes i set it to -75 by editing the config file.
Yes i know it is more sensitive, but i was not sure if default config is really alive.

Afterwards i rebooted all 3 stations so that the new value gets active.
But with the default value of -65 and then -75, always the -84db node connected and caused path changes.

Thats why i ask myself which component is responsible to block the peer. If mesh11sd has the correct "rights" to disconnect nodes or if something is missing in my setup that i am not aware of.

Now after updating to 4.0.1 and having the new option you mentioned i observed that there were some log entries with path changes again, but it seems is the mesh stabilized then by removing the direct connection. See:

Fri May 31 21:22:24 2024 daemon.notice wpa_supplicant[802]: mesh0: mesh plink with 7a:11:dc:49:8c:3e established
Fri May 31 21:22:24 2024 daemon.notice wpa_supplicant[802]: mesh0: MESH-PEER-CONNECTED 7a:11:dc:49:8c:3e
Fri May 31 21:22:31 2024 daemon.debug mesh11sd[1440]: interface mesh0 is up
Fri May 31 21:22:32 2024 daemon.debug mesh11sd[1440]: node [DEST,ADDR]
Fri May 31 21:22:32 2024 daemon.debug mesh11sd[1440]: node [7a:11:dc:49:8c:3e,7a:11:dc:4c:2d:e6]
Fri May 31 21:22:32 2024 daemon.debug mesh11sd[1440]: node [7a:11:dc:4c:2d:e6,7a:11:dc:4c:2d:e6]
Fri May 31 21:22:32 2024 daemon.notice mesh11sd[1440]: Station [ 7a:11:dc:49:8c:3e ] is [ 2 ] hops away and [ 11 ] path_change(s) for station have been detected
Fri May 31 21:22:32 2024 daemon.debug mesh11sd[1440]: Station [ 7a:11:dc:49:8c:3e ] has an incrementing path change count, consider its location or adjust txpower and/or rssi_threshold
Fri May 31 21:22:32 2024 daemon.notice mesh11sd[1440]: Stabilsing path to node [ 7a:11:dc:49:8c:3e ]
Fri May 31 21:22:32 2024 kern.warn kernel: [13938.656610] ath10k_pci 0001:01:00.0: peer-unmap-event: unknown peer id 60
Fri May 31 21:22:32 2024 daemon.info mesh11sd[1440]: Path to station [ 7a:11:dc:4c:2d:e6 ] is stable
Fri May 31 21:22:32 2024 daemon.debug mesh11sd[1440]: checkinterval 10 seconds
Fri May 31 21:22:43 2024 daemon.debug mesh11sd[1440]: interface mesh0 is up
Fri May 31 21:22:43 2024 daemon.debug mesh11sd[1440]: node [DEST,ADDR]
Fri May 31 21:22:43 2024 daemon.debug mesh11sd[1440]: node [7a:11:dc:49:8c:3e,7a:11:dc:4c:2d:e6]
Fri May 31 21:22:43 2024 daemon.debug mesh11sd[1440]: node [7a:11:dc:4c:2d:e6,7a:11:dc:4c:2d:e6]
Fri May 31 21:22:43 2024 daemon.info mesh11sd[1440]: Path to station [ 7a:11:dc:49:8c:3e ] is stable
Fri May 31 21:22:43 2024 daemon.info mesh11sd[1440]: Path to station [ 7a:11:dc:4c:2d:e6 ] is stable
Fri May 31 21:22:43 2024 daemon.debug mesh11sd[1440]: checkinterval 10 seconds
Fri May 31 21:22:54 2024 daemon.debug mesh11sd[1440]: interface mesh0 is up

I hope this setup now really solves this issue now, would be great! :slight_smile:

What i just noticed today during homeoffice was that my notebook several times switched to the weaker node in 2nd floor, after a while back to r7800 3rd floor.
Also currently no wifi devices connected to the mesh node 1st floor, even if there are two devices next to it. one is a xiaomi hub, 40centimeter distance, then 5 meter distance a wifi relay switch.

Is there also a way to optimize this?