Zend certified PHP/Magento developer

Constant timeout between hosts connected to switch/router via Ethernet on a LAN

At this point I’m out of ideas so I thought I will ask for help. I’ve got 4 devices connected to my home router (Dasan H660GW). It is also an access point and an L2 switch like most other home routers.

So I’ve got 3 hosts connected via Ethernet:

  1. jjk-desktop (IP configured via DHCP, currently 192.168.55.101) – desktop PC (dual boot Win10/Linux)
  2. rpi-main (RaspberryPi, static IP 192.168.55.20)
  3. rpi-worker1 (RaspberryPi, static IP 192.168.55.30)

1 host connected via wifi:

  1. jjk-laptop (IP configured via DHCP, currently 192.168.55.100) – home laptop (Linux)

And finally my home router with IP of 192.168.55.1.

So here’s the issue: none of my devices connected via Ethernet can connect to each other – every request times out. But they can reach my laptop connected via wifi and vice versa – I can connect to each one from my laptop.

For example, trying to ping rpi-worker1 (192.168.55.30) from rpi-main (192.168.55.20) – this is just 7 pings but I’ve run them for 200+ and it’s 100% loss:

jjk@rpi-worker1:~ $ ping rpi-main -O
PING rpi-main (192.168.55.20) 56(84) bytes of data.
...
no answer yet for icmp_seq=7
^C
--- rpi-main ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7153ms

It looks exactly the same trying to ping from jjk-desktop to any rpi-main/rpi-worker1 or from rpi-main to rpi-worker1, etc.

Here’s an SSH attempt from jjk-desktop (192.168.55.101) to rpi-main (192.168.55.20):

jjk@jjk-desktop: ~
$ ssh 192.168.55.20                                                                                                                               
ssh: connect to host 192.168.55.20 port 22: Connection timed out
FAIL: 255

It’s the same when trying to SSH to rpi-worker1 (192.168.55.30). SSH’ing to jjk-laptop (192.168.55.100) works fine.

Last example – attempting a DNS query (rpi-main is also a DNS server):

jjk@jjk-desktop: ~
$ nslookup argo.jed.local rpi-main                                                                                                                
;; communications error to 192.168.55.20#53: timed out
;; communications error to 192.168.55.20#53: timed out
;; communications error to 192.168.55.20#53: timed out
;; no servers could be reached

Essentially every request between these 3 hosts connected via Ethernet times out.
Now I can see that all of them have ARP tables correctly set up (seemingly) and each IP maps to the correct MAC address:

jjk@jjk-desktop: ~
$ arp -en                                                                                                                                         
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.55.20            ether   e4:5f:01:98:c2:ae   C                     eno1
192.168.55.100           ether   e0:d4:e8:f2:0a:8f   C                     eno1
192.168.55.30            ether   e4:5f:01:d9:f4:fe   C                     eno1
192.168.55.1             ether   18:d0:71:fb:63:9f   C                     eno1

jjk@rpi-worker1:~ $ arp -en
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.55.100           ether   e0:d4:e8:f2:0a:8f   C                     eth0
192.168.55.1             ether   18:d0:71:fb:63:9f   C                     eth0
192.168.55.101           ether   e0:d5:5e:e6:a9:f1   C                     eth0
192.168.55.20            ether   e4:5f:01:98:c2:ae   C                     eth0

jjk@rpi-main:~ $ arp -en (I've cut out docker/k8s related crap)
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.55.100           ether   e0:d4:e8:f2:0a:8f   C                     eth0
192.168.55.1             ether   18:d0:71:fb:63:9f   C                     eth0
192.168.55.101           ether   e0:d5:5e:e6:a9:f1   C                     eth0
192.168.55.30            ether   e4:5f:01:d9:f4:fe   C                     eth0

JJKlaptop at ~ ❯ arp -en
Address                  HWtype  HWaddress           Flags Mask            Iface
192.168.55.30            ether   e4:5f:01:d9:f4:fe   C                     wlp1s0
192.168.55.20            ether   e4:5f:01:98:c2:ae   C                     wlp1s0
192.168.55.101           ether   e0:d5:5e:e6:a9:f1   C                     wlp1s0
192.168.55.1             ether   18:d0:71:fb:63:9f   C                     wlp1s0

Routes seem to be correctly set up on each of the devices as well:

ip route on jjk-desktop:
default via 192.168.55.1 dev eno1 proto dhcp src 192.168.55.101 metric 100
192.168.49.0/24 dev br-eaad61b9a668 proto kernel scope link src 192.168.49.1 linkdown
192.168.55.0/24 dev eno1 proto kernel scope link src 192.168.55.101 metric 100

ip route on jjk-laptop:
default via 192.168.55.1 dev wlp1s0 proto dhcp src 192.168.55.100 metric 600
192.168.49.0/24 dev br-41d5ad4a1d7d proto kernel scope link src 192.168.49.1 linkdown
192.168.55.0/24 dev wlp1s0 proto kernel scope link src 192.168.55.100 metric 600

ip route on rpi-worker1 (and it's essentially the same on rpi-main + a lot of docker/k8s stuff):
default via 192.168.55.1 dev eth0 src 192.168.55.30 metric 202
192.168.55.0/24 dev eth0 proto dhcp scope link src 192.168.55.30 metric 202

I’ve run tcpdump host on each of the hosts and it seems like the only things flowing are ARP requests (whenever I’m trying to SSH, ping, or w/e):

jjk@rpi-worker1:~ $ sudo tcpdump host 192.168.55.20
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
22:17:07.856650 ARP, Request who-has 192.168.55.30 tell rpi-main, length 46
22:17:07.856694 ARP, Reply 192.168.55.30 is-at e4:5f:01:d9:f4:fe (oui Unknown), length 28

This is how it looks on every Ethernet connected device, nothing else is ever showing up – in this example of tcpdump I’m pinging rpi-worker 1 from rpi-main.

TL;DR: Unable to achieve any connection between my Ethernet connected devices and I’m out of ideas as to what could be the cause, maybe someone has any suggestions.

I’m planning to buy a separate switch for these soon anyway and I suppose that will resolve the issue, but I’m still curious why this is happening right now. At this point I’m suspecting some issue with the home router itself.