Mesh11sd initial configuration problem

[Laugh-each-day]

I'm trying to create a generic setup procedure for a mesh at home. When successfully running, there should be a Mesh Master attached to the ONT and 2 mesh satellites. Unfortunately, I get a red LED and no mesh. I hope someone here can help iron out the problems.

Hardware for initial testing
Asus RT-AC58U v1 (two of these)

Further Hardware for intended mesh network
Gee/HiWiFi HC5962
Ubiquiti UniFi AP Pro (old and not reliable)

Software
All running OpenWRT 24
PC uses Linux

Sources

GitHub - openNDS/mesh11sd: Mesh11sd is a dynamic management and parameter...

Mesh11sd & 802.11s Issue

Hoping someone can help here - I have test devices (UI Rocket M5) that will be forming a mesh network. I have followed all the info on both these pages: [OpenWrt Wiki] 802.11s Based Wireless Mesh Networking [OpenWrt Wiki] The Mesh11sd Project The commands used to setup the mesh and interfaces and a diagram for context are below. The issue is that I seem to have the nodes connected as they appear when running iw dev m-11s-0 station dump command but I cannot ping/ access devices on the other si…

Current Setup Procedure for Confidence Test (containing the problem(s))

1. Install OpenWRT onto router and connect PC by cable to LAN port
2. Logon and create a password e.g. Luci or SSH
3. Determine the node’s IPv6 address (for access as once the mesh starts then IPv4 isn’t possible)
4. Create local DHCP for LAN ports e.g. 192.168.2.1 (to prevent conflicts with WAN connected)
5. Connect WAN port using cable to LAN port of main router (currently an old, “dumb” ISP router)
6. Check the node has access to the internet e.g. Luci-System-Software-Update Lists
7. Open SSH terminal to node
8. Run the following commands:

# 1) Update and install packages (pick openssl OR wolfssl)
opkg update
opkg remove wpad-basic-mbedtls wpad-basic-openssl wpad-basic-wolfssl wpad-mini wpad-mbedtls wpad-openssl wpad-wolfssl
opkg install wpad-mesh-openssl
opkg install uhttpd px5g-mbedtls luci-ssl
opkg install ip-full kmod-nft-bridge vxlan mesh11sd

# 2) Stop mesh11sd and bring radios down
service mesh11sd stop || true
wifi down || true

# 3) Configure radio1 (5 GHz) for mesh backhaul
uci set wireless.radio1.disabled='0'
uci set wireless.radio1.country='00'
uci set wireless.radio1.channel='0'
uci set wireless.radio1.htmode='HE80'    # change to 'VHT80' if unsupported
uci set wireless.radio1.txpower='20'
uci commit wireless
wifi up

# 4) Configure mesh11sd for Confidence Test
uci set mesh11sd.setup.auto_mesh_id='test-mesh_nomap'
uci set mesh11sd.setup.mesh_gate_base_ssid='test-Access_nomap'
uci set mesh11sd.setup.mesh_gate_encryption='1'
uci set mesh11sd.setup.mesh_gate_key='Test-Key_23'
uci set mesh11sd.setup.auto_mesh_band='5g'
uci set mesh11sd.setup.portal_use_default_ipv4='1'
uci set mesh11sd.setup.auto_config='0'    # Confidence Test mode (='0')
uci commit mesh11sd
uci commit network || true

# 5) Run Confidence Test and follow logs
mesh11sd debuglevel 3
mesh11sd commit_changes commit
mesh11sd auto_config test
mesh11sd read_log -f

9. Once the Confidence Test is (successfully) running then open a second SSH terminal (using the IPv6 address as IPv4 won’t now work) and check on the status of the mesh. The following commands can prove helpful

mesh11sd status
mesh11sd show_config
mesh11sd peers
logread -f   # system logs
iw dev wlan1 station dump  # replace wlan1 with the actual mesh iface

# For exact iface names to use, run in the second terminal:
uci show wireless
ip link show
iw dev

Unfortunately, in my case the LED glows red and the Confidence Test doesn’t start. Can anyone suggest how to isolate the problem and a fix, please?

[bluewavenet]

@Laugh-each-day

I hope someone here can help iron out the problems.

Yes indeed.

But an important question must be answered first - which of the following do you want?

1. You want to create a mesh backhaul network to which you "connect" access points
2. You want your client devices to be able to roam transparently from one access point to another.

Note that these two are very often, depending on hardware, mutually exclusive.

If your answer is point 1 above:
First problem is "All running OpenWRT 24".
The version of Mesh11sd there is quite old and as OpenWrt 24.10 is now in the pre-eol phase of its life, no version updates of packages will happen, other than for security issues.

I would suggest that before going any further, you reflash to the latest stable, 25.12.2 at the time of writing. But we can discuss your requirement in more detail first.

[Laugh-each-day]

Thank you, BlueWaveNet.

Desired Goals
The primary goal is your "2" i.e. for client devices to be able to roam transparently from one access point to another. They should have access to all network resources i.e. internet, printers, and remote webcams too, hopefully.

A second goal is to have a self-tuning and self-healing network. One satellite moves position around the house at irregular intervals. Also these routers were bought second-hand ("pre-loved") with OpenWRT installed but are no longer young. (Especially the Ubiquiti, which has worked well for 2 years but now often freezes under load on hot days.)

Latest OpenWRT version
According to OpenWRT's Table of Hardware at https://toh.openwrt.org/?view=normal the latest versions are:

1. Asus RT-AC58U v1 - C.Release is 24.10.4 (24.10.4 installed)
2. Gee/HiWiFi HC5962 - C.Release is 24.10.5 (24.10.2 installed)
3. Ubiquiti UniFi AP Pro - C.Release is 25.12.0 (no access at present to check)

It looks like I already have (almost) the latest stable version for these routers. Hopefully there will be a ver.25 for them some time, but who knows? (The Ubiquiti seems to be on its last legs so isn't likely to become a permanent mesh node.)

[egc]

The ToH is updated manually and is lagging behind.
You really should check if there is a stable release for your router e.g. in:

Index of /releases/25.12.2/targets/

[bluewavenet]

@Laugh-each-day

The primary goal is your "2" i.e. for client devices to be able to roam transparently from one access point to another.

This is NOT a mesh. It seems you have been mislead by the marketing from some manufacturers who use the term "mesh" when they mean "roaming".

The Mesh11sd package allows for the setup of a wireless backhaul network that dynamically manages a multipoint-to-multipoint mesh of nodes which can be used amongst other things to distribute access points around a venue/property/etc..
Edit: Yes, an access point can be software running on a mesh-node (the most common case) - as well as a separate device.

Normal user devices (phones, tablets, laptops, desktops) CANNOT connect to a mesh-node, instead they will connect to access points sitting on the mesh backhaul.

Mesh11sd is NOT applicable and has no part in enabling roaming of user devices.

I would strongly suggest you close this thread, then search on this forum for "roaming" and do a little background reading.

Then, if you need to, open a new thread entitled something like "How do I enable roaming between my access points?".

[Laugh-each-day]

Thank you, egc. I found the Asus RT-AC58U at https://downloads.openwrt.org/releases/25.12.2/targets/ipq40xx/generic/, so there is an OpenWRT 25.12.2 available. Next I just have to get organised for a re-flash to update. Very pleasing.

[Laugh-each-day]

Hi BlueWaveNet.

Agreed. Multiple authors emphasis that a desire for roaming alone doesn’t necessitate a (true) mesh system. I have had roaming between 2, sometimes 3, routers and AP’s for years, and most recently including 802.11r and -k. But that was in a single story, square shaped, wooden house similar to a California Bungalow.

We have recently moved to a new house of almost 200m2 (a bit over 2,000 sq.ft.). It is oblong, has 2 stories, concrete block walls, and a separate, granny flat-like dwelling in the garden. Also, I won’t be able to use cables for more than a single link away from the router/ONT. I probably could cover this with the devices listed above by adapting my previous configuration with time and fiddling about. However, my initial attempts resulted in a much slower system than previously, and it had too many dead areas. Also, my previous system never seemed to achieve fully stable, reliable connections to all devices e.g. printers, and system changes or additions usually resulted in troubleshooting of some issue.

So, while it is easiest to describe our use as roaming around the property from AP to AP, the mesh is intended to connect these AP’s without cables and in a reliable, self-tuning, and self-healing manner. The AP’s get moved from location to location every month or two, and the equipment is not the youngest nor most reliable any more. This is what the mesh should provide while enabling access through the attached AP’s. I thought that a true mesh would best support this.

(Thanks to egc I have found OpenWRT 25. It was not listed on https://toh.openwrt.org/?view=normal.)

[bluewavenet]

@Laugh-each-day

the mesh is intended to connect these AP’s without cables and in a reliable, self-tuning, and self-healing manner.

Ok then, so you really do need a mesh!
It is always worth emphasising that "mesh" is 100% NOT "roaming".

@Laugh-each-day

802.11r and -k.

On a shared wireless interface, "802.11r and -k" are incompatible with "802.11s (aka mesh)".
Roaming, in the 802.11 -k -r sense, to work correctly, needs each AP to be on a different radio channel.
An 802.11s mesh, requires every meshnode to be on the same channel.

Normal user devices cannot connect directly to an 802.11s mesh backhaul, instead they need to connect to an access point (AP) which is in turn connected to the mesh backhaul - either as a separate ethernet connected AP, or "built in" to the meshnode (eg a shared VIF or a second physical radio).

Your initial attempts to configure Mesh11sd were very wrong, not necessarily your fault, but partially for following other people's failed attempts and partly my fault for not writing some simple "Getting Started" documentation.
Also, what you were trying to follow was most likely very old and outdated.

I would suggest you read the current Mesh11sd documentation, then come back with, not just questions, but a more detailed outline of what you want to achieve - including a block diagram if you can.

Mesh11sd Documentation

[Laugh-each-day]

Thanks again, egc, for pointing me to the latest firmware. I’ve now upgraded the Asus RT-AC58U and Gee/HiWiFi HC5962 both from OpenWRT 24.10.4 (or /.2) to OpenWRT 25.12.2 with Luci-System-Backup/Flash-Flash_new_firmware_image.

[Laugh-each-day]

PS The site I found easiest to use to find firmware was https://firmware-selector.openwrt.org/. It seems to be giving up-to-date-firmware.

[Laugh-each-day]

Hi BlueWaveNet,

I’ve updated both routers to OpenWRT 25.12.2. The router I'm configuring first is:

Model:	Gee/HiWiFi HC5962
Architecture:	MediaTek MT7621 ver:1 eco:3
Target Platform:	ramips/mt7621
Firmware Version:	OpenWrt 25.12.2 r32802-f505120278
Kernel Version:	6.12.74

Going back to commands based solely on your post, I now have the following commands to get the mesh11sd daemon started in a "safe" state (aka "manual mode"). (The change from OpenWRT 24 to OpenWRT 25 included a change from opkg to apk package management.)

Step 1) Check latest firmware is installed:
https://firmware-selector.openwrt.org/
(not https://toh.openwrt.org/?view=normal, which is not up-to-date)

Step 2) Set admin password (if not yet set)

Step 3) Check no "ath10k-ct" drivers in use (replace with non-ct versions)
e.g. using Luci or SSH.

Step 4) Find IPv6 address (as IPv4 will later fail).
e.g. on a Linux PC use command "ip -6 route" for info
(refer [https://github.com/openNDS/mesh11sd?tab=readme-ov-file#getting-the-link-local-ipv6-address-of-the-portal-node](https://github.com/openNDS/mesh11sd?tab=readme-ov-file#getting-the-link-local-ipv6-address-of-the-portal-node))

e.g. ssh root@fe80::d6ee:7ff:fe59:65ae%enp2s0

Step 5)Configure and Start Mesh (in a "safe" state/"manual mode")
#  Open a 1st SSH terminal to router e.g. use IPv6 address
#  Update package list and remove/install these packages:

apk update
apk del wpad-basic-mbedtls
apk add wpad-mbedtls
service wpad restart
apk add ip-full kmod-nft-bridge vxlan luci-ssl luci-app-commands
apk add mesh11sd

At this point the LED glows red as it did before. However, I do have access via a 2nd SSH terminal using IPv6 (also using IPv4) - which is an improvement compared to before.

If I execute mesh11sd status in the 2nd terminal I get a list of variables including "procd_status":"not running", which is probably to be expected with a red LED.

If I reboot the router then it starts OK but the LED is still red (and access is still possible via terminal an Luci).

What should I do next?

[bluewavenet]

@Laugh-each-day

What should I do next?

Can I assume you have done nothing else other than installing the packages, exactly the same on the Asus and the HiWiFi, can you ssh by ethernet from your computer via the link-local ip address, each in turn?

If so. choose one of them to be the mesh portal.
Connect its wan port to the upstream router.
Connect your computer to a lan port.
SSH into it using its link-local ipv6 address.
Run the command:

mesh11sd auto_config test; exit

You will be disconected.

Now connect your computer to the other mesh-node using the ethernet cable to a lan port.
SSH into it using its link-local ipv6 address.

Run the command:

mesh11sd auto_config test; exit

Again, you should be disconnected.

Unplug the ethernet cable from your computer.

Scan wifi waiting for some new SSIDs to appear.
The SSIDs will look like "MeshGate-xxxxxx" and "VTunnel-xxxxxx"

After a little while you should see the led changing from constantly on to a heartbeat like flashing.

Try connecting to the SSIDs

Report back.
Note: Luci will be disabled at this stage. Instead, you will see a status page.

[Laugh-each-day]

@bluewavenet

Can I assume you have done nothing else other than installing the packages, exactly the same on the Asus and the HiWiFi,

Almost correct. Both routers were flashed then the only change was to set the static IP from 192.168.1.1 to 192.168.2.1 and 192.168.3.1 respectively. In the case of the Asus router I also had to replace the ath10k-ct drivers, which I did using:

apk del ath10k-firmware-qca4019-ct kmod-ath10k-ct-smallbuffers
apk add ath10k-firmware-qca4019 kmod-ath10k-smallbuffers
reboot

@bluewavenet

can you ssh by ethernet from your computer via the link-local ip address, each in turn?

Yes for both routers using the IPv6 addresses.

The WiHiFi router was connected to the router on the ONT. Running the command mesh11sd auto_config test; exit on both routers successively seemed to work correctly and I was disconnected from both as expected.

After several minutes "MeshGate-2g-xxxxxx", "MeshGate-5g-xxxxxx", "VTunnel-2g-xxxxxx" and "VTunnel-5g-xxxxxx" appeared.

However, the lights continued to glow solidly, red on the HiWiFi and blue on the Asus. Using SSH and entering mesh22sd status replied with "procd_status":"not running"," for the HiWiFi and "procd_status":"running" for the Asus.

I presume this suggests that the problem currently lies with the HiWiFi?

[bluewavenet]

@Laugh-each-day

kmod-ath10k-smallbuffers

No- do not use the smallbuffers version either. This is only for supporting numerous users connecting on AP interfaces when memory is restricted in the device and will most likely interfere with the autonomous mesh buffer management. This may or may not be the cause of your current problem. To be honest, I did not know there was a non-ct small-buffers version.

@Laugh-each-day

the only change was to set the static IP from 192.168.1.1 to 192.168.2.1 and 192.168.3.1 respectively.

No, put this back to default. The Mesh11sd auto config will sort it out.
With default Mesh11sd config the backhaul ipv4 subnet will be 192.168.111.0/24. We can make adjustments later.

@Laugh-each-day

lights continued to glow solidly

The lights will heartbeat flash when other meshnodes can be seen on the mesh backhaul.
It is also possible the led control is nonstandard, if it is we can usually add a config option to fix it - if necessary we can look into it later, BUT you don't have both nodes up and on the backhaul yet so maybe there is no problem with the lights.

@Laugh-each-day

I presume this suggests that the problem currently lies with the HiWiFi?

Yes, it looks probable.

Can you confirm you have the wan port on the HiWiFi connected to the ONT?

SSH into the HiWiFi.
Run the commands:

mesh11sd debuglevel 3
mesh11sd commit_changes commit
reboot;exit

EDIT: We are still in confidence test mode and that is reset by a reboot so we have to turn it on again.
Let it boot up again then SSH back in.
Run the commands:

mesh11sd auto_config test; exit

SSH back in and:

mesh11sd read_log

See if you can copy/paste the output here.
A new cycle starts every ~10 seconds or so.

On my operational dev system here, it looks like this:

root@meshnode-8ecb:~# mesh11sd read_log
Thu Apr 16 09:45:14 GMT 2026 daemon.debug mesh11sd[2821]: [1177184] This IS a layer 3 mesh portal
Thu Apr 16 09:45:14 GMT 2026 daemon.debug mesh11sd[2821]: [1177185] Station [ 96:83:c4:2f:f9:d1 ] is an immediate neighbour, but has had [ 52836 ] path_change(s) detected
Thu Apr 16 09:45:14 GMT 2026 daemon.info mesh11sd[2821]: [1177186] Path to [ 96:83:c4:2f:f9:d1 ], changed, [ 1 ] hop(s) via [ 96:83:c4:2f:f9:d1 ], HWMP Sequence Lifetime [ 611 ] ms
Thu Apr 16 09:45:14 GMT 2026 daemon.info mesh11sd[2821]: [1177187] Path to [ 96:83:c4:14:58:bd ], stable, [ 1 ] hop(s) via [ 96:83:c4:14:58:bd ], HWMP Sequence Lifetime [ 687 ] ms
Thu Apr 16 09:45:14 GMT 2026 daemon.debug mesh11sd[2821]: [1177188] Station [ 96:83:c4:2d:c5:24 ] is an immediate neighbour, but has had [ 48004 ] path_change(s) detected
Thu Apr 16 09:45:14 GMT 2026 daemon.info mesh11sd[2821]: [1177189] Path to [ 96:83:c4:2d:c5:24 ], changed, [ 1 ] hop(s) via [ 96:83:c4:2d:c5:24 ], HWMP Sequence Lifetime [ 478 ] ms
Thu Apr 16 09:45:14 GMT 2026 daemon.debug mesh11sd[2821]: [1177190] Station [ 96:83:c4:5e:25:6e ] is [ 2 ] hops away and [ 129694 ] path_change(s) for station have been detected
Thu Apr 16 09:45:14 GMT 2026 daemon.info mesh11sd[2821]: [1177191] Path to [ 96:83:c4:5e:25:6e ], changed, [ 2 ] hop(s) via [ 96:83:c4:14:58:bd ], HWMP Sequence Lifetime [ 458 ] ms
Thu Apr 16 09:45:15 GMT 2026 daemon.info mesh11sd[2821]: [1177192] apmond connecting to portal
Thu Apr 16 09:45:15 GMT 2026 daemon.debug mesh11sd[2821]: [1] apmond - Node id string: [ apmond;meshnode-8ecb;94:83:c4:a2:8e:cb;spider;0 ]
Thu Apr 16 09:45:15 GMT 2026 daemon.debug mesh11sd[2821]: [2] apmond - node type validated for [ meshnode-8ecb ]
Thu Apr 16 09:45:15 GMT 2026 daemon.debug mesh11sd[2821]: [1177193] apmond - send_ap_data - chunkstatus [ spider ], chunksize [ 0 ], return code [ 0 ]
Thu Apr 16 09:45:15 GMT 2026 daemon.debug mesh11sd[2821]: [1177194] Checking mesh_hwmp_rootmode
Thu Apr 16 09:45:15 GMT 2026 daemon.info mesh11sd[2821]: [1177195] Portal [ MRP@94:83:c4:a2:8e:cb ]
Thu Apr 16 09:45:15 GMT 2026 daemon.info mesh11sd[2821]: [1177196] Checkinterval [10]

If you do it quick enough after rebooting you might see startup errors. Lets see what you get.

[Laugh-each-day]

For some unknown reason the IPv6 access is gone:

$ ip -6 route
::1 dev lo proto kernel metric 256 pref medium
fe80::/64 dev enp1s0 proto kernel metric 1024 pref medium
~$

The IPv4 access is still possible since I hadn't got to reverting it back (yet) because of this. Can you suggestions why the IPv6 disappeared and how to get it back? Is this part of the mesh11sd discussion, or is it due to something else? (The only action of any note since IPv6 was available was a BIOS update for the mobo which created a new Ethernet Network Connection called "Wired Connection 2". I don't see why this should have an effect, though.)