802.11s based wireless mesh network configuration (better documentation)

Installing and Using OpenWrt Network and Wireless Configuration
1

I have a couple of these babies:

Working fine under OpenWRT. Would like to pair them up in a mesh, at each end of the house. Needless to say there is a LOT to learn here, but I found a lovely doc here:

which is good but not great and I wonder if we can work together to make it great? OK as a technical writer by background, by great I will admit I mean the currently biased level of content and quality that leaves a modestly competent reader informed and confident and able to install a mesh.

But reading it have some questions. If I can get answers form the community here, I am happy to update that page (if and when I were to get a wiki account - self registration being disabled currently).

Questions arising as I walk through it:

  1. The first step recommends replacing wpad-basic with wpad-mesh-openssl instead. All good and well, but I think it's worth some quick notes (here, and there) as what these packages are, and what the consequences and reasons are.Here's what my modest reading around the OpenWRT Wiki suggests (but I find it incomnmplete and a little guess-worky on my part):
    • wpad I will guess is from WPA (Wifi Protected Access) and D for Daemon? So a daemon that supplies wifi authentication features
    • it seems to come in -mini, -basic, and -mesh-openssl variants at least, with mini providing basic PSK (Pre-Shared-Key) features, -basic adding fast transitioning and extra security features, and -maesh-openssl adds mesh support.
    • It's not clear to me what the difference between fast transitions ( 802.11s) and mesh (802.11r) is, but I'm going to guess under s twp APs have distinct SSIDs and under r they offer the same SSID (the transition now being invisible to an end user). But as I said I'm guessing and learning a bit and fishing for feedback, correction and more learning.
    • It seems the replacement of a -basic package with a -mesh then presents essentially no compromise in features, simply adds features supporting meshs.
    • What remains unclear is after removing one package and installing the other, what happens. Byy which I mean does this just replace the package on disk, and it remains to be done to restart the services or reboot the router to gain advantage of the new package? Or does installing the package stop and start the required services to gain immediate utility from the installed package?
  2. We are now asked to add anew interface to /etc/config/wireless
    • Immediately I'm confronted with existing configs. I see a par for radio0 and a pair for radio1, each with a device and an interface (with default_ prepended) eclared. Where and how are these mapped to the more familiar wlan0 and wlan1 that I see in Luci under Wireless configuration, and what is the difference between radio0 and wlan0?
    • We are asked then to add a new interface and give it a mesh-id. it's not clear what that is and how it's used but I note it for now.
    • There is a clue about bridging an ap interface and the mesh interface, but there is no further mention of bridging or who and when that happens which leaves me befuddled.
    • We see an option to get capabilities with iw dev <devname> get mesh_param with no mention what a is, so I try radio0 and no luck but wlan0 works (and in fact the next lines confirm that). But above we saw that radio0 was declared as a wireless device. So again we're left wondering what wlan0 is and how is is bound to radio0.
    • It then asks us to run three commands wifi then logread -l 20 -f and finally iw dev wlan0 station dump without explaining what this does or linking to anything. That's where any sensible reader bails to do more reading alas.
      • The wifi command turns out to be a script in /sbin, no ready documentation easily found, some discussion here: https://unix.stackexchange.com/questions/62045/how-to-apply-new-wireless-settings-on-an-openwrt-router-without-rebooting-it but examining the script with no argument it performs up. No clarification here why uping it useful, when down and reload commands are there. As ever learning rather than blindly following.
      • Turns out wifi status is useful and is the first time I've see a tie between radio0 and wlan0! Though deeply ironic, because in this output wlan0 is listed under ... iface, not a device, but an interface - and we used it above as a device. Oh well, inconsistent terms are possible (if not useful).
      • Turns out that is just a running ubus call network.wireless status
      • Oddly uci show wireless knows nothing about wlan0 and grep -r wlan0 /etc reveals little (some LED configs but nothing that also mentions radio0)
      • The logread command is simple enough. Though on standard OpenWRT seems there's no disk file just a ringbuffer in memory. But either way, a command looking for the results of the wifi command.
      • The iw command has better documentation and station dump shows stats for each station connected (which is nice). But again it uses wlan0 and I have not yet found how wlan0 is tied to radio0
  3. We're then asked to create a mesh interface with iw phy phy0 interface add mesh0 type mp mesh_id mymesh
    • But no comment as to what mymesh is. I can guess (but the job of better documentation and I would love to improve it if I can is to remove guesswork) is that mymesh is the same name specified under option mesh_id in the mesh interface we added to /etc/config/wireless.
    • But there is nothing said about what's happening here. what is a phy
    • My guess again is that this is configuing the AP (Access Point) as a mesh point (mp) in the mesh with mesh_id as specified (which was the mesh_id we put into both devices in the /etc/config/wireless. But where is this config stored? How is it persisted?
  4. Interestingly it now asks us to check with ifconfig -a
    • Voila, ifconfig knows about wlan0 but not radio0.
    • For all my fishing I still can't find what ties wlan0 to radio0 though.

At this point I put it on hold until I learn a little more. I really want to understand how wlan0 and radio0 are connected in configs, how and where iw configurations are persisted and what role /etc/config/wireless has in relation of iw and ifconfig.

It would be nicer still if mesh networks could be easily configured in Luci, and hey if it is and I missed that, let me know too!

1 Like
2

wow thats a lot of basic questions many don't have to do with meshing per se at all.

First off since commercial "mesh" systems also promote some sort of fast transition, there is the perception that mesh is fast transition. It is not. In OpenWrt mesh mode is strictly a wireless backhaul scheme. It doesn't have anything to do with the operation of APs.

The radio names are used only inside /etc/config/wireless to tell the UCI system which radio hardware you want each AP or mesh etc. to run on. Once a wlan interface is set up, it's association to a radio is fixed. iw dev will show all of your radios and associated interfaces. Here realize that 'radioX' is merely a friendly name (indeed you could edit /etc/config/wireless and rename your radios anything you want, as long as its consistent). iw knows the radios as phy0 etc.

The wlanX names are automatically generated and may not be consistent as APs etc are added or deleted to the configuration. So attach each wireless interface to a network within /etc/config/wireless, where you don't have to know the name.

OpenWrt's UCI system parses the unified config files and calls low-level utilities like iw and ip (ifconfig is obsolete) so that you don't have to. You can call iw's show commands to investigate the system but there is not a need to manually or script call to iw in "action" mode to configure anything.

3

Hey thanks for the feedback. Yep, I'm might curious how it all hangs together and would love to contribute to making it clearer for all.

I don't quite understand everything you've shared. Like "a wireless backhaul scheme"

What I guess I was hoping (with only naive current knowledge levels in the area - albeit on the backdrop fair comms experience historically) that "mesh" was the term for providing a single visible SSID to clients (and authentication) and the meshpoints handover silently (much like the GSM network but for wifi) without the client caring much which meshpoint they are currently connected to.

Is that close?

re: iw dev I'm still puzzled as it reports the wlan0 and wlan1 interfaces under phy#0 and phy#1 respectively. I'm not sure what extra level of abstraction the phyX names add alas. Moreover I see no way of tying either phyX to a radioX.

"The wlanX names are automatically generated" - by what, when, and so on ...

If iw knows radioX as phyX then what ties them. One candidate is option path 'platform/10300000.wmac' which is on the radio0 config for example. I can't find any doc one that is. But iw dev reports bow a wdev 0x3 in this case an addr which looks like a MAC.

Given the radio0 device has no MAC I might suspect that the path is what binds these. And voila I am one step closer to understanding. It looks like platform/10300000.wmac refers to a kernel exposed filesystem /sys/devices/platform/10300000.wmac in which is a directory net under which is a directory, wait for it ... wlan0.

# ls /sys/devices/platform/10300000.wmac/net
wlan0

I say one step closer as I think this but a clue. That is is probably just a kernel exposed volatile filesystem (that is, not a persistent fileystem, much like /proc) and the name wlan0 is divineable there in the path for radio0 (that is we can now see the tie) but it remains a mystery whence the name wlan0 comes where this name is persisted (or is it created on boot, and if so by what rules?) and where if anywhere is option path well documented?

Now I'm wondering what ties the mesh to the lan ... In the page cited the recommended config includes:

option network 'mesh'

Under the mesh interface definition. While the access points use:

option network 'lan'

In Luci I see a network interface called "lan" I don't see one called "mesh" and is not the idea of an ap and a mesh similarly to permit access to lan? The doc stats little:

network: Specifies the network interface to attach the wireless to.

4

Just picking on words here, I've actually not seen any consumer/ prosumer mesh systems using IEEE 802.11r so far (other than more enterprise oriented ones) - probably most of all because IEEE 802.11r support in clients (including smartphones and tablets) is pretty bad (and even more problematic with WPA3). Yes, they usually do band-steering and maybe some internal handoff between satellites, but usually via hard de-auth.

5

Great topic Bernd. Usually that kind of questions do not get much attention, unfortunately, if someone responds, answers are usually half baked. I wonder why they call it documentation, I suggest they should call it fragmentation. Mesh documentation is a good example: It only helps people that already know how to implement a mesh network, everybody else is probably not very happy.
Unfortunately I can not contribute, but I like to present one very well written tutorial from Carlos Gomes, maybe you don't know it. Carlos Gomes

1 Like