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:
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.
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.
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.
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.
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:
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
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;
}
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!
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!
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?
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?
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>
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.
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
@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.
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.
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.