2

I have a raspberry pi that is connected to the network with DHCP. When I start it, I can ping it and connect to ssh through wifi. The issue is when I diconnect the device that I am using (my pc/android phone or other pi) from the local network and reconnect, I am un able to ping the pi or connect via ssh from that device. I need to do a ping from the pi to the device to be able to connect again.

This was not the case till few days ago.

Does anyone have a clue?

So to sum-up the issue: - A is connected to the pi through ssh - A is disconnected from the network and reconnected - A can no longer connect nor ping the pi - Pi can ping A (with a little delay in the beginning) - A can now ping and connect to the pi!

| improve this question | |
  • That's weird that it can connect after a ping from the pi. Is this consistent behavior, as in A will not be able to ping and connect to the pi for as long as you wait to ping from the pi? Also what are the ip addresses for each device or are you connecting by hostname? Also, when A can't reach the pi, can other devices reach the pi or is it only that device that was connected and now can't reconnect? Last, do both devices still show up as connected to your router the whole time? Possibly your router is misconfigured and is assigning new IP's to your devices each time and confusing itself. – T. M. Dec 16 '18 at 23:44
  • Thanks for your answer. Yes this is a consistent behaviour! the pi adress is 192.168.1.35 and for examp^le my laptop is 192.168.1.54. Also, I use fing on my android phone whith which I can see all my devices except the pi unless I ping my phone from the pi! Also, when A can't reach the pi, the devices that have been pinged can access thepi. And finally, all the devices show on the router, including the pi. – ka3lous Dec 17 '18 at 21:12
  • I'm going to agree with Ingo on an ARP issue and speculate its a bug in your router. Have you tried power cycling your router? It's amazing how often consumer routers need that. Then try the things in Ingo's answer. – T. M. Dec 17 '18 at 23:55
1

This behavior is typical seen by problems with arp resolution. I don't know if it is your problem but it is worth to look at it. Let me explain.

On a local area network without router (broadcast domain) devices broadcast for ip addresses of other devices they want to connect to with arp requests, typical seen with sudo tcpdump -n arp:

ARP, Request who-has 192.168.10.4 tell 192.168.10.113, length 28
ARP, Reply 192.168.10.4 is-at 00:0a:e4:02:04:30, length 46

Now the package can go to mac address 00:0a:e4:02:04:30 (destination address of the ethernet frame, that contains the ip frame, that contains the tcp frame ...). To improve performance both devices will cache the mac address from the other side in its arp cache for 5 minutes by default so only every 5 minutes there is a arp request sent for refresh. If the RasPi has a problem and does not reply then the other device cannot connect - no ping. But when the RasPi sends a request (ping) it gets an arp reply and both devices caches the opposed mac address. The other device is able to ping the RasPi - just 5 minutes long. After disconnecting the interface it gets down and its arp cache is cleared so it also cannot ping the RasPi after reconnect.

So first test to evaluate this: from the RasPi ping the other device wait 6 minutes and try to ping the RasPi. Inspect the arp caches with:

~$ ip neighbor show

And of course you can simply look with tcpdump. If you find that the RasPi does not Reply then you know the reason but it is a bit difficult to say why it fails without deeper knowledge of the network setting. Maybe a missconfigured firewall or wpa_supplicant, interfaces with two mac addresses, buggy interface? Try to set the problematic interface to promiscuous mode and check again. Then it will accept any packages from the network.

rpi ~$ sudo ip link set wlan0 promisc on|off

But this should not be used as a solution if it works. You have to fix the cause.

| improve this answer | |
  • Hello, thanks for your answer. The problem was effectively due to ARP issues. I used wireshark to analyse the traffic from my laptop and confirmed that the arp requests never get answers. So I checked the configuration on the pi for all the /proc/sys/net/ipv4/conf/wlan0/arp_* files and everything was ok (0 values). So I decided to restart the router, and now it seems to work. – ka3lous Dec 18 '18 at 20:20
  • @ka3lous Glad to help you :-) And thank you for feedback what was going wrong. If my answer helped you it would be nice if could accept it by clicking the tick on the left side. This would finish the question and show others it has an answer and do not try to help you for nothing ... – Ingo Dec 18 '18 at 20: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.