1

I have a few Pi's over here and all devices have the same issue:

When connected to a Wi-Fi network te PI is starting to cause issues with either accessibility from outside (ping, ssh, etc.) and also multicasting (not discovered anymore). This only happens after a while (15 - ... minutes).

Strange though is that when performing pings from the Raspberry itself (connected via HDMI) the connection to the internet is all ok. I can ping any website or internal address without any issues.

When I ping to the internal network address from the Pi (that is trying to access the Pi) it looks like the issue solves itself and the Pi is accessible from outside again ... for a while.

iwconfig:

lo        no wireless extensions.

wlan0     IEEE 802.11  ESSID:"MY_WIFI"
          Mode:Managed  Frequency:2.462 GHz  Access Point: 00:11:22:33:44:55
          Bit Rate=72.2 Mb/s   Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality=64/70  Signal level=-46 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:440  Invalid misc:0   Missed beacon:0

eth0      no wireless extensions.

ifconfig:

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.31  netmask 255.255.255.0  broadcast 192.168.178.255
        inet6 fe80::ba27:ebff:fec9:941  prefixlen 64  scopeid 0x20<link>
        ether ***********  txqueuelen 1000  (Ethernet)
        RX packets 22357  bytes 3949874 (3.7 MiB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 43586  bytes 12945370 (12.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

After weeks of trouble shooting I decided to ask the community for help.

1

This behavior is typical for problems with arp resolution. Have a look at this. When you initiate a connection from the raspi to remote hosts they also get its mac address. mac addresses are always cached. Look at the cache with:

~$ ip neighbour

On responses the cache should contain the mac address of the remote host otherwise not. The entries in the cache are deleted after a timeout, by default 5 min. If your raspi does not reply on arp requests the remote host cannot establish a connection.

If you ping a remote host it cached the mac address and if you immediately ping back from the remote host, it will get an answer. If you ping back after e.g. 6 min it will not get an answer. To explore this you have to use a network sniffer e.g. tcpdump or wireshark. I prefer tcpdump. Install it and trace for arp (with an example from my raspi):

pi@raspberrypi:~$ sudo apt install tcpdump
pi@raspberrypi:~$ sudo tcpdump -n arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:32:55.340871 ARP, Request who-has 192.168.10.112 (b8:27:eb:06:e8:8b) tell 192.168.10.2, length 46
11:32:55.340930 ARP, Reply 192.168.10.112 is-at b8:27:eb:06:e8:8b, length 28

If you do not get replies you have to look why ...

I have had this problem with a bridge that wasn't transparent enough (flood was off, has to be flood on).

  • Thanks for the clarification about arp and pointing out in that direction. Though I still don't see the solution to the problem. Sometimes I get replies from other ip-addresses in the network and sometimes not. – Gijs Jul 3 '18 at 14:59
  • @Gijs That is just the issue with the cached mac address! Sometimes you will get replies if it is in the cache, sometimes you will not if the cache has timed out for that mac address and it isn't in it anymore. – Ingo Jul 3 '18 at 19:40

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.