System on LAN unreachable

Periphelion · 2011-08-29 22:31:43

I have several systems on my LAN, and as of late two of them tend to become mutually unreachable, specifically my desktop and laptop.

Both remain reachable by all other systems on the network, and in fact, a VM running on the desktop (with bridged networking, not NAT) is able to reach the laptop without issue. As such I've more or less ruled out any sort of hardware issues.

Doing a bit of digging with tshark, it would seem that the desktop receives packets from the laptop: pings and nmap scans go through without issue... However, no responses are ever sent.

When running tshark on the desktop and pinging from the laptop, the laptop receives no unicast traffic from the desktop. Now, for the strange part: What the laptop (and other systems on the network) receive is repeated ARP broadcasts from the desktop; it's requesting the MAC of an IP address in the Philippines. However, the LAN is confined to 192.168.0.0/24 and the laptop's (static) IP is 192.168.0.3.

Being that the desktop receives the laptop's packets, but not the inverse, I can only assume the problem lies entirely with the desktop. Yet, since it only occurs with the laptop's IP and I've never seen an issue even remotely similar to this with any other host, I tend to assume the laptop is somehow causing the desktop's connectivity problem.

I'm unfamiliar with networking at this level, and assumed that an entry placed in the ARP cache manually (via arp -s) would remedy the issue, but it didn't. Despite the permanent, known-good MAC being entered in the desktop's ARP cache, it still continues to request the MAC of a Filipino IP whenever trying to send network traffic to 192.168.0.3.

This issue recurs, and while it can be temporarily "fixed" by rebooting, it tends to present itself again after a few days of uptime. Changing the laptop's IP makes it reachable by the desktop, but the erroneous ARP broadcasts persist when trying to reach 192.168.0.3.

I'm curious as to why the ARP cache entry isn't being used, and frankly dumbfounded as to how 'ping 192.168.0.3' (or other network traffic to that IP) turns into ARP requests for an IP in the Philippines.

It's probably worth noting that when doing a manual 'arping 192.168.0.3' from the desktop, the proper IP is seen in the ARP broadcast, and as expected the appropriate MAC is returned.

Any help is appreciated.

fukawi2 · 2011-08-29 23:05:13

This sounds like an interesting one....!

What is this mystery IP Address in the Phillipines?

What is the output of `iptables-save` (Use [ code ] tags)

Have you tried changing switch ports? (long shot based on the info you've given, but can't hurt to try)

Periphelion · 2011-08-29 23:27:33

Nothing special:

# Generated by iptables-save v1.4.12 on Mon Aug 29 19:16:47 2011
*security
:INPUT ACCEPT [147923:105084657]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [175923:18661817]
COMMIT
# Completed on Mon Aug 29 19:16:47 2011
# Generated by iptables-save v1.4.12 on Mon Aug 29 19:16:47 2011
*nat
:PREROUTING ACCEPT [17972:1021939]
:INPUT ACCEPT [17972:1021939]
:OUTPUT ACCEPT [12783:847512]
:POSTROUTING ACCEPT [12783:847512]
COMMIT
# Completed on Mon Aug 29 19:16:47 2011
# Generated by iptables-save v1.4.12 on Mon Aug 29 19:16:47 2011
*raw
:PREROUTING ACCEPT [148501:105219570]
:OUTPUT ACCEPT [176509:18697683]
COMMIT
# Completed on Mon Aug 29 19:16:47 2011
# Generated by iptables-save v1.4.12 on Mon Aug 29 19:16:47 2011
*filter
:INPUT ACCEPT [181126:112170310]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [216328:21209206]
COMMIT
# Completed on Mon Aug 29 19:16:47 2011

I've tried multiple ports, yes. I used to run with eth0 and eth1 bonded (for failover) but stopped that when this issue came up. I've tried eth0 and eth1 separately to no avail.

The IP in question is 222.127.44.1, which I can't resolve to anything, have never seen before, and it has no odd Google results associated with it. Truly strange.

It's not a one-off anomaly, either. I did most of my testing on eth0, but when testing with eth1 the same IP was erroneously broadcast, despite a clean ARP cache for the interface.

fukawi2 · 2011-08-30 06:21:46

What about `ip route show`?

Periphelion · 2011-08-30 12:16:14

Similarly uninteresting:

default dev ppp0  scope link 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1 
206.248.154.120 dev ppp0  proto kernel  scope link  src 69.196.147.120

Just one route for the LAN and another for the PPPoE DSL connection.

mancino · 2011-08-30 12:41:01

i have a similar problem, i can see my card eth0 ip but when i ping my gateway is unreachable.
dhcpcd eth0
waiting from carrier and after timeout
i try with another network card but nothing.
Any idea?

fukawi2 · 2011-08-30 22:58:03

mancino wrote:

i have a similar problem, i can see my card eth0 ip but when i ping my gateway is unreachable.
dhcpcd eth0
waiting from carrier and after timeout
i try with another network card but nothing.
Any idea?

Not quite the same problem, please don't hi-jack threads.

Periphelion wrote:

Similarly uninteresting:
default dev ppp0  scope link 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1 
206.248.154.120 dev ppp0  proto kernel  scope link  src 69.196.147.120
Just one route for the LAN and another for the PPPoE DSL connection.

Well that's spectacularly confusing... I can't think of anything else at the moment, sorry
I'll post back if I do think of something.

mancino · 2011-08-31 11:17:17

I resolve, my cable line have broken maybe a little mouse!! Thx

Arch Linux

#1 2011-08-29 22:31:43

System on LAN unreachable

#2 2011-08-29 23:05:13

Re: System on LAN unreachable

#3 2011-08-29 23:27:33

Re: System on LAN unreachable

#4 2011-08-30 06:21:46

Re: System on LAN unreachable

#5 2011-08-30 12:16:14

Re: System on LAN unreachable

#6 2011-08-30 12:41:01

Re: System on LAN unreachable

#7 2011-08-30 22:58:03

Re: System on LAN unreachable

#8 2011-08-31 11:17:17

Re: System on LAN unreachable

Board footer