Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#550 - hostapd (wpad-mesh) fails to start interface at same time with meshpoint interface #6399

Closed
openwrt-bot opened this issue Feb 22, 2017 · 10 comments
Labels

Comments

@openwrt-bot
Copy link

charlemagnelasse:

Test device: OM2P from 2011 with ath9k and ar71xx subtarget
Version: LEDE 17.01.0-rc1 branch commit reboot-3208-g349577adbf

Build the image with following .config

CONFIG_TARGET_ar71xx=y CONFIG_TARGET_ar71xx_generic=y CONFIG_TARGET_ar71xx_generic_DEVICE_OM2P=y CONFIG_OPENSSL_WITH_DEPRECATED=y CONFIG_OPENSSL_WITH_EC=y CONFIG_OPENSSL_WITH_NPN=y CONFIG_OPENSSL_WITH_PSK=y CONFIG_OPENSSL_WITH_SRP=y CONFIG_PACKAGE_libopenssl=y CONFIG_PACKAGE_wpad-mesh=y # CONFIG_PACKAGE_wpad-mini is not set

Then modify /etc/config/wireless to look like this:

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

config wifi-iface 'ap2'
option device 'radio0'
option ifname 'ap-2'
option network 'lan'
option mode 'ap'
option ssid 'meshedAP'
option macaddr 'ac:86:74:00:00:01'
option encryption 'none'

config wifi-iface 'mesh2'
option device 'radio0'
option ifname 'mesh-2'
option network 'lan'
option mode 'mesh'
option mesh_id 'mymesh'
option disabled '0'
option mcast_rate '54000'
option macaddr 'ae:86:74:00:00:01'
option mesh_ttl 1
option mesh_fwding 0
option encryption 'none'
option ieee80211w 1
option encryption 'psk2+aes'
option key 'reallysecretkey'

The iw dev output looks then like this:

phy#0 Interface ap-2 ifindex 8 wdev 0x3 addr ac:86:74:00:00:01 type AP txpower 20.00 dBm Interface mesh-2 ifindex 7 wdev 0x2 addr ae:86:74:00:00:01 type mesh point channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz txpower 20.00 dBm

Setting encryption to "none" doesn't help. But it seems to work fine when the mesh interface is disabled in uci

phy#0 Interface ap-2 ifindex 11 wdev 0x6 addr ac:86:74:00:00:01 ssid meshedAP type AP channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz txpower 20.00 dBm

This could become a big problem for freifunk-gluon when 802.11s is used instead of IBSS in the site.conf. Their setup is using AP + mesh on the same PHY

@openwrt-bot
Copy link
Author

charlemagnelasse:

Just something I've noticed: When encryption is set to none + a key is set (to "reallysecretkey") then it fails.

But when you set encryption to none and key not at all then it will work. The relevant code portion can be found in lib/netifd/wireless/mac80211.sh

mesh) # authsae or wpa_supplicant json_get_vars key if [ -n "$key" ]; then

It checks for key and not encryption - thought it would check for encryption != none.

So it may not affect gluon after all because their config doesn't contain a "key" setting for the meshpoint device.

But the rest (encrypted mesh + AP) looks like a regression to me. It was working with encryption well in the past when it was still called OpenWrt - forgot the commit I've used.

@openwrt-bot
Copy link
Author

charlemagnelasse:

I think I found out what I did differently with OpenWrt. I think I was using authsae:

CONFIG_TARGET_ar71xx=y CONFIG_TARGET_ar71xx_generic=y CONFIG_TARGET_ar71xx_generic_DEVICE_OM2P=y CONFIG_OPENSSL_WITH_DEPRECATED=y CONFIG_OPENSSL_WITH_EC=y CONFIG_OPENSSL_WITH_NPN=y CONFIG_OPENSSL_WITH_PSK=y CONFIG_OPENSSL_WITH_SRP=y CONFIG_PACKAGE_authsae=y CONFIG_PACKAGE_libconfig=y CONFIG_PACKAGE_libopenssl=y CONFIG_PACKAGE_wpad-mesh=y # CONFIG_PACKAGE_wpad-mini is not set phy#0 Interface ap-2 ifindex 9 wdev 0x5 addr ac:86:74:00:00:01 ssid meshedAP type AP channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz txpower 20.00 dBm Interface mesh-2 ifindex 8 wdev 0x4 addr ae:86:74:00:00:01 type mesh point channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz txpower 20.00 dBm

But afaik, authsae is not supporting DFS and is extreme limited

This ticket therefore shows only a problem in the wpa_supplicant part of wpad-mesh and not necessarily in the hostapd part

@openwrt-bot
Copy link
Author

charlemagnelasse:

Upstream was informed

@openwrt-bot
Copy link
Author

charlemagnelasse:

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;
}

@openwrt-bot
Copy link
Author

jeffsf:

Similar behavior confirmed on Archer C7, 5 GHz radio, 17.01.4, 17.01 of March 2018, and master of March 2018.

Seems to be a "last one wins" situation, depending on the order declared in ''/etc/config/wireless'' -- see below for config snippets.

Proposed patch above untested at this time. Corresponds to line 5144 //et seq// in ''wpa_supplicant_init_iface()''

config wifi-device 'radio1' 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
option device 'radio1'
option mode 'mesh'
option mesh_id ''
option mesh_fwding '1'
option encryption 'psk2+ccmp'
option key ''
option network 'mesh'

phy#0
Interface wlan0
ifindex 27
wdev 0x2
addr
type mesh point
channel 149 (5745 MHz), width: 80 MHz, center1: 5775 MHz
txpower 30.00 dBm

=====

config wifi-iface
option device 'radio1'
option mode 'ap'
option ssid 'test'
option key 'test'
option encryption 'psk2+ccmp'
option network 'vlan100'

phy#0
Interface wlan0
ifindex 29
wdev 0x2
addr
type managed
txpower 30.00 dBm

=====

config wifi-iface
option device 'radio1'
option mode 'ap'
option ssid 'test'
option key 'test'
option encryption 'psk2+ccmp'
option network 'vlan100'

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

phy#0
Interface wlan0
ifindex 61
wdev 0x3
addr
type mesh point
txpower 0.00 dBm

=====

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

config wifi-iface
option device 'radio1'
option mode 'ap'
option ssid 'test'
option key 'test'
option encryption 'psk2+ccmp'
option network 'vlan100'

phy#0
Interface wlan0
ifindex 62
wdev 0x4
addr
type mesh point
txpower 0.00 dBm

@openwrt-bot
Copy link
Author

jeffsf:

Checking git://w1.fi/hostap.git

The "offending" section is no longer present in wpa_supplicant.c

Further, it now contains specific CONFIG_MESH ifdefs

#ifdef CONFIG_MESH
#include "ap/ap_config.h"
#include "ap/hostapd.h"
#endif /* CONFIG_MESH */

(and more)

Initial work to incorporate the current wpa_supplicant master branch HEAD underway.

@openwrt-bot
Copy link
Author

jeffsf:

Work In progress -- Compiles now -- [[https://forum.lede-project.org/t/is-there-a-make-test-option/12632/1|looking for automated tests]]

''#ifdef CONFIG_CTRL_IFACE_MIB'' needed to be moved to allow new function to be seen in ''ctrl_iface_ap.c''

@openwrt-bot
Copy link
Author

jeffsf:

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

@openwrt-bot
Copy link
Author

charlemagnelasse:

This was fixed a while ago https://git.openwrt.org/?p=openwrt/openwrt.git;a=log;h=d91494eedf06ac6b31c1aa9f7172871b16af96c8

But I don't have the rights to close my own bug.

@openwrt-bot
Copy link
Author

jeffsf:

d91494e is in lede-17.01 and the failure mode exists on that branch. Perhaps a different commit?

I see ''package/network/services/hostapd/patches/370-ap_sta_support.patch'' in lede-17.0.1 and will give it another try.

OK, //can leave closed// -- seems to be coming up now with today's build off

commit 60f8d388c69e0faddbf1c3033cdcb74b38fe3694 (HEAD -> lede-17.01, origin/lede-17.01, github/lede-17.01) Author: Felix Fietkau 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>

No idea why this was not the case earlier. I'll pursue the other problems (as the APs come up, but the mesh doesn't connect and the log is flooded with errors) under another issue, once I have narrowed them down.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant