I'm running a current snapshot built with image generator on a test network with tplink 2*wr703 and wr842v3 routers.
An unauthenticated mesh configures and runs well with no obvious issues.
Enabling authentication does not provide authenticated connectivity.
I have had this running in an earlier test system using wpad-mesh and authsae.
However with the latest snapshot on a 4mb device openssl doesn't fit.
I have seen that there was a version of wpad-mesh using wolfssl that is significantly smaller than previous versions of wpad-mesh and a subsequent build confirms this fits into a 4m wr703 device.
I have followed the latest info I could find in this thread https://forum.openwrt.org/t/setting-up-authenticated-mesh-with-wpad-mesh/12399/20
Running on OpenWrt SNAPSHOT r7569-4c1aa64b4d' (~30/7/18 build)
Q. Has anyone successfully created an authenticated 802.11s mesh with wolfssl?
Tip for detecting successful mesh connection.
run:
iw meshdev station dump
then check for a line near the rx/tx bitrate that has an expected throughput ie:
tx bitrate: 72.2 MBit/s MCS 7 short GI
rx bitrate: 6.0 MBit/s expected throughput: 33.507Mbps
If this line isn't present even though the mesh plink status indicates established and the mesh peer status all say active then the link will not pass data.
[edit] I have an AP also configured on the same radio device.
sae_password and key were bouncing back and forth for a while as to which worked properly with the "stock" wpad-mesh implementation. Perhaps a long shot, but try adding or replacing that option statement. (I have both enabled in my current config.)
I was checking the /tmp/run/wpa_supplicant-mesh0.conf file for changes when adding/removing the various key/password options and noticed the following:
wpa_supplicant only runs if the mesh has encryption enabled and the .conf file only gets updated if encryption is enabled.
option sae_password doesn't create a password entry in the .conf file, only the option key does.
Further testing suggests that 1*AP and 1 * mesh configuration per radio works intermittently for encrypted wolfssl 802.11s. It can take upto several minutes before the link is established or it may not establish. I'm wondering if there is some sort of 'race' or timeout occurring.
2 * AP and 1 * mesh doesn't work for encrypted links but does for unencrypted links. Also the unencrypted links establish in a few seconds.
I can't test this with wpad-mesh-openssl as the image is to big for my routers. So I don;t know if the issue I am seeing is restricted to wolfssl or not.
There were some problems on at least the Archer C7 on master early this year with 802.11s and AP running simultaneously on the same radio. They were resolved several months ago.
And just for entertainment
If the wireless is configured to only have a mesh interface it fails to start the wireless.
If you also have a station configured the wireless will start.
You might want to check your config. I'm able to get an encrypted mesh interface running as the only interface on the 5 GHz radio of several Archer C7s running master from April, 2018
I've cut and pasted the wireless and network config from a working device (same model).
I altered the i/p in the network config and disabled the ap config from the working device.
Config below.
If the AP is disabled the mesh fails to start
Wed Aug 1 22:54:34 2018 daemon.notice netifd: radio0 (3337): Successfully initialized wpa_supplicant
Wed Aug 1 22:54:34 2018 daemon.notice netifd: radio0 (3337): command failed: Link has been severed (-67)
(I'm guessing that the bold there is from Markdown interpreting the # character as styling. The </> button in the edit toolbar is a good way to show "code" as verbatim.)
My running config includes:
Looks just like my config, just a different device and i'm using 2.4G radio.
I have even tried cut and paste of your config to see if that would make any difference but it hasn't
Maybe something with the way the interface is being handled? From that message, it "feels like" the radio comes up, but netifd isn't able to properly associate it with an interface that it is managing. I ended up setting the mesh interface's IP address and MTU in a "hook" inside of the netifd script, so there may be something in how /etc/config/wireless and /etc/config/network interact with netifd.
Following that theme I tried removing the option network config line in /etc/config/wireless so there wasn't any network interface associated with the wireless interface. Same error message.
I ended up tracing the execution of the netifd scripts with set -x or set -vx to trace down how they worked and what the status of things were along the way. No other messages about mesh0 or the wireless interface?
I'll check out the set function and give that a go.
I'm pretty certain that the mesh interface won't come up on my devices if hostapd isn't running (ie AP configured as well as the mesh). The mesh interface only uses wpa_supplicant. As to whether that is due to a timing issues or something not being configured by wpa_supplicant only I'm not sure. I'll try tracing the scripts to see if I can find where the issue is occurring.
Just out of interest, on your dual band routers what qty Ap/mesh/SAT do you have on each radio and how many instances of wpa_supplicant/hostapd are running for each radio.
Interesting, I think there is more than one issue.
If an AP is enabled as well as the mesh, the HT and noscan parameters are added to the mesh.conf file that is passed to wpa_supplicant. I was using HT40 with noscan=1. With the mesh only enabled, the HT40 was passed to the mesh.conf but the noscan option wasn't passed.
If I enable the AP and disable the noscan option I get the same result as not having the AP enabled.
Changing the HT40 to HT20 allows the mesh to come up.
So it looks like when the mesh tries to come up (no AP) when it is configured to HT40 and there isn't a noscan=1 passed to the conf file the radio shuts down after detecting another AP.
