FYI The next version of mesh11sd is in the final stages of pre-release testing.
Follow at:
1 Like
What tool is this?
Short update.
For the last 5 days my mesh is running stable. A record so far.
I have:
- moved all routers to OpenWrt 23.05.3
- on the 2 routers not connected to the LAN; in the wifi setting set the RSSI connect threshold to-70db; this prevents these 2 routers to connect to each other.
- manually set on the Lan and Internet connected
mesh_hwmp_rootmodeset to 4.. I didn't change the parameter on the other 2. I somehow forgot...
I will keep monitoring my setup and have an alarm warn me when the mesh goes down...
After a next reboot of the LAN connected modem I also will test without setting the root mode.
Maybe for me just ensuring the 2 pure wifi routers dont connect is enough to solve the issue.
The mesh11sd cli:
https://openwrt.org/docs/guide-user/network/wifi/mesh/mesh11sd#command_line_interface
1 Like
Short update: today there was an electricity cut. I didn't set the rootmode. And surely about 6 hours after the reboot the wifi became unstable.
Due to some 'important' work, a quick reboot was needed. I had to reboot the LAN connected router and another router to get all working correctly again.
Edit: the issue came during heavy loads due to large print jobs.
this comment in documentation:
However if the mesh network interface is defined in the wireless configuration, this will be used. If it is not defined, Mesh11sd will add the required options dynamically.
Does it refer to a possible GUI defined wireless network in mode '802.11s' -which translate in wifi-iface of mode 'mesh'? And "if what is not defined', mesh11sd will add the requirement options itself?
How I read this and how it can fit my purpose: If you define a wireless network with mode 802.11s and install the daemon, the daemen will set the needed parameters one cannot set via the GUI or on the interface itself.
And based on your feedback, installing the daemon is mandatory for a stable mesh.
Reading the github documentation at https://github.com/openNDS/mesh11sd it seems to take the scenario of a main router acting also as a portal/gateway node with additional peers. I'm finding it hard to translate this to a main wired router where the mesh consist of one portal connected via a wired lan to the main router/gateway and additional wifi backhauled satellites in a mesh config, what commercial mesh networks call 'bridged mode'.
Normally i would set up the mesh network via the wireless config and it works. Do i need this step ? or do i just connect the portal node via a wired lan to my main network/gateway then position the mesh peers and enable autoconfig on the mesh11sd daemon and all nodes and it automagically configures the 802.11s network ?
I need more info as setting up a mesh network in openwrt without mesh11sd seems easier than with mesh11sd; what am i missing ?
This comment in github also confused me:
Autoconfig Essentials
Note: Use the same configuration for all nodes, including the base ipv4 address.
so all nodes should have the same IP address ??? this doesn't make sense to me.
If you have a wired backbone for your AP you do not need 802.11s (and mesh11sd).
wired is only on the one peer, the portal as mesh11sd calls it, the others are wifi backhaul that talk back to the portal. This is typical for a mesh network. Without mesh how will the other peers (the one not wired into the router) talk to anything ?
What's what you call a portal?
With 802.11s as the underlay mesh you can use/build a layer 2 or a layer 3 network...
I'm not quiet sure I understand your question 
First of all, DO NOT use any version less than 4.0.1 as there are numerous problems caused by the previous versions defaulting to auto_config mode along with numerous problems associated with differing hardware.
The new release v4.0.1 is now merged into 23.5 as well as snapshots and is at the time of writing being built by the OpenWrt build bots. It will be available from the OpenWrt feeds, if not already then within a few hours with luck.
The default mode with auto_config disabled is intended for people with complex systems or an already configured mesh.
Without mesh11sd, the mesh will work fairly reliably with 2 nodes, but when there are more than 2, you WILL have problems unless you are very lucky as the 802.11s HWMP mac-routing system will be disabled. A common symptom is one or more nodes loosing connection at random intervals due to non-functioning HWMP.
In "manual mode", mesh11sd will use the pre-existing mesh config in /etc/config/wireless and then manage the essential mesh parameters that cannot be set in the wireless config.
The optional "auto_config" enabled mode is designed to enable a rapid rollout of a mesh backhaul with little or no configuration required.
With auto_config enabled, you would not have ANY pre-configured mesh, in fact the ideal is to have the "routers" to be used as mesh nodes all with a fresh reflash of OpenWrt with the default of wireless disabled.
As you have read, All mesh nodes will have exactly the same configuration yes, right down to the same base ip address.
In the simplest setup, just one of the nodes will have a connection from its WAN port to a LAN port of the ISP router. This node will detect the upstream connection and configure itself as a Mesh Portal ie a layer 3 ip router running dhcp and dns services for downstream devices.
Any node without such a WAN connection will configure itself as a Mesh Peer, obtaining an ip address via dhcp from the Portal node via the mesh backhaul, overriding the "configured" ip address. So it does make sense 
With mesh11sd, HWMP is dynamically adjusted to eliminate multi hop path changes caused by overlapping node coverage and you can configure Leech nodes for cases where a mesh to ethernet link is required within the coverage of peer nodes. A Leech node connects to the mesh backhaul, but does not contribute to it.
Once the build-bots have finished, I will produce a wiki article showing how the roll out a mesh network using the Firmware Selector to make a "Meshnode Image".
Please feel free to ask questions here, or open an issue on Github at:
2 Likes
Hi bluewavenet, thanks for your usual excellent explanation and the mesh11sd script plus github page.
I have downloaded mesh11sd_4.0.1_all.ipk from your github and I will be using latest 23.05.3 openwrt from firmware selector and customization as needed, including kmod-ntf-bridge.
so, if i understand it properly, and after reading your gitub README, the mesh network will end up with only one IP and if i need to connect to any of the other peers i need to use what you show on your github, e.g. 'mesh11sd connect 94-83-c4-08-14-83', obviously with the right MAC.
My scenario is 1 main wired router (gateway) with all wifi on it disabled.
3 APs, lets call them AP1, AP2 and AP3, all these configured initially as dumb APs.
All dhcp/dns services come from the main wired router.
All APs only have lan interface and bridged to the wifi, i.e. no WAN because I don't want double NAT.
AP1 connects via it's lan with an ethernet cable to one of the lan ports on the router; standard dumb AP scenario.
AP2 and AP3 use wifi backhaul (in mesh mode) to connect back to AP1 so it can upstream to the router and the internet.
The section below, from your github, cannot apply in my scenario since i have no wan for the reasons given above.
"Before proceeding to set these essentials, you must first connect each node in turn to an upstream Internet connection, connecting its "wan" port to a "lan" port of your isp router."
I'm going to assume in my scenario connecting each APs, via it's lan to the router will achieve the same result.
Before starting issue '/etc/init.d/mesh11sd stop'
If i understood everything correctly I will configure the 3 APs exactly the same; as per your github instructions:
- Set country code on all APs the same.
- set same mesh ID seed on all APs.
- Gateway SSID; will this be Gateway IP (ie. main wired router) because it cannot be AP1 SSID since this has to be same as the other AP SSID and is wired connected to the main router via its lan.
- Set same encryption (WPA3 is the only one allowed in openwrt) and all 3 APs.
- Set same access code all 3 APs.
- uci set mesh11sd.setup.auto_config='1' so it auto configures.
- uci commit mesh11sd on each APs everytime 1-6 complete on each AP.
- change /etc/config/mesh11sd 'auto_mesh_band' by uncommenting #option auto_mesh_band '5g' because I want the mesh to use 5GHz/ax for the wifi backhaul.
Start by connecting AP1 via its lan port to the main wired routed/gateway.
Power on AP1.
Position AP2 and AP3 where needed and power on.
Mesh should now be configured with AP1 as the portal (and gateway for AP2 and AP3).
AP2 and AP3 will come up as mesh_gates.
Does this make sense ? Have I missed, or misunderstood something ?
Your github seems intended for the portal also being the main router providing DHCP services my scenario is different hence my confusion.
Once again thanks for all your invaluable help.
Yes you have sort of missed a few bits making a simple job seem quite complicated 
So first of all:
-
It looks like you do not want to have a portal node, ie no mesh node connected upstream via its WAN. A Portal Mesh Node has an upstream link to a different ip subnet. You want the mesh backhaul to be connected to your one and only LAN, ie the isp router's LAN. This is fine, just don't connect any of the mesh node's wan ports to anything if using auto_config (we can revisit this later if you really want to remap the wan port for use as a lan port). If you have OpenWrt on the isp router, then
mesh11sd connectshould work, otherwise you will have to enable dhcp6 and ra services on it. -
"Upstream" means routing to another ip subnet, closer to the Internet.
-
The mesh backhaul will inherit the ipv4 subnet from the "portal" or in your case, the isp router's dhcp. Every mesh node will have a dhcp ipv4 address as well as an ipv6 address. (mesh11sd connect uses ipv6).
-
DO NOT configure your APs as Dumb APs. Mesh11sd with auto_config "auto configs" for you!!
-
" All mesh nodes will have exactly the same configuration "
-
I repeat, AP1, AP2, AP3, all configured the same (even if they are different hardware).
-
Connect any one of them by ethernet LAN to LAN. Call this one AP1 if you like (or better Mesh Gate 1).
-
Do not connect anything to the other two apart from the power connector. Put them in the target location.
-
It might sound counter intuitive, but 2.4 GHz mesh often/usually gives better coverage/performance particularly at HE40 bandwidth on AX (the default). Up to you of course and it does depend on numerous factors....
-
Your point 3 does not make sense to me. Be aware that the SSID is broadcast on its own virtual wireless interface independent of the mesh which operates on its own "mesh" virtual interface. They might both be on the same physical hardware but are otherwise independent.
-
On OpenWrt you can have all sorts of combinations of encryption types on an AP.
-
A meshnode will use sae/aes encryption to communicate on the backhaul. This was developed specifically for 802.11s mesh and was later modified and adopted for use on access points, where it is known as "wpa3". This is probably where the confusion originates.
-
I could go on, but it would be better to do this via the Firmware Selector as soon as the build-bots have finished for your hardware - What is your hardware? The bots might be done!
2 Likes
thanks again, so firstly i think we have a show stopper since I disable all ipv6, I do not need it for anything. The wan interface, on the mesh gates is already remapped to lan which is then bridged to the wifi.
point 4. i do this because there is no wan so no need for services like firewall, dhcp, dns to be running since all that is catered for by the main router. Are you saying to leave all these at default, ie. running ? It will probably work but seems making the AP do unnecessary work.
point 5. so an easier way, assuming all APs are same vendor/model and same openwrt version is just do one, save config and then load that config to the other APs.
point9, point taken and I've tested this. In my environment wifi6 backhaul works best because since i have dual band APs the 2.4GHz band is reserved for IOT stuff everything else connects to the 5GHZ.
point10. this is the same as when configuring 802.11s via luci though right ? you have the mesh SSID and then the SSIDs for the other channels, which can be different for 2.4 and5GHz or the same; from my research no definite answer which is the best.
point 12. understood, I've seen your explanation on this before in other forum submissions.
Hardware:
main router: Linksys WRT3200acm with openwrt 23.05.3
Managed switch (need this because i have vlans) Netgear716T/Netgear 108T
APs: Linksys velops (WHW01) with openwrt 23.05.3
Also run zabbix, chrony, loganalyzer, print server on rip4 connected to lan.
Goal: mesh network with 3xAPs, AP1 wired lan connected to main router, AP2 and AP3 connect via wifi backhaul mesh.
I have looked through default /etc/config/mesh11sd, as on your github and I think i got the sections i need to change to make this easier when mesh11sd is started. There is nowhere i can see on this forum to attach files and I don't want to repeat the entire config file since it's quite long.
thanks again..
You do now. Well only if you want mesh11sd connect to work.
You are completely misunderstanding the term "auto config".
Mesh11sd TURNS UNNEEDED SERVICES OFF. It auto-configures!!!
No - you are totally overthinking it. Just reflash them all with the same customised image.
Mesh does not have an SSID. It uses a MeshID that MUST be the same for every mesh node to connect to the backhaul. User devices should not see the MeshID (some old devices might see it in error) and normal user devices cannot connect to a mesh backhaul.
You are completely overthinking this, based on many misconceptions about how an 802.11s mesh works.
Don't complain when you break it.
You do know that vlans don't work over wireless without some form of tunnelling protocol?
I'm getting there. I'm going to go away and leave you in peace while i consume all the above.
I did not realise that your auto_config is that 'intelligent' to actually disable normally running services that are no longer needed; that's great.
AP1 is on vlan50 of the managed switch/router so that lan is eth0.50 and bridged to the wifi, the other AP/gates are bridged lan to wifi.
I assure you this config works fine I have had it working like this for over a year.
FYI, i have had mesh running fine using the stand luci config as shown here:https://openwrt.org/docs/guide-user/network/wifi/mesh/80211s, i.e. using /etc/config/wireless but the mesh nodes were losing connectivity occassionally so that's when i thought mesh11sd will help.
thanks again for all your patience.
Ah, so you are not trying to trunk vans over wireless... So basically your vlans are not involved in the mesh at all. You can trunk over mesh, but need that tunnelling protocol eg vxlan tunnel for layer 2 over ipv6... oh! ip6 again 
i know i said i'm going but had to reply.
I have used GRE tunneling already using only ipv4. I did this to try out a guest network that completely isolates from the other wifi whilst not having to use vlans over the wifi. This created a point-to-point tunnel and then i just added guest interface to use that tunnel. it worked fine.
1 Like
Apologies for butting in, I've been watching this thread. I'm running a 2-node mesh without mesh11sd and presumably getting by because I haven't tried adding a third node.
But, I am "trunking" 2 VLANs over that mesh. The mesh interfaces have no layer 3 ("unmanaged" in OpenWrt terms), and only one of the two tagged 802.1q derivative interfaces has its own layer 3 configuration:
23: mesh: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether nn:nn:nn:nn:nn:nn brd ff:ff:ff:ff:ff:ff
inet6 fe80::40c:43ff:fe26:6058/64 scope link
valid_lft forever preferred_lft forever
24: mesh.2@mesh: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
link/ether nn:nn:nn:nn:nn:nn brd ff:ff:ff:ff:ff:ff
25: mesh.5@mesh: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
link/ether nn:nn:nn:nn:nn:nn brd ff:ff:ff:ff:ff:ff
inet 192.168.5.1/24 brd 192.168.5.255 scope global mesh.5
valid_lft forever preferred_lft forever
inet6 fe80::.../64 scope link
valid_lft forever preferred_lft forever
(yeah, the base interface gets that autoconfigured inet6 address - I don't know why)
VLAN 2 is part of the usual br-lan bridge, so that the other node in the mesh (not the one above) can be reached/managed from br-lan. That node has DHCP client layer 3 config on its .2 VLAN interface off the mesh.
VLAN 5 is used as part of a "jail" segment for wired IoT devices that don't need to talk to the internet (enforced with firewall rules). It's bridged to the other node's LAN switch ports where the devices live. That other node has no layer 3 for its .5 jail mesh VLAN interface.
The node whose ip l output I quoted above runs the DHCP server for the jail, and also the DHCP server for br-lan.
If this subthread seems to be long-winded happy to take this to a new thread.