FS#2698 : netifd DFS-delayed wireless interfaces not correctly handled

Quick Actions

View Dependency Graph

Status Requires testing
Percent Complete
0%
Task Type Bug Report
Category Base system
Assigned To No-one
Operating System All
Severity Medium
Priority Very Low
Reported Version Trunk
Due in Version Undecided
Due Date Undecided
Private

Attached to Project: OpenWrt/LEDE Project
Opened by Oldřich Jedlička - 27.12.2019

FS#2698 - netifd DFS-delayed wireless interfaces not correctly handled

Found on TP-Link Archer C7 v4 on master (commit db992e7b53 - 5 days ago).

When having 3 interfaces on channel requiring radar scan (DFS), only the main interface is shown - see logs, where radio0 wifi should have 3 interfaces wlan0-lan, wlan0-guest and wlan0-admin, but only wlan0-lan is shown. Due to DFS scan it comes up after a minute after `/etc/init.d/network start` is executed.

Configuration:

2 wifis: 2,4GHz (radio1) + 5GHz (radio0)
each band has 3 SSIDs (domaci-soukroma, domaci, domaci-admin), each one’s interface assigned to one bridge - lan, guest and admin, respectively.

Called `ubus call network.wireless status`, received result:

wlan0-lan exists
wlan0-guest and wlan0-admin not recognised
wlan1-lan, wlan1-guest, wlan1-admin exist

Expected result:

wlan0-guest and wlan0-admin recognised

Configuration, logread (produced by `/sbin/netifd -d 15 -l 7`), `ubus network.device status` and `ubus network.wireless status` attached (removed IP and MAC addresses).

etc_config_network.txt (2 KiB)

etc_config_wireless.txt (3.4 KiB)

OpenWrt-logread.txt (30.5 KiB)

ubus_call_network.device_stat... (15.9 KiB)

ubus_call_network.wireless_st... (3.9 KiB)

Oldřich Jedlička commented on 01.01.2020 13:41

The problem might be in mac80211.sh, which on line 518 states:

# Hostapd will handle recreating the interface and
# subsequent virtual APs belonging to the same PHY

This is true for interfaces wlan0-guest and wlan0-admin, which are created after wlan0-lan comes up. But before this happens, the mac80211_setup_vif is called and tries to do (see lines 750-755):

logger ip link set dev "$ifname" $action
ip link set dev "$ifname" "$action" || {
  wireless_setup_vif_failed IFUP_ERROR
  json_select ..
  return
}

This needs to be postponed for wlan0-guest and wlan0-admin until the main interface wlan0-lan comes up. I believe this is worked-around also in function drv_mac80211_setup on line 962, which states:

[ "${add_ap}" = 1 ] && sleep 1
for_each_interface "ap" mac80211_setup_vif

So it gives hostapd 1 second to come up. But problem with wlan0-guest and wlan0-admin is that they come up after 60 seconds as soon as DFS scan finishes and wlan0-lan comes up.

Oldřich Jedlička commented on 01.01.2020 14:25

Added generated hostapd configs. Main interface on phy0 in the attached config is interface=wlan0-lan, others are bss=wlan0-guest and bss=wlan0-admin. phy0 does not work (uses channel requiring DFS scan on 5GHz band), phy1 works (2.4GHz band, no DFS required).

hostapd-phy0.conf (2.3 KiB)

hostapd-phy1.conf (2.1 KiB)

Oldřich Jedlička commented on 20.03.2020 20:47

Fixed by pull request 2848 .