Pi 3B+ can not be seen via Wifi but can see web

[bill-orange]

Using the latest updated Raspien release with my shiny new B+, I have run into a problem. After a random number of hours of operation, the PI B+ is not reachable or pingable from other network computers. This is especially weird since, the offending PI can see other devices in the network and can see the internet. My other PIs and PCs do not have this problem. If I disconnect and reconnect WiFi the problem is resolved for a while. I have tried reducing processor and memory speed. It has made no difference. My power supplies meet mfg. recommendations.

I suspect that this issue may be some sort of adverse interaction with my UMBEE TimeWarner router. However, if this was exclusively a router problem, I would expect my PI Model Bs and PI zero Ws to also have this problem. I am running Raspian on two PI B+. Both have this problem.

Can anyone reproduce this problem? I found one other user on another forum with identical symptoms but that still leaves this as a pretty rare event.

[pelwell]

[ So this is a 3B+, and the problem is seen over WiFi? If so, please make the issue title more precise. ]

Are you saying that even while the Pi can ping out (and get replies, presumably), other devices (even ones it has pinged) can't ping it?

[bill-orange]

Will do. I will edit the post title once I am on a PC and not my phone.

Yes, this is a 3B+. You restated my problem correctly. It is very strange. As well as not being able to ping the offending PIs, I can not connect with VNC or see an apache2 default web page. All the while the PIs can ping other devices and show web pages such as CNN.com.

[JamesH65]

Fixed the title.

Note that the Pi3B+ has a new Wifi chip, although the kernel driver is the same, the underlying firmware will be different - so could well be a weird interaction specific to the new chip.

[P33M]

How are you resolving the Pi's IP? Hostname?

What happens if you try to ping the (known) IP address instead of trying to resolve the host?

[bill-orange]

I am pinging the IP address.

Sent from my iPhone

On Apr 20, 2018, at 8:39 AM, P33M [email protected] wrote:

How are you resolving the Pi's IP? Hostname?

What happens if you try to ping the (known) IP address instead of trying to resolve the host?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[pelwell]

This is baffling.

1. Can you try continuously pinging the Pi from another device to see if that keeps the "link" up?
2. If 1 is successful, try pinging from a third device (if you have one) after what would have been long enough to expect a failure.
3. If 1 isn't successful (and you have a third device) try leaving both pinging simultaneously and see if they fail at the same time.

[JamesH65]

Bit of a long shot, but is the IP address on the Pi changing for some reason? Perhaps the interface going down and coming back with a different address?

On 20 April 2018 at 16:52, Phil Elwell [email protected] wrote:

This is baffling.

1. Can you try continuously pinging the Pi from another device to see if that keeps the "link" up?
2. If 1 is successful, try pinging from a third device (if you have one) after what would have been long enough to expect a failure.
3. If 1 isn't successful (and you have a third device) try leaving both pinging simultaneously and see if they fail at the same time.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/linux/issues/2522#issuecomment-383140171, or mute the thread https://github.com/notifications/unsubscribe-auth/ADqrHXe4iQ2DEJihZH-iK3uJUUeS5t7Tks5tqgRTgaJpZM4TdpCj .

-- James Hughes Principal Software Engineer, Raspberry Pi (Trading) Ltd

[bill-orange]

I can try the two device test. Regarding test one, I wrote a shell script that pings the offending PI three times every five minutes and saves the result along with the time in a log file. When the failure happens the log entry goes from ‘3’ to ‘0’. After resetting the WiFi on the offending PI the log starts recording ‘3’ again.

I should be able to run the script on a spare PI Zero W and get two machines pinging away at it.

[bill-orange]

James, good thought, but the IP address is not changing.

[mkreisl]

@bill-orange Having sometimes same problem here (@JamesH65 , @pelwell - don't panic, its not a Pi3B+ issue here :grin: ) Randomly I can not ping a device (it's not only a Pi, happens with all WLAN clients). So, going to the not responding device and ping from there the other other client - and voila, ping is working again. Probably WLAN router does not handle ARP packets correctly, but I can live with that.

Maybe you have same issue

[bill-orange]

Well, I have to admit that your problem is similar. In my situation the only way to restore ping-ability is to disconnect and reconnect WiFi or reboot. Even forcing a DHCP renewal does not do the trick. Also, in my situation only the PI 3B+ are affected. Bs and Zero Ws work fine.

Running this script every hour or so with chron keeps the PI 3B+ visiable

#!/bin/bash
sudo ifconfig wlan0 down
sudo ifconfig wlan0 up

Running this script every 5 minutes with chron check visibility.

#!/bin/bash
echo 'execute pinger script'
echo
count=$(ping -c 3 _address_of_3B+_| grep icmp | grep bytes | wc -l)
{
	echo $(date +%H:%M) ' Result of PING: ' $count
} 2>&1 | tee -a /home/pi/Public/logfile.log
exit

I agree that this does have something to do with ARP. I can not think of anything else that would cause a one directional problem.

[rodizio1]

I'd try looking at the traffic with wireshark/tshark/tcpdump and check if you can see ARP requests and replies.

Could this be power-saving/DTIM related maybe?

[bill-orange]

I will try looking at the ARPs. I would be surprised if this is a power saver issue since it’s occurance is random.

It also does not appear, to my surprise, to relate to the new Broadcom chip.

I plugged in a spare Pi Zero W. It ran fine no problem. I did an update-upgrade and installed apache2 and it started exhibiting the problem. So, it’s either something to do with the 3-13-18 release of Raspian or something to do with Apach2. I stopped Apache2 with sysctrl and I am waiting to see if the problem recurres.

Bill

[bill-orange]

I completely uninstalled apache2 after the problem reoccurred with Apache stopped. I am waiting to see if the problem reoccurs.

@rodizio1 I loaded Wireshark on a computer connected via Ethernet and set the filter in Wireshark to ARP. Is that correct? What exactly am I looking for. Wow, that thing sure shows a lot of packets flowing. No wonder the router light continuously flickers.

[bill-orange]

The problem still reoccurred with apach2 completely uninstalled. This was the result I expected but it’s good to be sure.

This narrows the problem down to the 3-13-18 Raspian release. Hardware, power and apache2 are eliminated.

[JamesH65]

Just to eliminate it, can you confirm there are no voltage low warnings in dmesg or that you do not see the lightning bolt symbol at top tight of a connected display?

[bill-orange]

No lightening bolts and no syslog or dmesg entries suggesting a power problem. I am using a 2.5A supply.

[JamesH65]

Hmm, bit of a loss at what to suggest. It is most odd, and clearly not common or we would be inundated with reports.

[JamesH65]

Did you try a different router?

[bill-orange]

Yes, It did seem to increase the time to failure, but since this is a somewhat random, the increase could be a red herring.

In any event, even if the router was partially the culprit, the problem started with 3-13-18 and there are plenty of UBEE routers out there. I would not expect Raspian 3-13-18 to have router dependent difficulties.

[Trotter73]

Hi,

I was seeing similar things after I changed Router, my Pis could ping however I could not ping the Pis, for me IPV6 seemed to be the culprit. I disabled IPV6 completely by adding ipv6.disable=1 to cmdline.txt since then no issues...

The router I was seeing issues with was a BT HH6

Worth a go as its easy to trial....

[vrodic]

Probably related to this forum post https://www.raspberrypi.org/forums/viewtopic.php?t=32398

"Wifi ARP requests lost" - lists a possible workaround from

davidasailor26

For anyone that comes across this problem in the future: I still have no effective fix. For now, I'm working around it by adding a cron job to another host I have on the same subnet. Basically this cron job sends a broadcast ARP request to the Pi each minute. If no response is received, the job sends a deauthenticate packet to the Pi. The deauthenticate forces the Pi to reassociate with the AP, which takes about 2 seconds and fixes the issue. This does require that the other host have a wireless card capable of injecting raw packets. The script for the cron job is: Code: Select all

I will reply with any further breakthroughs I have. if ! /sbin/arping -b -f -c 5 -I em1 [IP Addr of Pi] > /dev/null ; then /sbin/aireplay-ng -0 1 -a [AP BSSID] -c [MAC Addr of Pi] wlan0 > /dev/null ; /bin/date >> /var/log/fixPi ; fi

and to these bugs at least

https://github.com/raspberrypi/linux/issues/2677

https://github.com/raspberrypi/linux/issues/2732

[scyto]

I have same issue on both a pi4 and pi zero. I took the card from the pi4 and put it in the pi zero. I only seem to have the issue on 2.4ghz networks When it happens if i have both wlan0 and eth0 connected both stop responding to traffic. I noted eventually my pi was going off line when the DHCP lease expired (i had short lease of 34 mins). I have a Windows Server 2019 DHCP server. As the pi is up a pole i can't connect with monitor and keyboard to see if it is still routing traffic externally from it or not.

I have increased the lease time to see if the issue goes away or just happens on the new lease expiry of 1 day.

--edit-- yes my symptoms were directly related to DHCP expiration period (lease time was 31 minutes). i don't have time to troubleshoot further so just manually configured the IP on the PI to avoid the issue entirely. I hope this might help someone else.

[dasl-]

@bill-orange did you ever solve this problem? I have basically the same issue you have. Addressed in more detail here: https://www.raspberrypi.org/forums/viewtopic.php?t=218167#p1719192

I have been unable to solve the problem so far.

[bill-orange]

Not in any satisfactory way. I have my PIs set up to reboot nightly. I switched routers. My WiFi network is less congested. I am running the latest Raspian. Taken all together, the problem is minimal.

Hardly a satisfying solution, without a solid known cause.

[scyto]

For me the fix was to hardcode a true static* IP address on the pi, after that i never had issue again after my previous post; i am convinced there is an issue with how the pi does dhcp acks to offers that some APs don't like - i literally saw the AP dropping the packets because. My thesis is because they were not unicast acks (i was sniffing both sides of the internal AP interface) and that this only occurred on DHCP lease renew, not initial DHCP by the pi - thats the behaviour i saw.

(* = not a dhcp reservation, my pet peeve is folks who say a dhcp reservation is a static IP, it isn't, though i know everyone in linux land calls it that these days, i am too old and grumpy and remember when it was never called that ;-) )

[dasl-]

I was able to do some wireshark packet captures to get some more information. I am still stumped, but maybe this information will be helpful.

My network setup:

router: 192.168.1.1 raspberry pi: 192.168.1.6 laptop: 192.168.1.5 phone: 192.168.1.4

Problem description

I think my problem is basically the same as that in the original poster's description.

The pi is connected to the internet via wifi.

After a period of time (days to weeks), I am unable to access the pi from any computer on my network:

• I am unable to ssh onto the pi,
• web pages hosted on the pi are inaccessible

The output of arp -a on my laptop during this issue might look like: ? (192.168.1.6) at (incomplete) on en0 ifscope [ethernet]

If I hook up a keyboard and monitor to the pi during this issue, I will see that the pi appears to be working fine. Nothing in dmesg or /var/log/messages etc. The output of ip addr showon the pi will look like this. Furthermore, the pi is able to access the network. It can hit external websites, such as google.com, and it can ping hosts on my network. If I ping from the pi to my laptop, then suddenly my laptop is able to access the pi again.

That is, after running ping 192.168.1.5 on the pi, my laptop can ssh onto the pi and hit webpages hosted on the pi. My phone still will not be able to access the pi though. But after the pi pings my phone, my phone will be able to access web pages on the pi also.

After doing this ping from pi -> laptop, the arp -a entry on my laptop for the pi is "fixed", no longer incomplete.

wireshark captures

capture pair 1

Here is a pair of packet captures I took on the pi and my laptop simultaneously during one of the periods when this problem was occurring.

capture from pi

Here's the output of running sudo tshark -i wlan0 -f arp -w tshark_sync.out on the pi:

As we can see, there are a couple of arp requests and responses from the pi (192.168.1.6) to the router (192.168.1.1).

capture from laptop

At the same time, I ran a packet capture on my laptop: sudo tshark -i en0 -f arp -w tshark_sync.out:

As we can see, there are a few arp request broadcasts for the pi's IP address (192.168.1.6) that are coming from my phone (192.168.1.4) as it tries to hit the web page hosted on the pi.

So this is interesting: the packet capture on my laptop saw the arp request broadcast from my phone, but the packet capture running simultaneously on the pi did not see this arp request broadcast. It's as if the pi was ignoring / not receiving the arp broadcast request??

capture pair 2

Next, I rebooted the pi to "fix" the messed up network on it (it will likely have issues again within a few days to weeks).

capture from pi

Here's the output of running sudo tshark -i wlan0 -f arp -w tshark_sync.out on the pi:

As we can see, the pi (192.168.1.6) received an arp request broadcast from my phone (192.168.1.4). The pi responded properly to this arp request.

capture from laptop

At the same time, I ran a packet capture on my laptop: sudo tshark -i en0 -f arp -w tshark_sync.out:

Again, we can see my laptop saw the arp request broadcast from my phone. In this example though, everything worked properly because the pi had been recently rebooted.

conclusion

So I am still confused about what is going on here. It seems like the wifi on the pi stops receiving broadcast messages after some random amount of time. I am not sure how to debug this further.

[pelwell]

Disabling power saving might help - "sudo iwconfig wlan0 power off" will do that. Note that this setting does not persist across a reboot - appending it to /etc/rc.local will cause it to run after every reboot:

...
iwconfig wlan0 power off
exit 0

(sudo is not required because /etc/rc.local is run as root).

You can check the status of power saving at any time with iwconfig wlan0:

pi@raspberrypi:~$ iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"Pi Towers"
...
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=66/70  Signal level=-44 dBm
...

[dasl-]

Thanks, I will try this and report in a few weeks if it seems to have helped.

I thought power management was already disabled though? Based on some random things I was googling: https://www.raspberrypi.org/forums/viewtopic.php?t=194619 And the output in dmesg:

pi@pifi:~ $ dmesg -T | grep -i brcm
[Tue Sep 15 00:56:34 2020] brcmfmac: F1 signature read @0x18000000=0x15264345
[Tue Sep 15 00:56:34 2020] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[Tue Sep 15 00:56:34 2020] usbcore: registered new interface driver brcmfmac
[Tue Sep 15 00:56:35 2020] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[Tue Sep 15 00:56:35 2020] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Mar  2 2020 23:30:41 version 7.45.202 (r724630 CY) FWID 01-72f6ece2
[Tue Sep 15 00:56:38 2020] brcmfmac: power management disabled

Although sure enough, after running sudo iwconfig wlan0 power off, the output of iwconfig wlan0 changes from Power Management:on to Power Management:off.

[max17048]

I thought power management was already disabled though? Based on some random things I was googling: https://www.raspberrypi.org/forums/viewtopic.php?t=194619

Tx, thats also my knowledge. But I have to run the rc.local-workaround (on 3B).

BTW, maybe iwconfig runs out of support in a couple of years. Use:

iw dev wlan0 set power_save off  # in rc.local to set and
iw dev wlan0 get power_save      # to check -> Power save: off