Well, I am sorry to hear your experience was a "rabbit hole".
The purpose of mesh11sd is to autonomously manage a multi node mesh.
The problem most people have is that they do not read the documentation and instead treat the package as you would a traditional one, ie go into Luci and select a few options.
If you do this, that is assume you have to configure traditional uci options one way or another, you will indeed end up in a bottomless rabbit hole as you fight the autonomous system.
Configuring manually is just fine if you only have two nodes.
It will, most likely, just work.
If you add a third, if you are lucky and have positioned all three exactly right, it will still work - unless something changes. Even something apparently trivial like leaving a door open.
Add a fourth, unless you are EXTREMELY lucky, very likely you will be in a game of now-you-see-me, now-you-don't. This is because Luci (and therefore uci) is designed to statically configure networks before they are brought up. This is not enough.
In an 802.11s mesh backhaul, the node has to join the mesh then turn on the HWMP mac routing that is built into the Linux kernel, then dynamically adjust its parameters depending on the availability or otherwise of peer nodes.
This is a dynamic process. Luci can only configure static processes.
Mesh11sd is a service daemon to dynamically manage the mesh backhaul.
If you were to open Luci and try to look at the mesh configuration, you will either see no trace of the mesh, or only see some very basic defaults. Then if you try to change anything, you fall down your rabbit hole, in the worst case soft bricking the device. For this reason Luci is disabled when mesh11sd is active (there are modes for expert users where Luci is re-enabled - but that is not for this thread).
A mesh node in "gate" mode, functions like a "dumb ap" but with a mesh backhaul link instead of an ethernet connection.
Why would you want to run Luci on a node like this?
Well the answer would be to gather statistics like the number of users, how much traffic are they generating etc.
The mesh11sd daemon runs another built in daemon, apmond, the access point monitor daemon.
A centralised database is generated to hold all the information about access point utilisation. This is usually on the "portal" node aka your router.
Simple commands give you a json formatted list of ap data.
Here is an example:
root@meshnode-8ecb:~# mesh11sd show_ap_data all
{
"OpenWrt-2g-256e@owe1-1@94:83:c4:5c:25:6e":{
"da:4b:ad:8c:f9:8c":{
"rx_bytes":"8901795",
"tx_bytes":"205175063",
"tx_retries":"33",
"signal_avg":"-63_dBm",
"tx_bitrate":"72.2_MBit/s_MCS_7_short_GI",
"rx_bitrate":"65.0_MBit/s_MCS_7",
"avg_ack_signal":"-60_dBm",
"connected_time":"3549_seconds",
"timestamp":"1750400350981_ms",
"date_time":"Fri_Jun_20_06:19:10_GMT_2025"
}
},
"OpenWrt-2g-2a52@owe1-1@94:83:c4:5c:2a:52":{
"a6:b4:09:cf:bd:71":{
"rx_bytes":"4199614",
"tx_bytes":"52459562",
"tx_retries":"3289",
"signal_avg":"-66_dBm",
"tx_bitrate":"72.2_MBit/s_MCS_7_short_GI",
"rx_bitrate":"52.0_MBit/s_MCS_5",
"avg_ack_signal":"-64_dBm",
"connected_time":"15308_seconds",
"timestamp":"1750415827324_ms",
"date_time":"Fri_Jun_20_10:37:07_GMT_2025"
}
},
"OpenWrt-5g-8ecb@owe1-1@94:83:c4:a2:8e:cb":{
"b4:8c:9d:ea:26:21":{
"rx_bytes":"294702",
"tx_bytes":"18278144",
"tx_retries":"266",
"signal_avg":"-49_[-55,_-57,_-53,_-54]_dBm",
"tx_bitrate":"390.0_MBit/s_VHT-MCS_9_80MHz_VHT-NSS_1",
"rx_bitrate":"433.3_MBit/s_VHT-MCS_9_80MHz_short_GI_VHT-NSS_1",
"avg_ack_signal":"-42_dBm",
"connected_time":"13472_seconds",
"timestamp":"1750415885205_ms",
"date_time":"Fri_Jun_20_10:38:05_GMT_2025"
}
}
}
root@meshnode-8ecb:~#
For anyone interested, see the mesh11sd documentation.
