OpenWrt/LEDE Project

  • Status New
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority High
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Stijn Tintel - 28.11.2019
Last edited by Stijn Tintel - 28.11.2019

FS#2637 - hostapd ubus reload makes OpenWrt as WiFi client very unreliable

Commit 60fb4c92b6b0d1582d31e02167b90b424185f3a2 (hostapd: add ubus reload) breaks WiFi client connectivity when for some reason the association does not succeed immediately.

I started seeing this problem on all my Raspberry Pi Zero W devices, where WiFi takes a long time to come up due to the lack of entropy:

[   32.392170] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[  104.672670] random: crng init done
[  104.685751] random: 3 urandom warning(s) missed due to ratelimiting
[  105.436537] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

At this point, the Raspberry Pi is associated to the AP, but the DHCP client is not running. This is the output of ifstatus lan:

{
        "up": false,
        "pending": false,
        "available": false,
        "autostart": true,
        "dynamic": false,
        "proto": "dhcp",
        "data": {

        },
        "errors": [
                {
                        "subsystem": "interface",
                        "code": "NO_DEVICE"
                }
        ]
}

Running ifup lan fixes the problem, but this is of course not easy to do on headless devices.

Later I also experienced this problem on a Raspberry Pi 3 A, which does not have the low entropy problem. In this case the delayed association was caused by a power outage, and the Raspberry Pi booted faster than the APs.

Project Manager
Stijn Tintel commented on 03.12.2019 18:31

I just noticed this on one of my devices, and am pretty sure it is caused by the same commit:

root@litebeam01:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option channel '36'
        option hwmode '11a'
        option path 'pci0000:00/0000:00:00.0'
        option htmode 'VHT80'
        option disabled '1'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'

config wifi-device 'radio1'
        option type 'mac80211'
        option channel '11'
        option hwmode '11g'
        option path 'platform/ahb/18100000.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'
root@litebeam01:~# ps | grep phy
  745 root      3444 S    /usr/sbin/hostapd -s -n phy0 -P /var/run/hostapd-phy0.pid -g /var/run/hostapd-phy0/global -B
  820 root      3444 S    /usr/sbin/hostapd -s -n phy1 -P /var/run/hostapd-phy1.pid -g /var/run/hostapd-phy1/global -B
  871 root      3444 S    /usr/sbin/wpa_supplicant -s -n phy0 -P /var/run/wpa_supplicant-phy0.pid -g /var/run/wpa_supplicant-phy0/global -B
  872 root      3444 S    /usr/sbin/wpa_supplicant -s -n phy1 -P /var/run/wpa_supplicant-phy1.pid -g /var/run/wpa_supplicant-phy1/global -B
 1806 root      1208 S    grep phy

We should not unconditionally start these instances I'd say.

Project Manager
Daniel Golle commented on 06.12.2019 13:04

Running the services unconditionally (to be precise: only in the presence of wifi hardware) was the intention of those commits and believe me, it's a feature, not a bug :)

The cause of the problem described by you above is probably that previously, we have been running hostapd/wpa_supplicant from those scripts and probably those services only fork to background once enough entropy had been collected.
I was hoping that introducing `ubus wait_for ...` would solve that problem, but apparently it didn't – the service is running and the configuration comes up (according to your logs), just netifd had already given up. I will try to find a way to reproduce this, but I don't have any hardware as bad as RasbPi Zero at hand, so it may take a couple of days to find it...

Project Manager
Stijn Tintel commented on 06.12.2019 13:09

If you have a spare AP you could configure a client to connect to it. Turn of that AP, boot the client, and boot the AP 2 minutes afterwards.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing