7

I have a small office network run with Unifi.

My main Windows workstation (on wired ethernet) is unable to ping one Raspberry Pi (WiFi) on my network (by IP or hostname):

> ping -t funipi.tsl
Pinging funipi.tsl [10.119.0.129] with 32 bytes of data:
Reply from 10.119.0.21: Destination host unreachable.
Request timed out.
Reply from 10.119.0.21: Destination host unreachable.
Request timed out.

Nor am I able to SSH or get any other connection to the Pi.

However other machines on the same network are able to ping/SSH into the Pi no problem.

I am also able to ping all the other machines on the network, including other Pis, from my main workstation without issue.

Then, if I SSH into the funipi.tsl (from a different workstation), the instant I start ping windows-workstation on the FuniPi, the Windows workstation's ping -t funipi.tsl starts working.

I went to lunch leaving both pings working away. Upon my return:

  • The Windows -> Pi ping was failing again (with same messages as above)
  • Pi -> Windows ping ("From test-pi.tsl (10.119.0.129) [...] Destination Host Unreachable")

Restarting the Pi -> Windows ping fixes the Windows -> Pi ping and other connections.

The only weirdness I'm seeing is that ping on the pi detects its own hostname incorrectly (uses the last hostname to use the same DHCP lease, the result of nslookup 10.119.0.129). However I'm not convinced this is a problem.

I wonder if it's a power saving feature turning on on the Pi, but I don't see why other machines on the same network would be able to see the Pi while my workstation cannot.

I saw some discussions about this possible being caused by an ARP issue, but I haven't been able to confirm that, mostly for lack of fully understanding ARP.

Thanks for the look.

Update

Looks like an ARP issue:

> arp -a 10.119.0.129 -v

Interface: 10.119.0.21 --- 0x19
  Internet Address      Physical Address      Type
  10.119.0.129          00-00-00-00-00-00     invalid


Interface: 0.0.0.0 --- 0xffffffff
  Internet Address      Physical Address      Type
  10.119.0.129          00-00-00-00-00-00     invalid

What could be causing this?

arp -d 10.119.0.129 doesn't seem to do anything.

After ping from FuniPi to windows-workstation, my arp table looks better:

> arp -a 10.119.0.129 -v

Interface: 10.119.0.21 --- 0x19
  Internet Address      Physical Address      Type
  10.119.0.129          b8-27-eb-11-92-83     dynamic


Interface: 0.0.0.0 --- 0xffffffff
  Internet Address      Physical Address      Type
  10.119.0.129          00-00-00-00-00-00     invalid
Cameron Tacklind
  • 535
  • 6
  • 13

2 Answers2

4

I would guess that the machine that can't reach the pi has the previous machine that had the dhcp lease in its arp cache, and that other machines on the network do not.

You can test this by running arp -na on the machine that can't reach the pi and look for the entry for the pi's ip address. Compare the ethernet address listed there to what ip addr on the pi shows.

Also, you can correct the problem with the command arp -d IP (replacing IP with the pi's IP address).

Normally the arp cache times out long before a dhcp server would reuse an ip address, so this shouldn't be a problem. Host arp caches use to be about 5 minutes, but some switches might retain arp cache for 4 hours. A ping from the pi might clear the stale arp entry in both the switch and host arp caches. Similarly, a gratuitous arp might also help here.

But probably the best solution would be to not reuse ip addresses in the dhcp server so quickly.

user10489
  • 1,001
  • 1
  • 6
  • 11
2

I saw some discussions about this possible being caused by an ARP issue, but I haven't been able to confirm that, mostly for lack of fully understanding ARP.

You already find some information at the answer of @user10489. I will give some additional details to understand the problem.

Devices on a link local ethernet network are addressed by worldwide unique MAC addresses (OSI layer 2). A device does not know the ip address of its neighbor. So it broadcast on the local link with the arp protocol:

~$ sudo tcpdump -n arp
20:36:46.199408 ARP, Request who-has 192.168.24.2 tell 192.168.24.65, length 28
20:36:46.199974 ARP, Reply 192.168.24.2 is-at 34:81:c4:fc:71:a9, length 46

It get an answer from the device with MAC address 34:81:c4:fc:71:a9 and can now be connected. For performance boost this request is cached in the ARP cache so it can be used with subsequent connections without always repeating the request. This request is initiated by the source device but the destination device caches also the source MAC. So it does not need to request for the ip address to answer.

~$ ip neigh show   # the arp cache
192.168.24.2 dev eth0 lladdr 34:81:c4:fc:71:a9 REACHABLE

The entry in both caches are triggered by every ethernet packet and timed out after 5 minutes by default.

Your problem now is that the windows-workstation does not get an arp reply from the RasPi (but other devices do). if you ping it from the RasPi then the MAC - ip mapping is also cached on the windows-workstation and you can ping the RasPi. If you try it after 6 min again it will fail, the cache entry has timed out. If you permanently ping the windows-workstation from the RasPi within 5 min the reverse connection should always work.

You have to look why the windows-workstation does not get an arp reply from the RasPi. I cannot help much about this because lack of detailed information about your local network (broadcast domain). Have a look at switches and bridges. I would have a focus on the Unifi.

Ingo
  • 42,961
  • 20
  • 87
  • 207