4

Question

What is the current proper way to force reconnection to a WiFi access point? (Or even better: automatically reconnect after the connection is dropped?) The only way to reconnect that has worked so far is to re-plug the USB WiFi dongle or do a full reboot.


Problem

Every so often (2-5 times/day) when the WiFi connection drops, the Pi never automatically reconnects to the WiFi network. I would like to run some command(s) to reconnect to the WiFi network, since it doesn't seem to do so automatically with a USB WiFi dongle, whereas it consistently auto-reconnects with the onboard WiFi when testing over a shorter distance. This suggests something might need to be reconfigured (or worked around) for the WiFi dongle to auto-reconnect.

(Note: The access point is both somewhat far away from the Pi and not the most reliable. Unfortunately, neither can be moved closer to the other, and the onboard WiFi doesn't "reach".)

(EDIT: Clarity)


Specifications

Raspberry Pi 3 Model B v1.2 running Raspbian Stretch Lite with latest updates and kernel version 4.14.98-v7+ as of Mar 3 2019. (EDIT: Updated from 4.14.79-v7+ to newest stable packages & kernel. This helped make the connection more reliable, but once it drops it still stays dropped until reboot.)

USB WiFi dongle plugged directly into Pi: "5dBi Long Range WiFi for Raspberry Pi" (https://www.amazon.com/gp/product/B00YI0AIRS) with a Realtek 8192CU chipset.

$ lsusb

Bus 001 Device 005: ID 0bda:8178 Realtek Semiconductor Corp. RTL8192CU 802.11n WLAN Adapter

Configuration

Default DHCP setup, no static IP, /etc/network/interfaces left untouched.

/etc/wpa_supplicant/wpa_supplicant.conf:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US

network={
        ssid="MySSID"
        psk="MyPassword"
}

Onboard WiFi disabled by adding the following line to the end of /boot/config.txt:

dtoverlay=pi3-disable-wifi

/etc/modprobe.d/8192cu.conf:

# Disable power saving and USB selective suspend
options 8192cu rtw_power_mgnt=0 rtw_enusbss=0

Likely defaults, but nearby files are as follows:
/etc/modprobe.d/blacklist-rtl8192cu.conf: blacklist rtl8192cu
/etc/modprobe.d/blacklist-rtl8xxxu.conf: blacklist rtl8xxxu

$ iwconfig wlan0

wlan0     IEEE 802.11bgn  ESSID:"MySSID"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:2.437 GHz  Access Point: 01:23:45:67:89:AB
          Bit Rate:144.4 Mb/s   Sensitivity:0/0
          Retry:off   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=100/100  Signal level=60/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

$ ifconfig wlan0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.123  netmask 255.255.255.0  broadcast 192.168.1.255
        [...]

I chose this WiFi chipset after reading from multiple sources that it was especially plug and play with the Raspberry Pi. It is, to a point... However, when trying all of the various methods detailed below to restart WiFi without rebooting, I either get an error, nothing happens, or the WiFi goes down and won't come back up without a reboot. Until now, the only reliable way I have found to remotely reconnect is to periodically reboot the Pi; an ugly solution for sure.


What I've Tried (without success)

  • ifconfig interface down/up:

    sudo ifconfig wlan0 down
    sudo ifconfig wlan0 up
    

    Brings the interface down and up, but it never gets an IP address.

  • wpa_cli stuff:

    wpa_cli -i wlan0 disconnect
    wpa_cli -i wlan0 reassociate
    

    or just:

    wpa_cli -i wlan0 reassociate
    

    Both result in the WiFi never reconnecting/no IP address.

  • In wpa_cli interactive mode, I get an "Association request to the driver failed" error:

    $ wpa_cli -i wlan0
    wpa_cli v2.4
    Interactive mode
    
    > reassociate
    OK
    <3>CTRL-EVENT-SCAN-STARTED
    <3>CTRL-EVENT-SCAN-RESULTS
    <3>Trying to associate with 01:23:45:67:89:ab (SSID='MySSID' freq=2462 MHz)
    <3>Association request to the driver failed
    <3>CTRL-EVENT-SCAN-STARTED
    <3>CTRL-EVENT-SCAN-RESULTS
    <3>WPS-AP-AVAILABLE
    <3>Trying to associate with 01:23:45:67:89:ab (SSID='MySSID' freq=2462 MHz)
    <3>Association request to the driver failed
    ...
    

    (This just loops until I quit with q.)

  • Running wpa_supplicant directly:

    sudo killall wpa_supplicant
    sudo wpa_supplicant -B -c/etc/wpa_supplicant/wpa_supplicant.conf -iwlan0 -Dnl80211,wext
    
  • Another combo:
    sudo killall wpa_supplicant
    sudo dhclient -v -r wlan0
    
    followed by
    sudo systemctl restart dhcpcd.service
    sudo dhclient -v wlan0
    
  • Manually deleting the lease file before running some/all of commands in the above two bullets:
    sudo rm /var/lib/dhcpcd5/dhcpcd-wlan0-MySSID.lease
  • All of the above combined with re-enabling the onboard WiFi in /boot/config.txt, but this doesn't seem to be part of the problem.
  • 1
    raspberrypi.org/forums/… – Dougie Mar 3 at 23:35
  • @Dougie Thanks, though I'm not sure exactly which action(s) described at that point in the linked forum post you suggest I take. I updated to the newest stable kernel 4.14.98-v7+ and while it certainly reduced the frequency of connection drops (thanks!), it still does not automatically reconnect. I don't see that dmesg error when I ran dmesg | grep 'failed' after updating (forgot to check before). – Orange42m Mar 5 at 2:13
3

Very good explained question. I cannot see direct what may be wrong. But here are some quirks I have seen in your description.

You use deprecated commands ifconfig and iwconfig. I prefer to use up to date commands ip from iproute2 and iw. You may consider to also switch over to the new commands?

The wlan0 interface has a netmask of 255.255.255.1. This is an illegal netmask. I suppose it's a typo.

On default Raspbian, networking is managed by dhcpcd. You try to use the isc-dhcp-client named dhclient. It doesn't make sense because it has no functionality. dhcpcd is used.

dhcpcd manages wpa_supplicant in a hook file completely in its own way without reference to the default operating system features. For example systemctl status wpa_supplicant.service will not give you any usable information about the running wpa_supplicant. Mostly it shows that it is disabled. Maybe you will have a look at /usr/lib/dhcpcd/dhcpcd-hooks/ to get an idea.

Respecting this special behavior of dhcpcd I'm not sure if ifconfig interface down/up (or sudo ip link set dev wlan0 down/up) triggers the dhcp client to get or renew a lease. If in doubt I use sudo systemctl restart dhcpcd.

If you re-enable the on-board WiFi you have to distinguish between wlan0 and wlan1 of course. I don't know how dhcpcd do that.

You are already running wpa_supplicant directly. Do it with the debug option -d. It give you a bunch of output but maybe you will find a hint what's going wrong.

Having a glance at How do I set up networking/WiFi/static IP address? may also help.

I prefer to use systemd-networkd. With it you have better control about services integrated into the operating system.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.