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.
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)
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?
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'
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 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) - #9 by jeff
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.
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=''
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.
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)"
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.
"Works for me", at least on the 5 GHz radio, in recent builds (April and later) off master and should be working on openwrt-18.06
Hmm. Tried the latest 18.06 snapshot. Had no luck. I needed to disable the AP before I got a working mesh. This was with wpad-mesh.
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'pci0000:01/0000:01:00.0'
option htmode 'VHT80'
option disabled '0'
#config wifi-iface 'default_radio0'
# option device 'radio0'
# option network 'lan'
# option mode 'ap'
# option ssid 'OpenWrt'
# option encryption 'none'
config wifi-iface 'mesh'
option device 'radio0'
option ifname 'wlan0-1'
option mode 'mesh'
option mesh_id 'mymesh'
option encryption 'none'
option network 'lan'
# option mesh_fwding '1'
option disabled '0'
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/qca955x_wmac'
option htmode 'HT20'
option disabled '1'
config wifi-iface 'default_radio1'
option device 'radio1'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'none'
This is the only way mesh works for me.
Sorry for a double post but I managed to fix the issue. I'll just document it, in case anybody else has problems.
config wifi-iface 'default_radio0'
option device 'radio0'
option ifname 'wlan0'
option network 'lan'
option mode 'ap'
option ssid 'OpenWrt'
option encryption 'none'
I needed to add an ifname for the AP config.
The thread subject is "authenticated" mesh -- how is it "authenticated"?
Because the following works quite well, once you've got your mesh stations and APs straightened out without encryption
config wifi-iface 'mesh0'
option device 'radio5'
option ifname 'mesh0'
option mode 'mesh'
option mesh_id '<your mesh ID here>'
option mesh_fwding '1'
option encryption 'psk2+ccmp'
option key '<your key here>'
option sae_password '<your key here>'
This is running config, and the presence of both key and sae_password is due to numerous changes in the OpenWRT code which had it flip-flopping between which of the two worked at any moment.
Yeah. Sorry. Just confirming that I did what jeff said above, putting encryption afterwards presented no issues.
I've set up a working 802.11s mesh on single band routers running OpenWrt 18.06.1, but have yet to secure it. My current configuration is as follows:
/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 '<redacted>'
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option ipaddr '192.168.0.2'
option netmask '255.255.255.0'
option gateway '192.168.0.1'
list dns '200.12.232.4'
list dns '200.12.229.1'
list dns '8.8.8.8'
option ip6assign '60'
config device 'lan_dev'
option name 'eth0.1'
option macaddr '<redacted>'
config interface 'wan'
option ifname 'eth0.2'
option proto 'dhcp'
config device 'wan_dev'
option name 'eth0.2'
option macaddr '<redacted>'
config interface 'wan6'
option ifname 'eth0.2'
option proto 'dhcpv6'
config switch
option name 'switch0'
option reset '1'
option enable_vlan '1'
config switch_vlan
option device 'switch0'
option vlan '1'
option ports '0 1 6t'
config switch_vlan
option device 'switch0'
option vlan '2'
option ports '4 6t'
/etc/config/wireless:
config wifi-device 'radio0'
option type 'mac80211'
option hwmode '11g'
option path 'platform/10300000.wmac'
option htmode 'HT20'
option disabled '0'
option legacy_rates '1'
option channel '1'
config wifi-iface
option device 'radio0'
option ifname 'wlan0'
option network 'lan'
option mode 'ap'
option ssid '<redacted>'
option encryption 'psk2+ccmp'
option key '<redacted>'
config wifi-iface
option device 'radio0'
option ifname 'mesh0'
option network 'lan'
option mode 'mesh'
option mesh_id '<redacted>'
option mesh_fwding '1'
Both wifi interfaces (wlan0 in AP mode and mesh0 in mesh mode) are on the same radio0 device.
Previous attempts at adding @jeff's suggested encryption options
option encryption 'psk2+ccmp'
option key '<your key here>'
option sae_password '<your key here>'
to the mesh0 interface have rendered wlan0 inaccesible.
I'll document my attempts to get encryption to work on both interfaces in this thread.
First trial after adding @jeff's suggested encryption options:
Since I can't ping the non-wired meshed routers from stations or from the wired meshed router, I assume IP packets aren't being routed through the mesh. But I could when the mesh was unencrypted.
I'll appreciate hints and tips.