I just setup my WSM20 on OpenWRT, default everything.
What's puzzling me is I am able to select 802.11s and create a mesh network. It came with wpad-basic-mbedtls. The wiki states that wpad-basic-mbedtls should be removed and replaced before mesh functionality can be achieved. I take it the wiki is just vastly out of date so can anyone give some info as to how wpad-basic-mbedtls works or is this some super weird bug?
Thanks
If you want your mesh traffic to be open and unencrypted over the air, then you can create a mesh network without upgrading to a mesh or full version of wpad. This is of course very insecure and anyone within range could connect their own meshnode(s) without any restrictions and have full unfettered access to your local lan.
Not good..... But your choice.
To make a mesh work reliably you have to set numerous driver parameters that cannot be set within the wireless config and the mesh11sd package is provided for this purpose.
Because of the security issues of not encrypting your mesh network, mesh11sd will refuse to start if it does not find a suitable version of wpad and report the fact in the system log.
I hope this clarifies things for you... 
So I need more than being able to select WPA3-SAE?
I know maybe this is not the absolute perfect way to do mesh (I'll look into mesh11sd) but I'd just like to know why it works on the basic package. I'm still confused about that. I can understand wpad-basic-mbedtls having WPA-3 security since after looking around it came bundled in 21.02.0 by default: https://openwrt.org/releases/21.02/notes-21.02.0#wpa3_support_included_by_default
But I still don't know why 802.11s is selectable.
So what other meshnodes are in your "working" mesh network?
Luci allows you to create a mesh interface and it even allows you to select encryption.
BUT without a mesh compatible version of wpad, it will fail to connect to any other meshnodes.
Without going into any technical details I will give some background:
Long before wpa3 existed, encryption in 802.11s was developed and evolved over some time and eventually became standardised using the sae/aes method.
It was only some time later, this form of encryption was taken and modified into what we today see as wpa-sae for access points, but the implementation in an access point is very different to the implementation in a mesh network.
As most people do not set up 802.11s mesh interfaces but most people want to use wpa3 on their access points, a decision was made to include wpa3 in the basic version of wpad, saving on installed size for the majority.
I suppose you could say this is a bug in Luci, in that it does not check for mesh support in wpad.... Also the use of the term wpa3-sae as used for an access point, if I am pedantic, is incorrect when referring to a mesh. Sure it is the same thing "under the hood", but in implementation is quite different.
Personally, I think perhaps a simple warning in Luci is all that is needed.
ie "Make sure you upgrade wpad" or something similar.
"BUT without a mesh compatible version of wpad, it will fail to connect to any other meshnodes."
If you check this video at around 24:14 you will see that all 3 devices can ping each other and connect. This is also on wpad-basic-mbedtls
Shall I report this as a bug? Maybe it has security implications?
I can't see that mentioned anywhere in the video.... He will have installed a mesh compatible wpad version.
I can assure you this is not a bug (I tested here just now to confirm).
In addition, the configuration in this video will result in regular intermittent dropouts as the "luci" configuration cannot activate mesh parameters that are required for the mesh backhaul to establish its mac-routing protocol.
As far as it goes, the video only shows tinkering using Luci, and as such is very misleading as it will not result in a reliable mesh backhaul.
Some relevant documentation:
From own experience, most functionality stripped from wpad in wpad-basic will fail silently if invoked.
Indeed, my experience too.
He did the setup from initially flashing and shows all steps so they would have been on basic. I even asked them and they also confirmed it was the basic mbedtls also. But yes I think this is a case of it allowing you to do the mesh but not actually being properly done. 802.11s should not really be selectable imo but obviously if you followed the guide it does say to change it so no harm done.
Just to confirm I should follow either 802.11s wiki or Mesh11sd? Not both?
This video seems pretty popular and does appear to go through the same steps as the wiki: https://www.youtube.com/watch?v=cw8ykKgVKbM
I will see if I can look into supplementary videos for Mesh11sd. I did see some people saying 802.11s on OpenWRT is not relibale and most just do WDS so I'll see how I get on.
If you bothered to read them, you would find that the first refers you to the second.
Indeed, following your first video, it would be unreliable.
Your second video link is also very outdated - over 3 years old and predates mesh11sd. He "got away" with it as he only had 2 nodes communicating and was lucky. It was notable that he did not comment on the reliability.
I still don't get why standard 802.11s implementation would not be reliable. Are you telling me when the IEEE came up with this protocol that they just didn't actually test it or something? Like why does it even exist know what I mean? It may aswell be scrapped if you have to do these band aid fixes.
Who said the standard 802.11s implementation is unreliable?
No one with any technical knowledge on the subject anyway.
If you had bothered to read the mesh11sd user guide you will have seen the following:
The settings in the uci wireless config are acted upon at boot time or when the wireless network is restarted and are implemented before the mesh interface has reached an active state.
Unfortunately, many mesh configuration parameters can only be set after the mesh interface becomes active.
So instead, 802.11s mesh parameters are included in the mesh11sd daemon's config file. The daemon manages the mesh parameters in a dynamic way that the static wireless configuration cannot do.
Technically, you can of course manually configure all the 802.11s parameters yourself, using the iw utility, but manual config will not survive a wireless restart or a reboot.
No, the problem is that you still have not read the documentation.
Instead you have chosen to watch some outdated and misleading YouTube videos.
If in your opinion it does not work properly then this can only mean that the IEEE did not test it and it has never worked. Why does it even exist? It may as well be scrapped.... /s
The
ForceDunning-Kruger Effect is strong with this one