Odd WiFi Drop Out Issues

[GeorgeIoak]

I have a Raspbeery Pi Model 3+ which is connected to the official 7" touch screen and an OpenSprinkler board. I am using the built-in WiFi and I can access the Pi through ssh but after anywhere from 1 to maybe 5 days I cannot ssh into the Pi. When I go to the screen and check Network Manager in the menu it shows the 5G symbol, full strength, and the SSID name.

Code: Select all

pi@OSPI:~ $ cat /proc/device-tree/model
Raspberry Pi 3 Model B Plus Rev 1.3

pi@OSPI:~ $ uname -a
Linux OSPI 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

pi@OSPI:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

pi@OSPI:~ $ sudo iw dev wlan0 info
Interface wlan0
        ifindex 3
        wdev 0x1
        addr b8:27:eb:22:cd:c0
        ssid TheIoaks
        type managed
        wiphy 0
        channel 48 (5240 MHz), width: 80 MHz, center1: 5210 MHz
        txpower 31.00 dBm

If I check the logs I see a lot of this if I cannot ssh into the Pi:

Code: Select all

pi@OSPI:~ $ dmesg | grep error
[67604.358261] brcmfmac: brcmf_run_escan: error (-110)
[67604.358271] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[67664.358325] brcmfmac: brcmf_run_escan: error (-110)
[67664.358335] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[67724.438442] brcmfmac: brcmf_run_escan: error (-110)
[67724.438452] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[67784.438503] brcmfmac: brcmf_run_escan: error (-110)
[67784.438513] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[67844.438621] brcmfmac: brcmf_run_escan: error (-110)
[67844.438632] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[67904.438768] brcmfmac: brcmf_run_escan: error (-110)
[67904.438778] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[67964.438898] brcmfmac: brcmf_run_escan: error (-110)
[67964.438908] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[68024.439042] brcmfmac: brcmf_run_escan: error (-110)
[68024.439052] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[68084.439206] brcmfmac: brcmf_run_escan: error (-110)
[68084.439216] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[68144.439380] brcmfmac: brcmf_run_escan: error (-110)
[68144.439390] brcmfmac: brcmf_cfg80211_scan: scan error (-110)
[68204.439588] brcmfmac: brcmf_run_escan: error (-110)
[68204.439599] brcmfmac: brcmf_cfg80211_scan: scan error (-110)

When I can ssh into the Pi I find this:

Code: Select all

pi@OSPI:~ $ journalctl | grep carrier
Sep 11 08:01:12 OSPI dhcpcd[370]: eth0: waiting for carrier
Sep 11 08:01:12 OSPI dhcpcd[370]: wlan0: waiting for carrier
Sep 11 08:01:12 OSPI dhcpcd[370]: wlan0: carrier acquired
Sep 11 08:01:12 OSPI dhcpcd[370]: wlan0: carrier lost
Sep 11 08:01:21 OSPI dhcpcd[370]: wlan0: carrier acquired
Sep 11 08:01:38 OSPI dhcpcd[370]: wlan0: carrier lost
Sep 11 08:01:59 OSPI dhcpcd[370]: wlan0: carrier acquired
Sep 11 08:04:27 OSPI dhcpcd[370]: wlan0: carrier lost
Sep 11 08:04:28 OSPI dhcpcd[370]: wlan0: carrier acquired
Sep 12 01:59:49 OSPI dhcpcd[370]: wlan0: carrier lost
Sep 12 01:59:52 OSPI dhcpcd[370]: wlan0: carrier acquired
Sep 12 01:59:56 OSPI dhcpcd[370]: wlan0: carrier lost
Sep 12 01:59:57 OSPI dhcpcd[370]: wlan0: carrier acquired

I have several other devices and computers that connect through WiFi and I don't seem to have a problem with them. If there is a problem they are all able to self recover (iPad, Mac, Windows PC, Android phone, Smart Devices). Because of that fact I don't think it's an issue with the router. This has been going on for a long time so it's not related to a new update. I've been searching trying to find solutions but so far I can't and I'm not sure what else I can do to try and debug this.

When this happens I haven't been able to recover the WiFi other than just rebooting the Pi.

Any help in trying to narrow down what is going on and how to fix it would be appreciated!

[Andyroo]

Possibly power supply issues?

I had a real problem till I moved to an official power supply.

You could try

Code: Select all

sudo iw wlan0 set power_save off

but I think that would be hitting you before this time.

Also this thread may help https://www.raspberrypi.org/forums/view ... p?t=239730

[GeorgeIoak]

I don't think that this is related to power supply, it's got a known good power supply rated at 2.4A and measured voltage at the Pi is 5.1V

I've read multiple threads that the default power settings for WiFi are OFF and that when you display the settings there is a bug that shows that power savings are turned on. At one point I did try adding it to the config file and I still got this problem.

I've looked at that thread and I was hoping to find the root cause of why this is happening rather than just resetting the Pi or WiFi on a periodic basis. Of course if I can't find a solution I can use that method but if I remember correctly I've tried to bring the WiFi down and then up when this happens (working from the LCD connected to the Pi) and that didn't revive the connection so right now the only thing that works is rebooting the Pi.

Are there other logs or settings that I can enable to see what is causing this?

[epoch1970]

You can try killing the wpa_supplicant process if it survives your network down/up maneuver.
Power source stability is a possible cause indeed.

[GeorgeIoak]

Next time the connection drops I'll try

Code: Select all

service wpa_supplicant stop

and then see if I can start the service again and gain access again.

If it was a power supply issue wouldn't I expect to see other "random" errors in the logs?

[Andyroo]

I did not on my 3 - WiFi was the only thing that gave me issues.

No idea why the WiFi was impacted but I know when I changed to power over then the issues cleared. No change of software at OS or application level and no relocation of Pi or AP

[vamfoom]

I have 4 Raspberry Pis (three 3 B+ and a Zero W), they all seem to have issues with wifi. They all utilize genuine Raspberry Pi power supplies. I've scoured the whole Internet and found a lot of people having similar issues with suggestions to fix/work-around the issue. I've disable power management using all the methods mentioned but nothing really seems to help. The only thing that really helps a little is a script that monitors connectivity to an IP to detect network drops then restart the wifi interface, but even this is getting to be a bit unreliable. At this point, i wouldn't consider using the Pi with Wifi. Using the LAN port is the only good solution to network issue on the Pi. Shouldn't the default for Raspbian be set to make this reliable, if there is really a solution?

I'm keeping a log and on the pi zero, there could be periods of up to 10 minute of wifi issues:

Code: Select all

09-13 02:20:01 PM Network is UP. Just exit the program.
09-13 02:21:01 PM Network is UP. Just exit the program.
09-13 02:22:01 PM Network is UP. Just exit the program.
09-13 02:23:01 PM Network is UP. Just exit the program.
09-13 02:24:02 PM Network is UP. Just exit the program.
09-13 02:25:01 PM Network is DOWN. Perform a reset
09-13 02:26:02 PM Network is DOWN. Perform a reset
09-13 02:27:01 PM Network is DOWN. Perform a reset
09-13 02:28:01 PM Network is DOWN. Perform a reset
09-13 02:29:02 PM Network is DOWN. Perform a reset
09-13 02:30:02 PM Network is DOWN. Perform a reset
09-13 02:31:01 PM Network is DOWN. Perform a reset
09-13 02:32:01 PM Network is DOWN. Perform a reset
09-13 02:33:02 PM Network is DOWN. Perform a reset
09-13 02:34:01 PM Network is DOWN. Perform a reset
09-13 02:35:01 PM Network is DOWN. Perform a reset
09-13 02:36:01 PM Network is DOWN. Perform a reset
09-13 02:37:01 PM Network is DOWN. Perform a reset
09-13 02:38:02 PM Network is UP. Just exit the program.
09-13 02:39:01 PM Network is UP. Just exit the program.
09-13 02:40:01 PM Network is UP. Just exit the program.
09-13 02:41:02 PM Network is UP. Just exit the program.
09-13 02:42:01 PM Network is UP. Just exit the program.
09-13 02:43:01 PM Network is UP. Just exit the program.

[epoch1970]

Well of course on the internet you will find people having issues, with WiFi or anything else.
I don’t have much issues with WiFi using Raspbian on my 3Bs, never had IIRC. I don’t feel the urge to post “it works” all over the place...

Wireless is complicated, the environment (neighbors?) can influence its performance. And AP settings/quality, client settings, as well.

In case of problems I would check the client config against the official documentation, set the AP to factory defaults, and see what happens.

[GeorgeIoak]

I thought I would update this thread. I think we can rule out a power supply issue as the Pi hasn't had this issue for several days now. Here's the latest output:

Code: Select all

pi@OSPI:~ $ journalctl | grep carrier
Sep 12 07:42:01 OSPI dhcpcd[379]: eth0: waiting for carrier
Sep 12 07:42:01 OSPI dhcpcd[379]: wlan0: waiting for carrier
Sep 12 07:42:01 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 12 07:42:01 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 12 07:42:10 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 12 07:42:27 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 12 07:42:30 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 13 03:49:37 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 13 03:49:40 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 13 03:49:56 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 13 03:49:59 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 13 04:19:43 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 13 04:19:44 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 13 04:20:00 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 13 04:20:01 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 16 09:10:25 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 16 09:10:27 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 16 09:10:31 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 16 09:10:31 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 16 09:57:23 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 16 09:57:26 OSPI dhcpcd[379]: wlan0: carrier acquired

As you can see it's been over 4 days of up time now. The "self recovering WiFi drop outs" happened on the 12th and the 13th, then none for the 14th and 15th but they popped back up on the 16th. I'm not sure what's causing these or if they're normal but right now I haven't permanently lost WiFi but now that I post this I wouldn't be surprised if it happens again soon.

Do others see this carrier lost and acquired in their logs or is this a hint as to what my bigger problem is?

[GeorgeIoak]

Another update post. It "broke" again and this time I went to the Pi and issues a

Code: Select all

sudo service wpa_supplicant stop

and then waited before starting the service again. After that I checked the status and found this:

Code: Select all

● wpa_supplicant.service - WPA supplicant
   Loaded: loaded (/lib/systemd/system/wpa_supplicant.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2019-09-23 07:36:23 PDT; 2min 8s ago
 Main PID: 1059 (wpa_supplicant)
    Tasks: 1 (limit: 4915)
   CGroup: /system.slice/wpa_supplicant.service
           └─1059 /sbin/wpa_supplicant -u -s -O /run/wpa_supplicant

Sep 23 07:36:23 OSPI systemd[1]: Starting WPA supplicant...
Sep 23 07:36:23 OSPI systemd[1]: Started WPA supplicant.
Sep 23 07:36:23 OSPI wpa_supplicant[1059]: Successfully initialized wpa_supplicant

I was not able to ping yahoo.com so I used the onscreen WiFi status (which showed that every appeared to be fine even though it wasn't) to turn WiFi off. When I turned it back on to couldn't successfully scan and find any AP

This is what was left in the log:

Code: Select all

pi@OSPI:~ $ journalctl | grep carrier
Sep 12 07:42:01 OSPI dhcpcd[379]: eth0: waiting for carrier
Sep 12 07:42:01 OSPI dhcpcd[379]: wlan0: waiting for carrier
Sep 12 07:42:01 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 12 07:42:01 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 12 07:42:10 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 12 07:42:27 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 12 07:42:30 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 13 03:49:37 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 13 03:49:40 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 13 03:49:56 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 13 03:49:59 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 13 04:19:43 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 13 04:19:44 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 13 04:20:00 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 13 04:20:01 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 16 09:10:25 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 16 09:10:27 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 16 09:10:31 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 16 09:10:31 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 16 09:57:23 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 16 09:57:26 OSPI dhcpcd[379]: wlan0: carrier acquired
Sep 16 19:15:59 OSPI dhcpcd[379]: wlan0: carrier lost
Sep 16 19:16:00 OSPI dhcpcd[379]: wlan0: carrier acquired

So at this point I'm wondering how could the driver appear to be fine (because I can stop and start the service) but it is unable to scan and see any access points. This also means that it probably isn't an issue with my router because a normal scan will come back with at least 6 neighborhood access points.

[amcdonley]

You did set static ip in the Pi and dedicated ip in the router, correct?

Check the router log for events with the MAC address.

Did you try a stretch Os and don’t do an update? There may be some weird things from the 4.19 kernel.

[GeorgeIoak]

In /etc/dhcpcd.conf I have this:

Code: Select all

interface wlan0
static ip_address=192.168.10.230/24
static routers=192.168.10.1
static domain_name_servers=192.168.10.1 8.8.8.8

Other possible useful information:

Code: Select all

pi@OSPI:~ $ ip r | grep default
default via 192.168.10.1 dev wlan0 src 192.168.10.230 metric 303
pi@OSPI:~ $ sudo nano /etc/resolv.conf
pi@OSPI:~ $ cat /etc/resolv.conf
# Generated by resolvconf
nameserver 192.168.10.1
nameserver 8.8.8.8
nameserver fe80::a02:8eff:fe90:5fc%wlan0
pi@OSPI:~ $ hostname -I
192.168.10.230 2601:204:d400:8201:xxxx:xxxx:xxxx:xxxx

In my Orbi Router under LAN setup I have an Address reservation set for the Pi for 192.168.10.230 but I just noticed that the MAC address "used" in this reservation is different (probably from an older Pi I swapped out). That older MAC address was removed from the network and hasn't been powered up so "I don't think" this is an issue but I'll let you chime in before I make a change.

It looks like the router logs don't go back far enough so I may have to set up the router to email me the logs so I can gather more information.

Do you think having 3 nameserver settings in resolv.conf is a bad thing? Not sure where they came from other than the 2nd one is Google and I have no idea about that 3rd one.

[davidcoton]

So the Pi tries to connect to an address which the router thinks has a different Pi with a different MAC. Might work, but probably asking for trouble.
Don.t use static IPs unless you really have to. They cause a world of pain. Far better to let the router assign an address, but reserve a separate address for each device. That way it doesn't matter if you connect two Pis at once, each will get its own IP. You can take your Pis to another network without having to reconfigure. You don't have to remember which Pi has which address (unless you SSH or VNC via the address rather than by name).

[GeorgeIoak]

OK, I'll remove the static setting on the Pi and update the router to use the current MAC address. Then we'll see how long the Pi stays on the network.

Any comments on the multiple nameserver settings?

But, come to think of it, the real problem I'm having is that the Pi is not able to perform AP scanning so the trouble starts before any IP address assignments come into play. I'll still make changes since it sounds reasonable to change but this shouldn't have any impact on the problem I'm facing.