Default anygw route working intermittently via cable #1192
Description
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.
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