BUG: Mesh with wpa-supplicant-mesh-openssl fails

Hi,
today I could work again on the mesh setup I wanted to test. So I set up two OpenWRT APs with the follow wireless config:

config wifi-iface 'mesh0'
        option device 'radio0'
        option mode 'mesh'
        option mesh_id 'mesh0'
        option mesh_fwding '1'
        option encryption 'psk2+ccmp'
        option key 'mYsUPerSeCUREm3SH'
        option network 'lan'
        option ifname 'mesh0'

config wifi-iface 'mesh1'
        option device 'radio1'
        option mode 'mesh'
        option mesh_id 'mesh1'
        option mesh_fwding '1'
        option encryption 'psk2+ccmp'
        option key 'mYsUPerSeCUREm3SH'
        option network 'lan'
        option ifname 'mesh1'

The LAN interface has on both (AP1 and AP2) Bridges Spanning Tree enabled, so that I dont get a Loop when both meshes (2,4 and 5 GHz) are getting up.

Installed is on both OpenWRT 18.06.4 the following wifi packages:

root@AP1:~# opkg list-installed | grep -e wpa -e hostap -e wpad
hostapd - 2018-05-21-62566bc2-6
hostapd-common - 2018-05-21-62566bc2-6
hostapd-utils - 2018-05-21-62566bc2-6
wpa-cli - 2018-05-21-62566bc2-6
wpa-supplicant-mesh-openssl - 2018-05-21-62566bc2-6

The mesh1 (2,4GHz) was up, but could not communicate. Then I found this on the logread:

Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Successfully initialized wpa_supplicant
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Line 6: invalid key_mgmt 'SAE'
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Line 6: no key_mgmt values configured.
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Line 6: failed to parse key_mgmt 'SAE'.
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Line 7: too large mode (value=5 max_value=4)
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Line 7: failed to parse mode '5'.
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Line 8: unknown network field 'mesh_fwding'.
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Line 16: failed to parse network block.
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Failed to read or parse configuration '/var/run/wpa_supplicant-mesh1.conf'.
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): cat: can't open '/var/run/wpa_supplicant-mesh1.pid': No such file or directory
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): WARNING (wireless_add_process): executable path /usr/sbin/wpa_supplicant does not match process  path ()
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Command failed: Invalid argument
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): Interface 1 setup failed: WPA_SUPPLICANT_FAILED
Sun Aug 11 12:15:38 2019 daemon.notice netifd: radio1 (29740): command failed: Link has been severed (-67)
Sun Aug 11 12:15:38 2019 user.notice mac80211: Failed command: iw dev mesh1 set mesh_param mesh_fwding 1

after I removed mesh_fwding from the /var/run/wpa_supplicant-mesh1.conf and saved, the mesh was up and I could ping the opposite mesh partner.

Why are those options be placed there,when they should not be there? Or I am missing something more?

I also don't understand, why mac80211 reports that he can't sed the mesh_param:

root@AP1:~# iw dev mesh1 set mesh_param mesh_fwding 1 && echo OK
OK

I found the point, where mesh_fwding is placed into wpa_supplicant.conf.
In /lib/netifd/hostapd.sh on function wpa_supplicant_add_network()
in block [[ "$_w_mode" = "mesh" ]] && { I commented the line

[ -n "$mesh_fwding" ] && append network_data "mesh_fwding=${mesh_fwding}" "$N$T"

But after commenting out the line and executeing wifi, the kernel crashed with SWBA overrun on vdev 0, skipped old beacon:

https://pastebin.com/3phjFUP6

EDIT:
After a reboot, the whole thing is running. What I dont understand, that AP1 need the change, but AP2 runs also fine without...

Both APs have ath10k devices:
AP1 = TP-Link Archer C7 v2
AP2 = D-Link DAP-2695 A2

Assuming the wireless driver supports 802.11s, it runs fine with wpad-mesh (without any changes to the package-installed files, just configuration).

If that fails, your drivers may not properly support 802.11s. Ah, I see it added there -- I know that the chipset in the Archer C7v2 requires the "non-CT" ath10k drivers and firmware to run encrypted 802.11s.

1 Like