Setting up authenticated mesh with wpad-mesh

bmoffitt · 2018-03-08 19:26:41 UTC

Folks-

I'm trying to set up an authenticated (or even encrypted) mesh using 802.11s. I have done the authenticated mesh with AuthSAE in the past, but, since AuthSAE is deprecated, I wanted to use wpad-mesh instead.

Note: I am using Ubiquiti PicoStation/Bullet hardware.

I built LEDE 17.01.4 with wpad-mesh and hostapd-common. I set up two VAPs (one AP, one mesh) and tested. With no authentication or encryption (no wireless. mesh.key), it works fine. As soon as I add a wireless.mesh.key, the WiFi turns off and I get the following message (many, many times):

Wed Mar 7 21:53:36 2018 daemon.notice hostapd: handle_probe_req: send failed

/etc/config/network:

config interface loopback
    option ifname    lo
    option proto    static
    option ipaddr    127.0.0.1
    option netmask    255.0.0.0

config interface lan
    option ifname    'eth0'
    option type     bridge
    option proto    dhcp
    option ipaddr    172.24.47.47
    option netmask    255.255.255.0
    option hostname 'Test_unit'
    option ip6assign 60

config globals globals
        option ula_prefix auto

(I had previously had it configured with a static address)
/etc/config/wireless:

config wifi-device 'radio0'
    option type 'mac80211'
    option channel '6'
    option phy 'phy0'
    option path 'pci0000:00/0000:00:00.0'
    option hwmode '11g'
    option htmode 'HT20'
    option disabled '0'

config wifi-iface 'AP'
    option device 'radio0'
    option network 'lan'
    option mode 'ap'
    option ssid 'this_is_the_SSID'
    option encryption 'psk2+ccmp'
    option key 'this_is_the_key'

config wifi-iface 'mesh'
    option device 'radio0'
    option network 'lan'
    option mode 'mesh'
    option mesh_id 'xxxxxxxxxxx'
    option key 'yyyyyyyyy'
    option encryption 'psk2+ccmp'

I tried not using an "option encryption" line at all and using "option encryption none" - no difference. This points to a problem in authentication, not encryption, I think.

Ideas?

Thanks,

Bill

jeff · 2018-03-08 19:43:07 UTC

Working on Archer C7, 17.01 (git branch), wpad-mesh
Was also working on 17.01.4

config wifi-iface
	option device 'radio1'
	option mode 'mesh'
	option mesh_id '<redacted>'
	option mesh_fwding '1'
	option encryption 'psk2/aes'
	option key '<redacted>'
	option network 'mesh'

Not so sure on where I got psk2/aes and if that is cause or not.

Edit: just confirmed that psk2+aes as well as psk2+ccmp interoperate with psk2/aes. I have not confirmed that the frames are encrypted after making that change, though my guess is that they are.

drbrains · 2018-03-09 01:35:46 UTC

See discussion here: Starting with mesh networks

Latest post (56) by Jeff shows that encryption is working.

bmoffitt · 2018-03-14 19:12:55 UTC

I appreciate that - yes, the mesh seems to work OK and the access point seems to work OK, on their own. The problem comes in if I use mesh and AP ("MAP" in 802.11s parlance) on the same interface. That's where I'm seeing this problem.

jeff · 2018-03-14 19:33:28 UTC

I have yet to be able to make that work. At least on an Archer C7, on 5 GHz, when, using UCI, I add an AP to an existing mesh configuration on the same radio, the mesh stops. I have not yet tried it using iw directly.

bmoffitt · 2018-03-14 20:18:28 UTC

I finally got a few minutes to do some more testing today. I re-flashed my PicoStations with 17.01.4 (straight off the download site), removed wpad-mini and installed wpad-mesh. I was able to verify this behavior - mesh works fine on its own, but it stops working when I turn the AP on.

Bizarrely, the mesh fails even if I don't have encryption on the AP:

root@LEDE:~# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.channel='11'
wireless.radio0.hwmode='11g'
wireless.radio0.path='pci0000:00/0000:00:00.0'
wireless.radio0.htmode='HT20'
wireless.radio0.disabled='0'
wireless.AP=wifi-iface
wireless.AP.device='radio0'
wireless.AP.network='lan'
wireless.AP.mode='ap'
wireless.AP.ssid='this_is_the_SSID'
wireless.AP.key='this_is_the_key'
wireless.AP.encryption='none'
wireless.AP.disabled='0'
wireless.mesh=wifi-iface
wireless.mesh.device='radio0'
wireless.mesh.network='lan'
wireless.mesh.mode='mesh'
wireless.mesh.mesh_id='xxxxxxxxxxx'
wireless.mesh.key='yyyyyyyyy'
wireless.mesh.encryption='authsae'

Yeah, this looks like a bug, unless there is some configuration point I'm missing...

bmoffitt · 2018-03-14 20:22:24 UTC

Quick note: If I delete both the wireless.AP.key and wireless.AP.encryption entries, the mesh will work with the AP on. So it's just down to wpad.

jeff · 2018-03-14 20:30:35 UTC

Interesting result -- as if wpad-mesh can't handle AP and mesh encryption on the same interface.

Maybe I didn't need to order those old Ubiquiti WiFi Stations after all...

Edit:

root@office:~# iw phy0 interface add test0 type ap
You need to run a management daemon, e.g. hostapd,
see http://wireless.kernel.org/en/users/Documentation/hostapd
for more information on how to do that.
root@office:~# iw phy1 interface add test1 type ap
You need to run a management daemon, e.g. hostapd,
see http://wireless.kernel.org/en/users/Documentation/hostapd
for more information on how to do that.
root@office:~# ps w | fgrep hostapd
 3618 root      3752 S    /usr/sbin/hostapd -s -P /var/run/wifi-phy1.pid -B /var/run/hostapd-phy1.conf
root@office:~# ps w | fgrep wlan
 4211 root      3760 S    /usr/sbin/wpa_supplicant -B -b br-mesh -P /var/run/wpa_supplicant-wlan0.pid -D nl80211 -i wlan0 -c /var/r

grrr

Maybe hostapd (as compiled) can't handle both?
(On closer examination wpa_supplicant is running on wlan0 for the mesh network)

root@office:~# iw phy0 interface add test0 type mesh
root@office:~# ip link show dev test0
78: test0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 30:b5:c2:aa:43:30 brd ff:ff:ff:ff:ff:ff

Time passes...

http://lists.infradead.org/pipermail/hostap/2017-February/037184.html
[BUG] wpa_supplicant in SAE mode kills AP on same PHY

https://bugs.openwrt.org/index.php?do=details&task_id=550

See next post on newer versions of wpa_supplicant that appear to have different mesh support

Charlemagne Lasse commented on 28.02.2017 14:23
It can be fixed by removing following lines in wpa_supplicant.c

	if (iface->hostapd_ctrl) {
		char *cmd = "STOP_AP";
		char buf[256];
		int len = sizeof(buf);

		wpa_s->hostapd = wpa_ctrl_open(iface->hostapd_ctrl);
		if (!wpa_s->hostapd) {
			wpa_printf(MSG_ERROR, "\nFailed to connect to hostapd\n");
			return -1;
		}
		if (hostapd_stop(wpa_s) < 0)
			return -1;
	}

Reference links:
http://lists.infradead.org/pipermail/hostap/2017-February/037230.html

Edit:

Looks like it's "last one wins" as AP then mesh declared in /etc/config/wireless brings up mesh, and mesh then AP declared brings up AP.

jeff · 2018-03-14 22:42:05 UTC

Looks like the "right" resolution will be an update to the current version, based on looking at git://w1.fi/hostap.git

The "offending" section is now absent in wpa_supplicant.c and there is a CONFIG_MESH parameter controlling ifdefs.

Working on pulling this in on a local branch now.
Update: All the patches fail, so will have to figure out what is going on with them.

jeff · 2018-03-16 03:40:21 UTC

Had to move the development to lede-17.01, but having initial success with the "latest" wpa_supplicant code. Mesh came up and the other stations connected successfully. AP looks good too!

phy#0
	Interface wlan0-1
		ifindex 162
		wdev 0xc
		addr <redacted>
		ssid test-mesh-ap
		type AP
		channel 149 (5745 MHz), width: 80 MHz, center1: 5775 MHz
		txpower 30.00 dBm
	Interface wlan0
		ifindex 161
		wdev 0xb
		addr <redacted>
		type mesh point
		channel 149 (5745 MHz), width: 80 MHz, center1: 5775 MHz
		txpower 30.00 dBm

Thu Mar 15 20:46:27 2018 daemon.info hostapd: wlan0-1: STA <redacted> IEEE 802.11: authenticated
Thu Mar 15 20:46:27 2018 daemon.info hostapd: wlan0-1: STA <redacted> IEEE 802.11: associated (aid 1)
Thu Mar 15 20:46:27 2018 daemon.notice hostapd: wlan0-1: AP-STA-CONNECTED <redacted>
Thu Mar 15 20:46:27 2018 daemon.info hostapd: wlan0-1: STA <redacted> RADIUS: starting accounting session E1A5117BAEC56FE9
Thu Mar 15 20:46:27 2018 daemon.info hostapd: wlan0-1: STA <redacted> WPA: pairwise key handshake completed (RSN)

ghoffman · 2018-03-17 21:56:22 UTC

jeff -
could you please specify what your base install version is, and which versions of which wpad you are using to get AP and mesh both workin gon the same radio?
thank you!

jeff · 2018-03-17 22:33:21 UTC

I've been working with an Archer C7, the patches were originally applied to master but I found that it caused the router to "lock up". I then moved to "lede-17.01" and was able to bring up the two interfaces with my patches up update wpa_supplicant.

Apparently, there are already patches for mesh/AP on a single radio, and it now is sort-of working on builds off lede-17.01 I say "sort of" as when I add an AP into the mix, the logs get filled with endless repetitions of kernel WARNING of the form ... Great, now it's not doing it.

Ugh, needless to say, I'm still debugging this.

Edit: Let me get a couple more build trees up and configure them with all kmods, as I strip out ppp and the like from my builds. I'll get a web server up and public facing as well to support them. @ghoffman - are there any specific packages you need in an Image Builder?

root@test:~# cat /etc/openwrt_release 
DISTRIB_ID='LEDE'
DISTRIB_RELEASE='17.01-SNAPSHOT'
DISTRIB_REVISION='r2993+875-b9a408c'
DISTRIB_CODENAME='reboot'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='LEDE Reboot 17.01-SNAPSHOT r2993+875-b9a408c'
DISTRIB_TAINTS='no-all busybox'

root@test:~# opkg list-installed
ath10k-firmware-qca988x - 2017-01-11-ab432c60-1
base-files - 173.5-r2993+875-b9a408c
block-mount - 2018-01-04-37762ff4-1
busybox - 1.25.1-4
ca-bundle - 20170717
diffutils - 3.3-2
dropbear - 2017.75-4
findutils-find - 4.6.0-1
firewall - 2017-05-27-a4d98aea-1
fstools - 2018-01-04-37762ff4-1
fwtool - 1
git - 2.11.0-1
gre - 1-7
hostapd-common - 2018-03-13-c63e69c3-6
ip6tables - 1.4.21-3
iptables - 1.4.21-3
iw - 4.9-1
iwinfo - 2016-09-21-fd9e17be-1
jshn - 2018-01-07-1dafcd78-1
jsonfilter - 2016-07-02-dea067ad-1
kernel - 4.4.120-1-130ff56cb7e319063d074ae916a2ce17
kmod-ath - 4.4.120+2017-01-31-3
kmod-ath10k - 4.4.120+2017-01-31-3
kmod-ath9k - 4.4.120+2017-01-31-3
kmod-ath9k-common - 4.4.120+2017-01-31-3
kmod-cfg80211 - 4.4.120+2017-01-31-3
kmod-crypto-crc32c - 4.4.120-1
kmod-crypto-hash - 4.4.120-1
kmod-fs-ext4 - 4.4.120-1
kmod-gpio-button-hotplug - 4.4.120-2
kmod-gre - 4.4.120-1
kmod-gre6 - 4.4.120-1
kmod-ip6-tunnel - 4.4.120-1
kmod-ip6tables - 4.4.120-1
kmod-ipt-conntrack - 4.4.120-1
kmod-ipt-core - 4.4.120-1
kmod-ipt-nat - 4.4.120-1
kmod-iptunnel - 4.4.120-1
kmod-iptunnel6 - 4.4.120-1
kmod-lib-crc16 - 4.4.120-1
kmod-mac80211 - 4.4.120+2017-01-31-3
kmod-nf-conntrack - 4.4.120-1
kmod-nf-conntrack6 - 4.4.120-1
kmod-nf-ipt - 4.4.120-1
kmod-nf-ipt6 - 4.4.120-1
kmod-nf-nat - 4.4.120-1
kmod-nls-base - 4.4.120-1
kmod-usb-core - 4.4.120-1
kmod-usb-ledtrig-usbport - 4.4.120-1
kmod-usb2 - 4.4.120-1
lede-keyring - 2017-01-20-a50b7529-1
less - 481-1
libblobmsg-json - 2018-01-07-1dafcd78-1
libbz2 - 1.0.6-3
libc - 1.1.16-1
libcares - 1.11.0-1
libffi - 3.2.1-2
libgcc - 5.4.0-1
libip4tc - 1.4.21-3
libip6tc - 1.4.21-3
libiwinfo - 2016-09-21-fd9e17be-1
libiwinfo-lua - 2016-09-21-fd9e17be-1
libjson-c - 0.12.1-1
libjson-script - 2018-01-07-1dafcd78-1
liblua - 5.1.5-1
libmosquitto-ssl - 1.4.15-1
libncurses - 6.0-1
libnl-tiny - 0.1-5
libopenssl - 1.0.2n-1
libpcap - 1.8.1-1
libpthread - 1.1.16-1
librt - 1.1.16-1
libubox - 2018-01-07-1dafcd78-1
libubus - 2017-02-18-34c6e818-1
libubus-lua - 2017-02-18-34c6e818-1
libuci - 2018-01-01-141b64ef-1
libuci-lua - 2018-01-01-141b64ef-1
libuclient - 2017-11-02-4b87d831-1
libustream-openssl - 2016-07-02-ec80adaa-3
libuuid - 2.29.2-1
libxtables - 1.4.21-3
logd - 2017-03-10-16f7e161-1
lua - 5.1.5-1
luci - git-18.061.17832-d092772-1
luci-app-firewall - git-18.061.17832-d092772-1
luci-base - git-18.061.17832-d092772-1
luci-lib-ip - git-18.061.17832-d092772-1
luci-lib-jsonc - git-18.061.17832-d092772-1
luci-lib-nixio - git-18.061.17832-d092772-1
luci-mod-admin-full - git-18.061.17832-d092772-1
luci-proto-ipv6 - git-18.061.17832-d092772-1
luci-proto-ppp - git-18.061.17832-d092772-1
luci-ssl-openssl - git-18.061.17832-d092772-1
luci-theme-bootstrap - git-18.061.17832-d092772-1
mosquitto-client-ssl - 1.4.15-1
mtd - 21
nano - 2.7.5-1
netifd - 2017-01-25-650758b1-1
openssl-util - 1.0.2n-1
opkg - 2017-12-08-9f61f7ac-1
procd - 2018-01-22-9a4036fb-1
resolveip - 2
rpcd - 2017-12-07-cfe1e75c-1
swconfig - 11
tcpdump-mini - 4.9.2-1
terminfo - 6.0-1
uboot-envtools - 2015.10-1
ubox - 2017-03-10-16f7e161-1
ubus - 2017-02-18-34c6e818-1
ubusd - 2017-02-18-34c6e818-1
uci - 2018-01-01-141b64ef-1
uclient-fetch - 2017-11-02-4b87d831-1
uhttpd - 2017-11-04-a235636a-1
uhttpd-mod-ubus - 2017-11-04-a235636a-1
usign - 2015-07-04-ef641914-1
wpad-mesh - 2018-03-13-c63e69c3-6
zlib - 1.2.11-1

root@test:~# cat /etc/config/network 

config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdf9:2b1f:8aea::/48'

config interface 'mesh'
	option type 'bridge'
	option stp '1'
	option proto 'static'
	option ipaddr '172.16.1.100'
	option netmask '255.255.255.0'

config interface 'vlan100'
	option type 'bridge'
	option stp '1'
	option ifname 'eth0.100'
	option proto 'static'
	option ipaddr '192.168.1.100'
	option netmask '255.255.255.0'
	
	option gateway '192.168.1.1'
	option dns '192.168.1.1'

#
# Switch Config
#
[...]

root@test:~# cat /etc/config/wireless 

config wifi-device 'radio24'
	option type 'mac80211'
	option channel '6'
	option hwmode '11g'
	option path 'platform/qca955x_wmac'
	option htmode 'HT20'
	option require_mode 'g'
	option disabled '0'

config wifi-device 'radio5'
	option type 'mac80211'
	option channel '149'
	option hwmode '11a'
	option path 'pci0000:01/0000:01:00.0'
	option htmode 'VHT80'
	option require_mode 'ac'
	option disabled '0'

config wifi-iface 'mesh0'
	option device 'radio5'
	option mode 'mesh'
	option mesh_id '<mesh0_id>'
	option mesh_fwding '1'
	option encryption 'psk2+ccmp'
	option key '<mesh0_secret>'
	option network 'mesh'

config wifi-iface '5Gap'
	option device 'radio5'
	option mode 'ap'
	option ssid '<5Gap_ssid>'
	option encryption 'psk2+ccmp'
	option key '<5Gap_secret>'
	option network 'vlan100'

ghoffman · 2018-03-17 22:41:47 UTC

jeff - thanks. if i'm understadning the output, you have an OLD snapshot that you have downloaded and are working with packages from that snapshot?
or are your building your own from an old point on the git?
anyway - it does not work with any of the 17.0.x stable branches?

jeff · 2018-03-17 23:01:30 UTC

I can never decode the version string LEDE/OpenWRT uses, even after looking at scripts/getver.sh

Edit ./scripts/getver.sh <OpenWRT/LEDE version string> will return the commit.
See How to check source version 17.01 (rxxxx revision vs. git commit hash)

I've been building off the git branch "lede-17.01" and the git branch "master" with origin https://git.lede-project.org/source.git "lede-17.01" is a "stable" branch, not a development branch, as I understand it.

I don't see d91494e in 17.01.4 and that commit's November date means it likely happened after 17.01.4 was "cut".

jeff@ubuntu:~/Documents/devel/lede_source$ git log -1
commit 96288dc139129b8b70a8418ee3c97de93b0b5198 (HEAD -> master, origin/master, origin/HEAD)
Author: Matthias Schiffer <mschiffer@universe-factory.net>
Date:   Sat Mar 17 17:01:01 2018 +0100

    generic: revert broken LED core patch
    
    The patch breaks LED operation and has already been reverted in 4.4.121.
    4.9.87 is still affected; revert it locally until the issue is sorted out
    upstream.
    
    Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>

jeff@ubuntu:~/Documents/devel/lede_source$ git log -1 lede-17.01
commit 60f8d388c69e0faddbf1c3033cdcb74b38fe3694 (origin/lede-17.01, github/lede-17.01, lede-17.01)
Author: Felix Fietkau <nbd@nbd.name>
Date:   Sat Mar 10 10:09:07 2018 +0100

    kernel: merge a pending fix for HFSC warnings/slowdowns (fixes FS#1136)
    
    Signed-off-by: Felix Fietkau <nbd@nbd.name>

ghoffman · 2018-03-17 23:49:00 UTC

i'm testing tonight's snapsnot build. i can bring up both mesh and AP interfaces on the same radio.
luci has an option to set the mesh_id
but the luci option for mesh encryption is still not working.
i'll be testing, slowly.
EDIT - not stable. connects and immediately disconnects.

DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r6475-96288dc'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_ARCH='mips_24kc'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r6475-96288dc'
DISTRIB_TAINTS=''

jeff · 2018-03-17 23:55:00 UTC

Great! Saves me from wrestling with getting all the kmod packages built!

I'll be working through things here as well, as I'd like to get a 5 GHz AP up or put my backhaul down on 2.4, but it's got to be stable. With my setup on "master' builds it was running out of memory at boot, causing all kinds of problems.

Edit: last "good" commit on lede-17.01 appears to be (doesn't crash, AP shows, but not clear if actually "live")

commit 05f0fac189984981e3f28288e44d9afdd088dd77
Author: Sven Eckelmann <sven@narfation.org>
Date:   Tue Nov 7 11:48:40 2017 +0100

with breakage introduced by

commit 0f175041ad03d381a575e2c2b1a1c9ca76fe0e99
Author: Antonio Quartulli <ordex@autistici.org>
Date:   Fri Nov 9 15:23:34 2012 +0100

    mac80211: don't pass the hostapd ctrl iface in adhoc

ghoffman · 2018-03-19 23:49:48 UTC

@jeff -
have you isolated the problem to a specific module/package? it's not clear form your post.
if you are up to building, im trying to get meraki MR16's going. they are great with mesh on one radio and AP on the other. but obviously better with dual-band available for AP while utilizing 5g radio for backhaul.
i dont need extra packages; luci is helpful but not necessary.
let me know how i can help test.

jeff · 2018-03-19 23:55:45 UTC

No, not yet -- I can get both gretap interfaces instantiated and Mesh + AP devices instantiated on commits prior to 0f17504 on lede-17.01, but no RF from the AP. I can get Mesh + AP up and both connecting on master, but my gretap instances aren't coming up. Checking master is proving challenging, as older commits aren't building successfully for me.

jeff · 2018-03-21 02:57:11 UTC

Last-known good commit on master is 9004fc3c76324f669df3ff402faf78dc847af58a

gretap + 5 GHz mesh and AP on same radio on Archer C7

Comment on suspect commit is "netifd: update to the latest version (fixes FS#1358)"

https://bugs.openwrt.org/index.php?do=details&task_id=1452

Txf · 2018-06-14 17:39:45 UTC

Hi, I came across this topic on a search. I have two Archer C7s that I want to have in a mesh but as noted above I'm having the same issue with AP and mesh on the same radio.

Is there any update on a conclusive snapshot that works? I'm using somebody else's snapshot builds that include things like Fastpath, but seemingly those don't work with AP+mesh.