AP on brcm63xx fails due to noscan

[ilario]

I'm using LibreMesh compiled on top of OpenWrt's openwrt-18.06 branch (a bit more recent than OpenWrt 18.06.4) and I'm experiencing errors maybe more related with OpenWrt rather than with LibreMesh (?).

Trying to use a Broadcom (radio does not support combinations, e.g. does not support multi-AP) I am configuring the radio as an AP dedicated to backbone connection (not for clients, see #554). Even when editing /etc/config/lime for having just one AP interface, hostapd fails due to the presence of an unsupported (by the wireless driver) distance (and noscan) options. Shouldn't OpenWrt be able to manage this? Should we take care of this on LibreMesh side?

Tue Oct 15 14:37:12 2019 user.notice mac80211: Failed command: iw phy phy0 set antenna all all
Tue Oct 15 14:37:12 2019 daemon.notice netifd: radio0 (6592): command failed: Not supported (-122)
Tue Oct 15 14:37:12 2019 user.notice mac80211: Failed command: iw phy phy0 set distance 100
Tue Oct 15 14:37:13 2019 daemon.err hostapd: Configuration file: /var/run/hostapd-phy0.conf
Tue Oct 15 14:37:13 2019 daemon.err hostapd: Line 10: unknown configuration item 'noscan'
Tue Oct 15 14:37:13 2019 daemon.err hostapd: 1 errors found in configuration file '/var/run/hostapd-phy0.conf'
Tue Oct 15 14:37:13 2019 daemon.err hostapd: Failed to set up interface with /var/run/hostapd-phy0.conf
Tue Oct 15 14:37:13 2019 daemon.err hostapd: Failed to initialize interface
Tue Oct 15 14:37:13 2019 daemon.notice netifd: radio0 (6592): cat: can't open '/var/run/wifi-phy0.pid': No such file or directory
Tue Oct 15 14:37:13 2019 daemon.notice netifd: radio0 (6592): WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process  path ()
Tue Oct 15 14:37:13 2019 daemon.notice netifd: radio0 (6592): Command failed: Invalid argument
Tue Oct 15 14:37:13 2019 daemon.notice netifd: radio0 (6592): Device setup failed: HOSTAPD_START_FAILED

On a side note, on other routers I noticed similar errors (but the device was working anyway as they were related to commands running before hostapd), for example:

On a TP-Link WDR3600 (with a bit of additional configuration, not relevant here):

Sun Oct 20 20:11:06 2019 user.notice mac80211: Failed command: iw phy phy1 set antenna all all
Sun Oct 20 20:11:06 2019 user.notice mac80211: Failed command: iw phy phy0 set antenna all all
Sun Oct 20 20:11:07 2019 daemon.notice netifd: radio1 (1575): Usage:    iw [options] dev <devname> set channel <channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]
Sun Oct 20 20:11:07 2019 daemon.notice netifd: radio1 (1575): Options:
Sun Oct 20 20:11:07 2019 daemon.notice netifd: radio1 (1575):   --debug     enable netlink debugging
Sun Oct 20 20:11:07 2019 user.notice mac80211: Failed command: iw dev wlan1-mesh set channel 48 HT40

On a Mediatek router YouHua WR1200JS with default LibreMesh configuration:

Sun Oct 20 20:02:41 2019 user.notice mac80211: Failed command: iw phy phy0 set antenna all all
Sun Oct 20 20:02:41 2019 daemon.notice netifd: Interface 'lm_net_wlan1_mesh_batadv_if' is disabled
Sun Oct 20 20:02:42 2019 user.notice mac80211: Failed command: iw phy phy1 set antenna all all
[...]
Sun Oct 20 20:02:42 2019 daemon.err hostapd: Using interface wlan0-ap with hwaddr d6:5f:25:eb:7e:ac and ssid "LibreMesh.org"
Sun Oct 20 20:02:42 2019 daemon.notice netifd: radio1 (10527): Usage:   iw [options] dev <devname> set channel <channel> [NOHT|HT20|HT40+|HT40-|5MHz|10MHz|80MHz]
Sun Oct 20 20:02:42 2019 daemon.notice netifd: radio1 (10527): Options:
Sun Oct 20 20:02:42 2019 daemon.notice netifd: radio1 (10527):  --debug     enable netlink debugging
Sun Oct 20 20:02:42 2019 user.notice mac80211: Failed command: iw dev wlan1-mesh set channel 48 HT40

[ilario]

Regarding the second half of the bug report, see the specific issue on #647.

[ilario]

There have been no reports on this in years... Also because the AP-sta backbone is not a well known feature, I suspect. Seems that the distance setting is not a problem: it will cause an iw error message but hostapd should run anyway.

So the problem is only noscan. https://github.com/libremesh/lime-packages/blob/08a3948a5a80f6e26318c96227e02466bd09345e/packages/lime-system/files/usr/lib/lua/lime/wireless.lua#L172 Looking for noscan on OpenWrt website, there is an interesting phrase: "noscan Do not scan for overlapping BSSs in HT40+/-. Turning this on will violate regulatory requirements!" noscan has been added by @dangowrt in #48 @dangowrt, is noscan still needed? There is no strong reason for removing it, as seems that it works on most wifi chips... But if we can remove that line is better.

Also, I am not sure this still causes errors on modern OpenWrt...