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#2637 - hostapd ubus reload makes OpenWrt as WiFi client very unreliable #7899
Comments
stintel: 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
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. |
dangowrt: 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. |
stintel: 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. |
dangowrt: I've now tried exactly that and cannot reproduce the issue. Can it be that the wifi driver (maybe brcmfmac? cfg80211?) doesn't signal link status properly and our 'ip link set wlan0 up' call makes it come up prematurely? |
stintel: Any suggestions on how to check this would be appreciated. |
dangowrt: To test this, please try this: |
stintel: https://drive.google.com/file/d/1SJQx9ukPT6ZeOmz1GpYwYlYgeWRBTYSO/view?usp=sharing Since the device was not connected I could not do this over SSH, so here's a photo. |
stintel: As I noticed some changes were made to wifi reconfig recently, I tried with master r13499-7b4877c204 and at first sight I can no longer reproduce. The crng is initialized a bit faster in this new version, I will try booting the RPi0W with the AP offline for 2 minutes.
[ 72.436719] random: crng init done
[ 72.453561] random: 2 urandom warning(s) missed due to ratelimiting
[ 73.233633] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
FYI, on this version, I am not seeing this line: |
stintel: Brought up the AP after ~25m uptime on the RPi0W and it instantly connected and requested an IP via DHCP. |
stintel:
Commit 60fb4c9 (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": {
}
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.
The text was updated successfully, but these errors were encountered: