1

Problem Statement

I have an embedded Linux system which uses systemd-networkd for network management. Roughly half the time, the device can connect to a Wifi AP and obtain an IPv4 address via DHCP in under 30 seconds. In the other cases, system logs shows authentication and association but the device does not obtain an IPv4 address. I've waited 5 minutes or longer without getting an IP.

Configuration

1) This is the /etc/systemd/network/wlan0.network configuration file:

[Match]
Name=wlan0
[Network]
DHCP=ipv4
IPv6AcceptRA=no
LinkLocalAddressing=no

I have also had the .network file setup with just DHCP=yes and nothing below that. The results seem the same.

2) Here is the /etc/wpa_supplicant.conf file:

ctrl_interface=/var/run/wpa_supplicant
ap_scan=1

country=US

network={
        ssid=<my SSID>
        psk=<my key>
}

3) I did not configure my own wpa_supplicant@wlan0.service file for wpa_supplicant as I am starting it manually when the interface is needed. No other network managers are installed (NetworkManager, connman, etc). I am not starting any DHCP tools (dhclient, dhcpcd); I am relying on the systemd-network internals for that.

Debugging

1) Here is the output of dmesg | tail showing association, which always happens regardless of getting an IP address:

[  846.988274] ieee80211 phy1: WMM Turbo=1
[  847.312843] wlan0: authenticate with <AP MAC addr>
[  847.329052] wlan0: send auth to <AP MAC addr> (try 1/3)
[  847.334566] wlan0: authenticated
[  847.352271] wlan0: associate with <AP MAC addr> (try 1/3)
[  847.362762] wlan0: RX AssocResp from <AP MAC addr> (capab=0x1011 status=0 aid=1)
[  847.373968] wlan0: associated
[  847.391864] wlan0: Limiting TX power to 24 (24 - 0) dBm as advertised by <AP MAC addr>

This output comes from the driver, so is probably not too meaningful in a generic sense other than to say "it associated".

2) Some blogs/posts suggest commands like systemctl restart systemd-networkd and ifconfig wlan0 down && ifconfig wlan0 up to trigger a DHCP renegotiation. Sometimes the latter command works...although I can't tell if just waiting a few seconds made some difference.

3) When everything works, I see a log like this:

Apr 25 12:41:43 host systemd-networkd[511]: [[0;1;39m[[0;1;31m[[0;1;39mwlan0: found matching network '/etc/systemd/network/wlan0.network', based on potentially unpredictable ifname[[0m
Apr 25 12:41:43 host systemd-networkd[511]: wlan0: IPv6 successfully disabled
Apr 25 12:41:48 host systemd-networkd[511]: wlan0: Gained carrier
Apr 25 12:41:48 host systemd-networkd[511]: wlan0: DHCPv4 address 10.217.244.165/8 via 10.128.128.128
Apr 25 12:41:48 host systemd-networkd[511]: wlan0: Configured

When the issue occurs, I just see the "wlan0: found matching network..." message.

4) Similar to dmesg, iw wlan0 link always shows connection to the AP, even when not obtaining an IP:

$ iw wlan0 link
Connected to <AP MAC addr> (on wlan0)
    SSID: <AP name>
    freq: 5200
    RX: 87243 bytes (416 packets)
    TX: 3038 bytes (11 packets)
    signal: -60 dBm
    tx bitrate: 6.0 MBit/s

    bss flags:  short-slot-time
    dtim period:    1
    beacon int: 100

Edit: The driver has a known bug where "the output of the command iw wlan0 link always displays the bitrate as the lowest data rate for the connected frequency band." So 6.0 MBit/s is false. However the signal level should be correct.

Question

Anyone have further recommendations on debugging or configuration to get this working reliably? It's unclear to me if this is a driver issue, systemd issue, or network issue.

bjornruffians
  • 133
  • 1
    Having a TX of 6 Mbits show that you either have a lot of noise/walls/box and/or are not that near from the AP. I honestly have my doubts whether debugging people Wifi problems is entirely on-topic here just for the sake of Wifi layer problems (e.g. Unix forum). You also are obscuring entirely the MAC address, do not do that to the first 6 digits, otherwise without identifying the brand and model, it is impossible to know which chipset is that. Furthermore, nano USB sticks/iOT without antennas suck when it comes to range, and often even do not work well even when at the side of an AP. – Rui F Ribeiro Apr 25 '19 at 13:29
  • also most of those iOTs use realtek to shave costs (Chinese buy them by the truckload) see https://unix.stackexchange.com/questions/252210/wi-fi-problems-using-asus-usb-n13-adapter-realtek/252215#252215 – Rui F Ribeiro Apr 25 '19 at 13:33
  • This is a Laird Wifi/BT chip if it matters, with 2 external dual-band antennas. I'm mostly interested in the software configuration shown here...if I'm doing something wrong to that effect. It's quite possible the issue is hardware, though I've tried to rule that out as best I can. – bjornruffians Apr 25 '19 at 13:34
  • 1
    Anyway, getting 6MBps is not exactly being near from the AP. Walls? Inside a cabinet? Inside a fake ceiling? Noise/industrial noise? Having 6Mbps I pretty much doubt it is an issue in the Unix side. – Rui F Ribeiro Apr 25 '19 at 13:37
  • Just verified: there's a known issue with this driver regarding bit rate reported. Will add to post. – bjornruffians Apr 25 '19 at 13:42
  • 2
    Per Rui's suggestion, I re-arranged the antennas a bit to give them a clearer path. The antennas were also resting on an ESD mat so I isolated them with some insulating material (wood). The board now reports signal strength around -45dBm, which is improved. Monitoring a few more connect attempts before calling that my issue.

    I suppose I'm surprised that -60dBm wasn't high enough signal strength...

     – bjornruffians Apr 25 '19 at 14:18
  • did you consider your wifi has some stability issue or configuration problem ? – Kiwy Apr 29 '19 at 09:27

1 Answers1

1

From your signal and mainly TX rate at 6Mbps, there are clearly issues at the layer 2 which have to be improved. The signal is not strong enough to guarantee a reliable service.

Once the strength of the signal is improved, the DHCP problems will disappear.

TLDR The problem is not on the Unix side of things per se.

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232