lime-packages Default anygw route working intermittently via cable

Observed when using lime-proto-anygw on top of OpenWrt 24.10.

First reported by Gothos @a-gave in the mailing list:

I'm already using it with libremesh-2024.1-ow24.10.1-mini and I noticed that anygw is working normally for devices connected via wifi, but works intermittently for client devices connected via cable, for which the fastest thing was to set gateways and routes statically.

Using a combination of 4 router (TP-Link WDR3600 swconfig, TP-Link WR841N v13 swconfig, YouHua WR1200JS DSA, PlasmaCloud PA1200 DSA) I set up a few scenarios and run ping 10.13.0.1 (the IP they all have in common due to lime-proto-anygw, and the 13 is calculated based on the default SSID LibreMesh.org) from my laptop while being connected via ethernet.

The router where my laptop is connected is indicated with *, the other routers connected to this one are indicated with ·. A packet loss of 0% is the good ideal situation.

TP-Link WDR3600	TP-Link WR841N v13	YouHua WR1200JS DSA	PlasmaCloud PA1200	Packet loss
*				0%
	*			0%
		*		0%
			*	0%
*	·	·	·	33%
·	*	·	·	37%
·	·	*	·	28% with dupes
*	·			0%
*		·		29%
*			·	28%
·	*			0%
	*	.		20%
	*		·	18%
·		*		23% with dupes
	·	*		15% with dupes
		*	·	95%

I attach the Wireshark PCAP capture of my ethernet adapter when my laptop was connected to a LAN port of a YouHua WR1200JS with only OpenWrt 24.10, lime-proto-anygw and the dependencies of lime-proto-anygw (kmod-nft-bridge liblua5.1.5 libuci-lua libiwinfo-lua lua luci-lib-ip luci-lib-nixio luci-lib-jsonc lime-system kmod-macvlan iputils-ping shared-state shared-state-dnsmasq_hosts shared-state-dnsmasq_leases) that was connected, via another ethernet cable, from its LAN port to the LAN port of a PlasmaCloud PA1200, also with only OpenWrt 24.10 and lime-proto-anygw.

202506-anygw_testing.zip

Observing more closely, we can see that every 5 minutes the ping works again, for a variable number of seconds, and then it stops again.

ping 10.13.0.1
PING 10.13.0.1 (10.13.0.1) 56(84) bytes of data.
64 bytes from 10.13.0.1: icmp_seq=397 ttl=64 time=0.923 ms
64 bytes from 10.13.0.1: icmp_seq=697 ttl=64 time=0.987 ms
64 bytes from 10.13.0.1: icmp_seq=997 ttl=64 time=0.940 ms
64 bytes from 10.13.0.1: icmp_seq=998 ttl=64 time=0.890 ms
64 bytes from 10.13.0.1: icmp_seq=999 ttl=64 time=0.857 ms
64 bytes from 10.13.0.1: icmp_seq=1000 ttl=64 time=0.860 ms
64 bytes from 10.13.0.1: icmp_seq=1001 ttl=64 time=0.863 ms
64 bytes from 10.13.0.1: icmp_seq=1002 ttl=64 time=0.818 ms
64 bytes from 10.13.0.1: icmp_seq=1003 ttl=64 time=0.869 ms
64 bytes from 10.13.0.1: icmp_seq=1004 ttl=64 time=0.803 ms
64 bytes from 10.13.0.1: icmp_seq=1005 ttl=64 time=0.850 ms
64 bytes from 10.13.0.1: icmp_seq=1006 ttl=64 time=0.888 ms
64 bytes from 10.13.0.1: icmp_seq=1007 ttl=64 time=0.831 ms
64 bytes from 10.13.0.1: icmp_seq=1008 ttl=64 time=0.923 ms
64 bytes from 10.13.0.1: icmp_seq=1009 ttl=64 time=0.986 ms
64 bytes from 10.13.0.1: icmp_seq=1010 ttl=64 time=0.841 ms
64 bytes from 10.13.0.1: icmp_seq=1011 ttl=64 time=0.803 ms
64 bytes from 10.13.0.1: icmp_seq=1012 ttl=64 time=0.762 ms
64 bytes from 10.13.0.1: icmp_seq=1013 ttl=64 time=0.828 ms
64 bytes from 10.13.0.1: icmp_seq=1014 ttl=64 time=0.825 ms
64 bytes from 10.13.0.1: icmp_seq=1015 ttl=64 time=0.798 ms
64 bytes from 10.13.0.1: icmp_seq=1297 ttl=64 time=1.04 ms
64 bytes from 10.13.0.1: icmp_seq=1298 ttl=64 time=0.881 ms
64 bytes from 10.13.0.1: icmp_seq=1299 ttl=64 time=0.861 ms
64 bytes from 10.13.0.1: icmp_seq=1300 ttl=64 time=0.842 ms
[...]

I tested with a 100 mbps USB adapter (instead than my usual 1 gbps USB adapter) and I can confirm that it was not due to the ethernet adapter:

--- 10.13.0.1 ping statistics ---
12508 packets transmitted, 1704 received, 86.3767% packet loss, time 12808699ms
rtt min/avg/max/mdev = 0.440/0.707/0.913/0.062 ms

Jun 20 '25 14:06 ilario

More info from the scenario described below the table in the first comment:

Nothing can be seen in logread at the times when the ping starts/stops working.

arping 10.13.0.1 always shows the first pair of answers (each time you get one answer from each router) but then just shows some answers every some time:

arping -I enp0s20u1 10.13.0.1
ARPING 10.13.0.1 from 10.13.252.150 enp0s20u1
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.147ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.169ms
[some time passed]
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  985.940ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  986.000ms
[some time passed]
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  627.461ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  627.519ms
[some time passed]
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.334ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.289ms
[...long and nice sequence of uninterrupted working answers being received one by one, likely only one router was answering here...]
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.246ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.258ms
[some time passed]
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  346.809ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  346.897ms
[some time passed]
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  347.817ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  347.907ms
^CSent 543 probes (1 broadcast(s))
Received 66 response(s)

Using the option -b keep on broadcasting, do not unicast results in a nice output with both routers aswering each time:

arping -I enp0s20u1 -b 10.13.0.1
ARPING 10.13.0.1 from 10.13.252.150 enp0s20u1
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.236ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.274ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.297ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.360ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.207ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.278ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.238ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.326ms
^CSent 4 probes (4 broadcast(s))
Received 8 response(s)

The first of the two answers (so the one from the YouHua WR1200JS, I suppose), usually contains some "trailer" padding content 2 bytes long, "91 65" in hexadecimal. You can see it in the PCAP file attached to the first comment.

Logging it to the router via its AP, installing tcpdump-mini and using it, I could see in lan4 and in br-lan only the few ARP packets that actually receive an answer. The ones that do not, don't even reach lan4 or br-lan. When using arping, it looks like this on the laptop:

arping -I enp0s20u1 10.13.0.1 
ARPING 10.13.0.1 from 10.13.252.150 enp0s20u1
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.165ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.193ms
^CSent 25 probes (1 broadcast(s))
Received 2 response(s)

and like this on the YouHua WR1200JS:

tcpdump -i lan4
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on lan4, link-type EN10MB (Ethernet), snapshot length 262144 bytes
08:20:17.731719 ARP, Request who-has anygw (Broadcast) tell 10.13.252.150, length 46
08:20:17.732095 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel

even when using tcpdump on the DSA conduit interface eth0 (I hope I got the naming right), it does not show the few packets per second you would expect while running arping.

Jun 21 '25 05:06 ilario

My guess is that it has something to do with the switch seeing the same mac address (the anygw mac address) on the multiple ports. One of them would be the port to the router itself. Upon receiving a frame from the anygw mac on one port, it wouldn't forward frames destined to the anygw mac to other ports anymore. The 5 minutes time intervals could be the aging time of the entrys in the switch's forwarding table.

I wonder what the second switch (the one from the PlasmaCloud) would do, when it receives a unicast frame destined to the anygw mac address, while also having the anygw address in the forwarding table associated with the port it just received the frame on? Does it drop the frame?

Could you install bridge-utils on both devices and compare the output of bridge fdb of both routers before pinging for the first time vs after pinging, when it has stopped working? Maybe this gives a clue.

Jun 22 '25 19:06 pony1k

Thanks @pony1k !!

Could you install bridge-utils on both devices

I found that command in ip-bridge, bridge-utils did not have it :) Compiled and installed :)

compare the output of bridge fdb of both routers before pinging for the first time vs after pinging, when it has stopped working?

Amazing, I didn't even know that the command bridge existed!

Scenario: YouHua WR1200JS with OpenWrt 24.10 and lime-proto-anygw connected LAN-LAN with a cable to a PlasmaCloud PA1200 with OpenWrt 24.10 and lime-proto-anygw. My laptop is connected only to YouHua's AP.

YouHua WR1200JS # bridge fdb
33:33:00:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
33:33:ff:eb:7e:ac dev eth0 self permanent
33:33:00:00:00:02 dev eth0 self permanent
33:33:ff:00:00:00 dev eth0 self permanent
d4:5f:25:eb:7e:ad dev wan vlan 1 master br-lan permanent
d4:5f:25:eb:7e:ad dev wan master br-lan permanent
33:33:00:00:00:01 dev wan self permanent
33:33:00:00:00:02 dev wan self permanent
01:00:5e:00:00:01 dev wan self permanent
4c:13:65:00:0f:80 dev lan1 master br-lan 
aa:aa:aa:0d:fe:aa dev lan1 master br-lan 
d4:5f:25:eb:7e:ac dev lan1 vlan 1 master br-lan permanent
d4:5f:25:eb:7e:ac dev lan1 master br-lan permanent
4c:13:65:00:0f:80 dev lan1 self 
aa:aa:aa:0d:fe:aa dev lan1 self 
aa:aa:aa:0d:fe:aa dev br-lan self permanent
33:33:00:00:00:01 dev br-lan self permanent
33:33:00:00:00:02 dev br-lan self permanent
01:00:5e:00:00:01 dev br-lan self permanent
33:33:ff:eb:7e:ac dev br-lan self permanent
33:33:ff:00:00:01 dev br-lan self permanent
33:33:ff:0d:fe:aa dev br-lan self permanent
33:33:ff:00:00:00 dev br-lan self permanent
33:33:00:00:00:01 dev anygw self permanent
33:33:00:00:00:02 dev anygw self permanent
01:00:5e:00:00:01 dev anygw self permanent
33:33:ff:00:00:01 dev anygw self permanent
33:33:ff:0d:fe:aa dev anygw self permanent
33:33:ff:00:00:00 dev anygw self permanent
33:33:00:00:00:01 dev wlan0-ap self permanent
33:33:00:00:00:02 dev wlan0-ap self permanent
01:00:5e:00:00:01 dev wlan0-ap self permanent
d6:5f:25:eb:7e:ac dev wlan0-apname vlan 1 master br-lan permanent
d6:5f:25:eb:7e:ac dev wlan0-apname master br-lan permanent
01:00:5e:00:00:01 dev wlan0-apname self permanent
d4:5f:25:eb:7e:ae dev wlan1-ap vlan 1 master br-lan permanent
d4:5f:25:eb:7e:ae dev wlan1-ap master br-lan permanent
33:33:00:00:00:01 dev wlan1-ap self permanent
33:33:00:00:00:02 dev wlan1-ap self permanent
01:00:5e:00:00:01 dev wlan1-ap self permanent
33:33:00:00:00:01 dev wlan0-mesh self permanent
33:33:00:00:00:02 dev wlan0-mesh self permanent
01:00:5e:00:00:01 dev wlan0-mesh self permanent
33:33:ff:eb:7e:ac dev wlan0-mesh self permanent
33:33:ff:00:00:00 dev wlan0-mesh self permanent
e8:b1:fc:d2:8c:2d dev wlan1-apname offload master br-lan 
d6:5f:25:eb:7e:ae dev wlan1-apname vlan 1 master br-lan permanent
d6:5f:25:eb:7e:ae dev wlan1-apname master br-lan permanent
33:33:00:00:00:01 dev wlan1-apname self permanent
33:33:00:00:00:02 dev wlan1-apname self permanent
01:00:5e:00:00:01 dev wlan1-apname self permanent
33:33:00:00:00:01 dev wlan1-mesh self permanent
33:33:00:00:00:02 dev wlan1-mesh self permanent
01:00:5e:00:00:01 dev wlan1-mesh self permanent
33:33:ff:eb:7e:ae dev wlan1-mesh self permanent
33:33:ff:00:00:00 dev wlan1-mesh self permanent

PlasmaCloud PA1200 # bridge fdb
4c:13:65:00:0f:81 dev eth0 self permanent
33:33:00:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
33:33:00:00:00:02 dev eth0 self permanent
33:33:ff:00:0f:80 dev eth0 self permanent
33:33:ff:00:00:00 dev eth0 self permanent
4c:13:65:00:0f:81 dev ethernet2 vlan 1 master br-lan permanent
4c:13:65:00:0f:81 dev ethernet2 master br-lan permanent
d4:5f:25:eb:7e:ac dev ethernet1 master br-lan 
e8:b1:fc:d2:8c:2d dev ethernet1 master br-lan 
aa:aa:aa:0d:fe:aa dev ethernet1 master br-lan 
4c:13:65:00:0f:80 dev ethernet1 vlan 1 master br-lan permanent
4c:13:65:00:0f:80 dev ethernet1 master br-lan permanent
aa:aa:aa:0d:fe:aa dev ethernet1 vlan 1 self 
d4:5f:25:eb:7e:ac dev ethernet1 vlan 1 self 
e8:b1:fc:d2:8c:2d dev ethernet1 vlan 1 self 
aa:aa:aa:0d:fe:aa dev br-lan self permanent
33:33:00:00:00:01 dev br-lan self permanent
33:33:00:00:00:02 dev br-lan self permanent
01:00:5e:00:00:01 dev br-lan self permanent
33:33:ff:00:0f:80 dev br-lan self permanent
33:33:ff:00:00:01 dev br-lan self permanent
33:33:ff:0d:fe:aa dev br-lan self permanent
33:33:ff:00:00:00 dev br-lan self permanent
33:33:00:00:00:01 dev anygw self permanent
33:33:00:00:00:02 dev anygw self permanent
01:00:5e:00:00:01 dev anygw self permanent
33:33:ff:00:00:01 dev anygw self permanent
33:33:ff:0d:fe:aa dev anygw self permanent
33:33:ff:00:00:00 dev anygw self permanent
4c:13:65:00:0f:88 dev wlan1-ap vlan 1 master br-lan permanent
4c:13:65:00:0f:88 dev wlan1-ap master br-lan permanent
33:33:00:00:00:01 dev wlan1-ap self permanent
33:33:00:00:00:02 dev wlan1-ap self permanent
01:00:5e:00:00:01 dev wlan1-ap self permanent
4e:13:65:00:0f:88 dev wlan1-apname vlan 1 master br-lan permanent
4e:13:65:00:0f:88 dev wlan1-apname master br-lan permanent
33:33:00:00:00:01 dev wlan1-apname self permanent
33:33:00:00:00:02 dev wlan1-apname self permanent
01:00:5e:00:00:01 dev wlan1-apname self permanent
4c:13:65:00:0f:82 dev wlan0-ap vlan 1 master br-lan permanent
4c:13:65:00:0f:82 dev wlan0-ap master br-lan permanent
33:33:00:00:00:01 dev wlan0-ap self permanent
33:33:00:00:00:02 dev wlan0-ap self permanent
01:00:5e:00:00:01 dev wlan0-ap self permanent
33:33:00:00:00:01 dev wlan1-mesh self permanent
33:33:00:00:00:02 dev wlan1-mesh self permanent
01:00:5e:00:00:01 dev wlan1-mesh self permanent
33:33:ff:00:0f:88 dev wlan1-mesh self permanent
33:33:ff:00:00:00 dev wlan1-mesh self permanent
4e:13:65:00:0f:82 dev wlan0-apname vlan 1 master br-lan permanent
4e:13:65:00:0f:82 dev wlan0-apname master br-lan permanent
33:33:00:00:00:01 dev wlan0-apname self permanent
33:33:00:00:00:02 dev wlan0-apname self permanent
01:00:5e:00:00:01 dev wlan0-apname self permanent
33:33:00:00:00:01 dev wlan0-mesh self permanent
33:33:00:00:00:02 dev wlan0-mesh self permanent
01:00:5e:00:00:01 dev wlan0-mesh self permanent
33:33:ff:00:0f:82 dev wlan0-mesh self permanent
33:33:ff:00:00:00 dev wlan0-mesh self permanent

Scenario: the same but with my laptop connected via cable to YouHua WR1200JS lan4. On YouHua WR1200JS, after connecting my laptop via cable with a static IP and no gateway set, these two new lines appear:

00:50:b6:f0:3c:60 dev lan4 master br-lan 
00:50:b6:f0:3c:60 dev lan4 self

On PlasmaCloud PA1200, after connecting my laptop via cable to the YouHua WR1200JS with a static IP and no gateway set, these two new lines appear:

00:50:b6:f0:3c:60 dev ethernet1 master br-lan 
00:50:b6:f0:3c:60 dev ethernet1 vlan 1 self

For some reason, even without having a gateway in the laptop and setting a static IPv4, the 10.13.0.1 already appears in ip neigh...

When starting pinging, there is no change on PlasmaCloud PA1200, but there is a line appearing-disappearing on YouHua WR1200JS. This line:

aa:aa:aa:0d:fe:aa dev lan1 self

is missing when the ping works and is present when the ping does not work.

Also, sometimes (did not find a correlation with ping for this), the lines relative to the other router appear-disappear. For example, on YouHua, this line sometimes disappears 4c:13:65:00:0f:80 dev lan1 self and that MAC address is from the PlasmaCloud device. And on PlasmaCloud, sometimes these lines disappear d4:5f:25:eb:7e:ac dev ethernet1 master br-lan and d4:5f:25:eb:7e:ac dev ethernet1 vlan 1 self.

For making sure it was not a problem of my laptop, I tried using a ping on PowerShell on a Windows 11 laptop. I suspect that we should not trust the percentages as there is some additional timeout that looks different from ping on Linux.

Just a couple of scenarios: YouHua WR1200JS connected via cable to TP-Link WDR3600, both only with OpenWrt 24.10 and lime-proto-anygw. Laptop connected to TP-Link.

ping /t 10.13.0.1

Pinging 10.13.0.1 with 32 bytes of data:
Reply from 10.13.0.1: bytes=32 time<1ms TTL=64
[...]
Ping statistics for 10.13.0.1:
    Packets: Sent = 2056, Received = 1848, Lost = 208 (10% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 2ms, Average = 0ms
Control-C

PlasmaCloud connected via cable to YouHua WR1200JS, both only with OpenWrt 24.10 and lime-proto-anygw. Laptop connected to YouHua.

ping /t 10.13.0.1

Pinging 10.13.0.1 with 32 bytes of data:
Request timed out.
[...]
Ping statistics for 10.13.0.1:
    Packets: Sent = 780, Received = 173, Lost = 607 (77% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 1ms, Average = 0ms
Control-C

For understanding how much this was related to DSA, I used tcpdump also on swconfig devices. In this scenario, the YouHua WR1200JS with DSA is connected via cable to TP-Link WDR3600, both with only OpenWrt 24.10 and lime-proto-anygw, and my laptop connected to TP-Link. I was connected to the named AP from TP-Link and tcpdump was running on the TP-Link.

I could observe three different situations:

for a while seems that TP-Link is answering correctly, all requests are received and answered

arping -I enp0s20u1 10.13.0.1 
ARPING 10.13.0.1 from 10.13.252.150 enp0s20u1
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.227ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.521ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  0.842ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  0.832ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  0.861ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  0.915ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  0.945ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.003ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  0.984ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  0.959ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  0.916ms
^CSent 10 probes (1 broadcast(s))
Received 11 response(s)

root@LiMe-f9c239:~# tcpdump -i eth0.1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0.1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:53:21.251884 ARP, Request who-has anygw (Broadcast) tell 10.13.252.150, length 46
14:53:21.252321 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
14:53:22.251506 ARP, Request who-has anygw (aa:aa:aa:0d:fe:aa (oui Unknown)) tell 10.13.252.150, length 46
14:53:22.251615 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
14:53:23.251452 ARP, Request who-has anygw (aa:aa:aa:0d:fe:aa (oui Unknown)) tell 10.13.252.150, length 46
14:53:23.251562 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
14:53:24.251404 ARP, Request who-has anygw (aa:aa:aa:0d:fe:aa (oui Unknown)) tell 10.13.252.150, length 46
14:53:24.251515 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
14:53:25.251336 ARP, Request who-has anygw (aa:aa:aa:0d:fe:aa (oui Unknown)) tell 10.13.252.150, length 46
14:53:25.251452 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
14:53:26.251276 ARP, Request who-has anygw (aa:aa:aa:0d:fe:aa (oui Unknown)) tell 10.13.252.150, length 46
14:53:26.251386 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
14:53:27.251300 ARP, Request who-has anygw (aa:aa:aa:0d:fe:aa (oui Unknown)) tell 10.13.252.150, length 46
14:53:27.251414 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
14:53:28.251185 ARP, Request who-has anygw (aa:aa:aa:0d:fe:aa (oui Unknown)) tell 10.13.252.150, length 46
14:53:28.251298 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
14:53:29.251171 ARP, Request who-has anygw (aa:aa:aa:0d:fe:aa (oui Unknown)) tell 10.13.252.150, length 46
14:53:29.251283 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
^C
18 packets captured
18 packets received by filter
0 packets dropped by kernel

for a while requests are not received, and thus are not answered

arping -I enp0s20u1 10.13.0.1 
ARPING 10.13.0.1 from 10.13.252.150 enp0s20u1
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.291ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.324ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  0.851ms
^CSent 19 probes (1 broadcast(s))
Received 3 response(s)

root@LiMe-f9c239:~# tcpdump -i eth0.1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0.1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:54:05.532602 ARP, Request who-has anygw (Broadcast) tell 10.13.252.150, length 46
14:54:05.533054 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
14:54:06.356614 IP LiMe-f9c239 > laptop.thisnode.info: ICMP net 90.68.206.60 unreachable, length 84
14:54:07.523930 IP6 fe80::a8aa:aaff:fe0d:feaa > fe80::ad6a:e8ef:bf3f:b693: ICMP6, neighbor solicitation, who has fe80::ad6a:e8ef:bf3f:b693, length 32
14:54:07.524277 IP6 fe80::ad6a:e8ef:bf3f:b693 > fe80::a8aa:aaff:fe0d:feaa: ICMP6, neighbor advertisement, tgt is fe80::ad6a:e8ef:bf3f:b693, length 24
14:54:07.532569 ARP, Request who-has anygw (aa:aa:aa:0d:fe:aa (oui Unknown)) tell 10.13.252.150, length 46
14:54:07.532653 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

maybe is the YouHua answering here, because tcpdump on the TP-Link WDR3600 does not see neither the requests neither the answers. Which is a bit surprising for my basic understanding of networks, as I am listening on eth0, the master device, not even on a port or on the LAN bridge eth0.1.

root@laptop ~ » arping -I enp0s20u1 10.13.0.1 
ARPING 10.13.0.1 from 10.13.252.150 enp0s20u1
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.100ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.182ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.183ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.226ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.128ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.135ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.310ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.106ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.348ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.361ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.144ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.327ms
Unicast reply from 10.13.0.1 [AA:AA:AA:0D:FE:AA]  1.222ms
^CSent 12 probes (1 broadcast(s))
Received 13 response(s)

root@LiMe-f9c239:~# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
14:47:52.912190 ARP, Request who-has anygw (Broadcast) tell 10.13.252.150, length 46
14:47:52.912363 ARP, Request who-has anygw (Broadcast) tell 10.13.252.150, length 46
14:47:52.912556 ARP, Reply anygw is-at aa:aa:aa:0d:fe:aa (oui Unknown), length 28
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

Jun 23 '25 13:06 ilario

I did not check carefully (i.e. powering on the routers one by one), but a similar issue is happening also via WiFi, see https://github.com/libremesh/lime-packages/issues/1197#issuecomment-3041246251

Jul 06 '25 09:07 ilario