No. The "protocol" used by the mesh to dynamically autoconfigure its mac-routing needs to be turned on. This, by default, cannot be done from the /etc/config/wireless file. It can be done manually once the mesh interface is "up", but will turn off again if the interface goes down or the router is rebooted.
The mesh11sd daemon checks/sets/resets the mesh parameters required for the mac-routing to work correctly, always running in the background.
802.11s uses a MESH topology. It is neither Tree nor Star but can sometimes look like both.
The hostname(s) of other meshnodes is/are determined by doing a reverse DNS lookup using the ip address of the remote meshnode. To get the remote meshnode ip, the ip address has to be looked up from the arp table.
OpenWrt uses Dnsmasq dhcp to populate the local .lan domain.
However, in your case, you have static ip addresses, so the reverse lookup will fail.
Alright, that is a better description than the previous one by far.
So since mesh11sd is running in the background, just want to confirm there is no configuration to be done, right?
Yes. I am not familiar with pfSense, but you should be able to specify static leases for the meshnodes so they always get the same ip address.
Not necessarily. pfSense should be able to populate local DNS in the same way as OpenWrt can.
Alternatively, adding the meshnodes to the pfSense hosts file might work.
Unless you want a second level of nat routing, all of the meshnodes should be configured in exactly the same way (given that they are all the same hardware) and will be completely interchangeable. ie There is no such thing as "Main" and "Node" "routers".
One of them will have an ethernet connection to the pfSense so it can provide an Internet feed to the mesh network. None of the meshnodes will be doing any ip routing, and none will be running dhcp or dns. They should all be dhcp clients unless you want the complexity of manually maintaining ip address allocations.
I think you mean "Dumb APs". This is a very unfortunate "dumbed-down" description that is very misleading. The proper technical term is a "Wireless Access Point" (WAP).
A WAP is anything but dumb. It is true that it does not do any ip routing, but it does do many other non-trivial things. A typical WAP provides a wireless SSID for client stations to connect to. It will also provide an upstream connection, usually an Internet feed.
WAPs work entirely at network layer 2, passing packets backwards and forwards. Layer 3 ip is only needed for management purposes.
The upstream feed is typically an ethernet connection to an ISP router (or an intermediate firewall - in your case pfSense).
Here you have that upstream connection being provided by the mesh network link for remote meshnodes and by ethernet on the meshnode closest to the pfSense box.
A good way to visualise a mesh network is to consider it as a virtual unmanaged ethernet switch where each meshnode is a port of that virtual switch.
That is correct. Mesh11sd autonomously adds required parameters. For advanced applications, additional parameters can be added to the config but are not required here.
You can check that mesh11sd is working by showing ip link when it is running and I will point out the differences.
Also show the output of mesh11sd status, and I will explain the output.
That's the whole point of a mesh-- automatic link setup. When any number of nodes are joined to the same mesh, they all have a path to each other. The mesh executive will determine whether packets can be sent directly or need to relay through one or more intermediates.
If A and C are in radio range of each other, it should send directly, otherwise it will relay through B. This is automatic and invisible to the upper layers of the network.
From ip link, this shows you now have an interface named mesh0 - this is an indication that mesh11sd is working.
The mesh11sd status is showing the current parameters, particularly mesh_fwding, mesh_gate_announcements, mesh_hwmp_rootmode and mesh_rssi_threshold have been set correctly.
It is a little odd that active_peers is showing "4". This should indicate that there are 4 meshnodes in the network, but don't you only have 3? Perhaps it is counting incorrectly...
I switched on the power of all my 3 AX X5000R routers this morning, and run the command: mesh11sd status again in SSH, now it is reporting the correct status: "active_peers":"3"
It might be a glitch in the router or something to report active peers = 4.
Well, , if your mesh devices have a usb port you could plug a GPS adaptor into each one and somehow read the geographic locations and superimpose them onto a Google Maps page....
It was probably a "ghost" node. Ghost nodes get into the mac-routing table if one or more meshnode does not have the correct parameters set. This can replicate to all other nodes and will persist for some time before timing out.
If mesh11sd is running on all nodes this should not happen.
If all the nodes are within close proximity it might be that it will still work, at least with any two nodes. It will most likely be a bit hit and miss, for example working for all 3 for a few hours, then one node will drop out and a reboot will be the only way to get it going again (consistent results from past research on various different hardware sets)
On each node do: service mesh11sd disable
followed by: service mesh11sd stop
When all are done, reboot them all and test.
To re-enable do: service mesh11sd enable
Followed by: service mesh11sd start or do a reboot
This is an issue with pfSense. Does it populate the local DNS domain with DHCP client host names?
You can find out by pinging a node by name. I very much suspect it does not, at least by default.
You could, as I suggested earlier, manually add the meshnodes into the pfSense hosts file.....
, if your mesh devices have a usb port you could plug a GPS adaptor into each one and somehow read the geographic locations and superimpose them onto a Google Maps page....
