there must be something more than what meets the eye: i fished out another home gateway, a huawei this time. interestingly the symptoms are very similar (well, it also probably runs some version of linux).
openbsd wifi -> huawei -> linux wifi: 64 bytes from 192.168.1.66: icmp_seq=356 ttl=64 time=388.439 ms 64 bytes from 192.168.1.66: icmp_seq=357 ttl=64 time=402.701 ms 64 bytes from 192.168.1.66: icmp_seq=358 ttl=64 time=7.685 ms 64 bytes from 192.168.1.66: icmp_seq=359 ttl=64 time=3.425 ms --- 192.168.1.66 ping statistics --- 424 packets transmitted, 332 packets received, 4 duplicates, 21.7% packet loss round-trip min/avg/max/std-dev = 2.767/133.146/2781.459/256.199 ms packet loss and crazy latency times. again, pinging only the gateway is perfect. pinging from linux is perfect. only pinging from openbsd to linux through the router is not. i have tried now 2 routers and 2 wifi network devices, ath(4), run(4), and the symptoms are always similar. the delayed pings are interesting: openbsd: 23:35:15.363306 10.10.10.60 > 10.10.10.33: icmp: echo request (seq:310) 23:35:16.521805 10.10.10.33 > 10.10.10.60: icmp: echo reply (seq:310) linux: 23:35:16.515386 10.10.10.60 > 10.10.10.33: icmp: echo request seq 310 23:35:16.515490 10.10.10.33 > 10.10.10.60: icmp: echo reply seq 310 openbsd: 23:35:18.393363 10.10.10.60 > 10.10.10.33: icmp: echo request (seq:313) 23:35:18.643357 10.10.10.33 > 10.10.10.60: icmp: echo reply (seq:313) linux: 23:35:18.635922 10.10.10.60 > 10.10.10.33: icmp: echo request seq 313 23:35:18.636006 10.10.10.33 > 10.10.10.60: icmp: echo reply seq 313 in other words, linux answers right away once it gets the request, and openbsd gets reply right away. so it seems the delay happens inside the router (both routers). and of course the packet loss, that is unacceptable. anybody has an idea what i could try? -f -- illiterate? write for a free brochure!
