Ping DUP / high latency

shm0 · January 30, 2020, 3:01am

Hi.
When I do a ping to my modem from my openwrt box, I get this result:

PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: seq=0 ttl=64 time=4.520 ms
64 bytes from 192.168.0.1: seq=0 ttl=64 time=4.562 ms (DUP!)
64 bytes from 192.168.0.1: seq=1 ttl=64 time=2.803 ms
64 bytes from 192.168.0.1: seq=1 ttl=64 time=2.839 ms (DUP!)
64 bytes from 192.168.0.1: seq=2 ttl=64 time=2.799 ms
64 bytes from 192.168.0.1: seq=2 ttl=64 time=2.830 ms (DUP!)
64 bytes from 192.168.0.1: seq=3 ttl=64 time=2.716 ms
64 bytes from 192.168.0.1: seq=3 ttl=64 time=2.752 ms (DUP!)
64 bytes from 192.168.0.1: seq=4 ttl=64 time=2.658 ms

The devices are directly connected. No switch or other device is in between them.
Duplicate responses only happen sometimes.
Latency also seems quite high.
However, there are no duplicate ping packets when doing a ping test over the internet.

Error/drop counters show 0/0 on both devices.
What could be the cause of this? Software/driver bug (modem) ?

moeller0 · January 30, 2020, 7:23am

Could you get a packet capture from the affected interface? Might be interesting to see exactly what is being transmitted,

shm0 · January 30, 2020, 9:02am

There is a bunch of arp requests going through the wire.
~ 10k ARP requets per minute
But I don't think that can cause ~3ms of delay?
I can't see any obvious things in the capture.

Here is a capture from the ping/pong session:

09:46:26.268080 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 378, length 40
09:46:26.270723 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 378, length 40
09:46:27.273379 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 379, length 40
09:46:27.275907 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 379, length 40
09:46:28.279002 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 380, length 40
09:46:28.281742 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 380, length 40
09:46:29.285860 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 381, length 40
09:46:29.288973 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 381, length 40
09:46:30.291299 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 382, length 40
09:46:30.293882 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 382, length 40
09:46:31.296877 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 383, length 40
09:46:31.299271 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 383, length 40
09:46:32.302118 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 384, length 40
09:46:32.304673 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 384, length 40
09:46:33.317255 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 385, length 40
09:46:33.319690 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 385, length 40
09:46:34.322997 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 386, length 40
09:46:34.325423 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 386, length 40
09:46:35.329093 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 387, length 40
09:46:35.331638 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 387, length 40
09:46:36.337218 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 388, length 40
09:46:36.339682 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 388, length 40
09:46:37.342743 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 389, length 40
09:46:37.345167 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 389, length 40
09:46:38.372321 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 390, length 40
09:46:38.374783 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 390, length 40
09:46:39.380109 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 391, length 40
09:46:39.382565 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 391, length 40
09:46:40.236976 IP 95.222.*.* > 10.130.*.*: ICMP 95.222.*.* udp port 68 unreachable, length 336
09:46:40.386937 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 392, length 40
09:46:40.389367 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 392, length 40
09:46:41.394308 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 393, length 40
09:46:41.396817 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 393, length 40
09:46:42.398681 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 394, length 40
09:46:42.401125 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 394, length 40
09:46:43.404485 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 395, length 40
09:46:43.406956 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 395, length 40
09:46:44.409710 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 396, length 40
09:46:44.412317 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 396, length 40
09:46:45.415710 IP 192.168.0.2 > 192.168.0.1: ICMP echo request, id 1, seq 397, length 40
09:46:45.418158 IP 192.168.0.1 > 192.168.0.2: ICMP echo reply, id 1, seq 397, length 40

I couldn't trigger the duplicate packet issue this time.
It only happens after a reboot for a certain amount of time, I think.
I will try to do another capture later.

Offtopic:
09:46:40.236976 IP 95.222.*.* > 10.130.*.*: ICMP 95.222.*.* udp port 68 unreachable, length 336

udhcpc: sending renew to 10.130.*.*
udhcpc: sending renew to 10.130.*.*
udhcpc: sending renew to 10.130.*.*
udhcpc: sending renew to 10.130.*.*
udhcpc: sending renew to 10.130.*.*
udhcpc: sending renew to 0.0.0.0
udhcpc: lease of 95.222.*.* obtained, lease time 7200

How to make udhcpc send the renew directly as broadcast and not as unicast?
I have set option broadcast '1' in my config.

//edit
So apparently, the broadcast is used to tell the server to send his answer as broadcast and not as I tought to force the client to use broadcasts only.
I made a small patch for udhcpc to always use broadcasts, works fine now.
I think my ISP has configured something wrong, Server-ID Option 54 is set to the IP of the relay server and I think that is not correct.

For the latency issue, I will try to connect another device to the modem and check if the latency is also high here.

//Offtopic
Could it be that the remaining lease time in the luci overview is bugged (by -40 min)?

//edit
With a mask of /24 the modem is not pingable.
Mask of /30 works.
I tried a different device, same high latency issue.
The modem also has a different IP (192.168.100.1) which is only reachable when no docsis link is established, also same high latency issue there.