In the context of IEEE 802.11 (aka Wi-Fi) "802.11d" doesn't mean "daemon", it means "additional regulatory domains".
"802.11sd" doesn't mean "daemon" either. It's just a standard designation the IEEE hasn't used yet (but it is going to do, they already arrived at "802.11be").
The only person to have mentioned this is you. So you make something up, post it, then complain about it?
The package this thread is concerned with is "mesh11sd".
The name was chosen because it is a daemon that manages 802.11s mesh networks.
If you want to permanently, or dynamically, set mesh 802.11s parameters that cannot be set in the wireless config, then you have two options:
Or alternatively, you can just install it and let it "plug and play".
99.99% of the time it just works if you let it do its thing after installing with the defaults.
Sure, advanced/seasoned users can then add their own stuff outside of anything this package does, and if that stuff breaks something, then having had it working first they will know immediately where to look for the problem/clash.
Ethernet will always be better!
That wasn't me:
This moniker describes a future IEEE standard.
Indeed. And I just asked a question why the OpenWrt documentation about configuring 802.11s interfaces tells this certain package (mesh11sd) "should be installed".
Why "should it be installed"?
It doesn't. It manages OpenWrt boxes running custom firmware. The IEEE standard body defines what a 802.11s mesh network is and it has nothing with what mesh11sd does. A 802.11s network is layer 2 virtual switch operating over wireless. Nothing less, nothing more.
There is nothing "plug and play" about that package. It's just not behaving in a way expected from an OpenWrt package.
If I had just received a clear, plain language explanation to my very first question that started this thread I would have avoided a lot of problems. Quoting verbatim the documentation which didn't really explain what I needed to know threw me way, way off course and I was down the rabbit hole of "Nothing is working. What the heck do I do now." I am still unsure of the answer.
Can you or anyone reading the thread today for the first time clearly explain in plain, not technical language understandable to an ordinary user who has never set up a mesh what that user is supposed to put in the default fields listed below:
uci set mesh11sd.setup.auto_mesh_id='MyUniqueMeshID123'
uci set mesh11sd.setup.mesh_gate_base_ssid='MyHomeNetwork'
uci set mesh11sd.setup.mesh_gate_encryption='1'
uci set mesh11sd.setup.mesh_gate_key='MySecurePassword123'
Don't quote the part of the documentation that "explains" the option because it's ambiguous and unclear what the user is supposed to fill in there and why or what it's used for later when the mesh11sd package completely takes over the entire setup of your router's settings and functions. Maybe tell me how to quickly find the new router IP mesh11sd assigns. I couldn't connect to the router wirelessly or wired when I first tried and was very confused by what happened.
Is "MyHomeNetwork" going to become the SSID that my computer connects to via wifi? and "MySecurePassword123" the password for that wifi connection? Or are those the SSID and password used by the mesh system being setup automagically?
What is "MyUniqueMeshID123" supposed to be? I used "karla-mesh" -- is that okay to put there? What are some good examples of what you might put in that setting and minimum/maximum length or restrictions of what characters to use, etc.
Maybe the GD thing would have worked for me? Probably not though because the Raspberry Pi I used on the first try doesn't have compatible mesh hardware. When/if such a thing happens, how can the user find out because you don't have wired or wireless access when such a failure occurs.
Rant over.
I stand corrected, poor @LilRedDog made a typo, we must slate him mercilessly for doing such a terrible thing.
I answered that already. FYI "should" is not the same as "must".
On what basis do you make that statment?
Yes it does, but it says nothing about how the underlying HWMP mac routing protocol should be set up and dynamically managed as required.
Indeed, the 802.11s standard provides nothing that automates the underlying protocol that it defines.
That is a very simplistic way of thinking about it. More accurate it is like an array of virtual layer 2 switches with multiple point to multiple point connections with a variable number of hops from point to point.
There is no requirement for a custom firmware. You can create a preconfigured firmware to simplify the rollout of mesh nodes, making the creation of a multi node backhaul a very simple task.
Flash your router with the default image from downloads.openwrt.org
Make no changes to the standard configs, leaving wireless disabled etc.
Install mesh11sd.
Run the command mesh11sd auto_config enable; reboot
and it will "plug and play`, automatically becoming either a portal mesh node or a peer mesh node depending on how you connect it.
Is that not "plug and play"?
Sure there are options you can choose.
If you want the mesh encrypted, install wpad-mbedtls.
If you want a guest network or want a vlan trunk over the backhaul, install ip-full and vxlan.
If you want cabled segments of backhaul install kmod-nft-bridge.
There are many more options to choose from, all defined in the basic uci config file.
You don't need the first boot script now?
Apologies, but I thought that was what I did.
MyUniqueMeshID123 Replace this with a string of characters to be used as the seed value that the system will use to generate. This will be "Your Unique Mesh Identifier" and must be the same on every mesh node you want to join the backhaul.
MyHomeNetwork Replace this with the name you want to use for your home network (to use for the SSID hence the name "mesh_gate_base_ssid").
mesh_gate_encryption='1' As listed in the documentation, encryption type "1" is "wpa3". You can choose 0, 1, 2 or 3 (see below)
Is this ambiguous?
# Set to 0 (none/owe-transition), 1 (sae, aka wpa3), 2 (sae-mixed, aka wpa2/wpa3), 3 (psk2, aka wpa2)
# or 4 (Opportunistic Wireless Encryption - owe)
Set your computer to get an address via dhcp. Look at the address your computer gets eg 192.168.123.200
Then the router ipv4 address will be 192.168.123.1.
On a Rpi, probably not, but using an Rpi as a router is well known to be problematic due to the limited nature of its network hardware.
Only if you are using the Rapid Deployment Firmware Flash method (the method that is the simplest and quickest).
From the "ambiguous" documentation:
Deployment Methods
There are two deployment methods:
The Rapid Deployment firmware flash method is the quickest and most efficient way to get a mesh network up and running.
This is the preferred deployment method.The Node by Node installation method can also be used, but is significantly less efficient. It takes much more time and a greater in depth knowledge of OpenWrt to deploy and uses more flash space on the nodes. In addition, there is greater scope for error. There will however be little or no performance penalty if using this method.
It's ambiguous.
This is ambiguous:
"Man helps dog bite victim"
How are instructions directing you to choose 1 of 2 options ambiguous?
Or are you saying you understand now (that only option 1 requires the script)?
(To be fair to the OP, the portion you quoted doesn't say Option 1 needs/uses a script. I'm unsure how a reader would assume that.)
????
I did not!
You don't need "mesh11sd" at all to run a 802.11s mesh network with OpenWrt. Just ignore everything the OpenWrt Wiki and some Github project says about that and just do this:
Use the OpenWrt Firmware Selector, customize installed packages and replace wpad-basic-mbedtls with wpad-mesh-mbedtls. The latter is necessary because the default OpenWrt firmware images are missing mesh support. Do not add mesh11sd!
Then configure a 802.11s interface on each OpenWrt AP using LuCI, through Network/Wireless/Add:
Channel: 36
Mode: 802.11s.
Mesh Id: [something unique shared between all nodes]
Network: lan
Encryption: WPA3-SAE
Key: [unique key shared between all nodes]
Continue to set up the "Master" SSID through LuCI as usual to connect your stations (clients).
Well a reader would actually "read on" to the following instructions, which include screenshots of the Firmware Selector page showing the uci-defaults text box.
The only reference to a "firstboot script" is on that page.
No?
But this says this:
Mesh11sd is a tool for OpenWrt users looking to create and manage wireless mesh networks using the 802.11s standard. (1)
It helps automate the process, which can be complex, especially for those new to networking or for the more experienced wanting to rapidly deploy larger networks.
My bad, you're right.
Finally.
Where is the Luci option for setting:
mesh_reactive_path_stabilisation_threshold
mesh_mac_forced_forwarding
mesh_hwmp_rootmode
mesh_hwmp_rann_interval
and lots of others that are needed for a multi node backhaul to function correctly?
I must have missed them somewhere.....
Nobody. Ever. Said. That. I run 802.11s here, too, without mesh11sd. For better or worst.
Edit: yeeeees with encryption 
This.
I would argue too that some instructions and manuals should be read cover to cover at first. Maybe we "should" add such a statement to the instructions?
Pardon me. Was your post sarcasm and I missed it; or what does lead you to the conclusion that the docs state that the user needs to install mesh11sd?