Hello all, I think I've found a bug in UDP/ICMP code in the kernel using traceroute. To reproduce: Launch traceroute -n to some Linux system nearby really quickly 3 times in the row; localhost won't work, it has to go through network. Quick response is crucial. I used systems w/ in the same physical network and a few routers between (still < 5 ms response). The effect: On third traceroute (or perhaps second/first, if you're quick enough), ICMP port unreachable will not be sent to the UDP datagram. I've tested this with: - From FreeBSD to RHL 2.2.12-20 faulty - From RHL 2.2.16-3 to Irix 6.5 works fine - From RHL 2.2.16-3 to RHL 2.2.16-3 faulty - From RHL 2.2.16-3 to RHL 2.2.5-22 faulty - several other configurations. Not tested with Linux kernel 2.0/2.4 though. The conclusion: if the traceroute target system is Linux, some a packet will "get lost". This isn't a problem in traceroute, or the sending system. x.y.z.150: system tracerouting x.y.z.251: system responding to the traceroute notes: At 15:38:29.225113 UDP packet arrives, but port unreachable is not generated. ------- [ tcpdumping on the system responding to the traceroute ] 15:38:28.358692 P x.y.z.150.53479 > x.y.z.251.33435: udp 10 [ttl 1] (id 53480) 15:38:28.358860 > x.y.z.251 > x.y.z.150: icmp: x.y.z.251 udp port 33435 unreachable [tos 0xc0] (ttl 255, id 7378) 15:38:28.361062 P x.y.z.150.53479 > x.y.z.251.33436: udp 10 [ttl 1] (id 53481) 15:38:28.361210 > x.y.z.251 > x.y.z.150: icmp: x.y.z.251 udp port 33436 unreachable [tos 0xc0] (ttl 255, id 7379) 15:38:28.361449 P x.y.z.150.53479 > x.y.z.251.33437: udp 10 [ttl 1] (id 53482) 15:38:28.361582 > x.y.z.251 > x.y.z.150: icmp: x.y.z.251 udp port 33437 unreachable [tos 0xc0] (ttl 255, id 7380) 15:38:28.797142 P x.y.z.150.53480 > x.y.z.251.33435: udp 10 [ttl 1] (id 53481) 15:38:28.797277 > x.y.z.251 > x.y.z.150: icmp: x.y.z.251 udp port 33435 unreachable [tos 0xc0] (ttl 255, id 7383) 15:38:28.799550 P x.y.z.150.53480 > x.y.z.251.33436: udp 10 [ttl 1] (id 53482) 15:38:28.799697 > x.y.z.251 > x.y.z.150: icmp: x.y.z.251 udp port 33436 unreachable [tos 0xc0] (ttl 255, id 7384) 15:38:28.799940 P x.y.z.150.53480 > x.y.z.251.33437: udp 10 [ttl 1] (id 53483) 15:38:28.800075 > x.y.z.251 > x.y.z.150: icmp: x.y.z.251 udp port 33437 unreachable [tos 0xc0] (ttl 255, id 7385) 15:38:29.225113 P x.y.z.150.53481 > x.y.z.251.33435: udp 10 [ttl 1] (id 53482) 15:38:33.352273 P arp who-has x.y.z.251 tell x.y.z.150 15:38:33.352365 > arp reply x.y.z.251 (0:1:2:35:e6:f8) is-at 0:1:2:35:e6:f8 (0:90:27:57:e9:f7) 15:38:34.222369 P x.y.z.150.53481 > x.y.z.251.33436: udp 10 [ttl 1] (id 53483) 15:38:34.222507 > x.y.z.251 > x.y.z.150: icmp: x.y.z.251 udp port 33436 unreachable [tos 0xc0] (ttl 255, id 7393) 15:38:34.224770 P x.y.z.150.53481 > x.y.z.251.33437: udp 10 [ttl 1] (id 53484) 15:38:34.224906 > x.y.z.251 > x.y.z.150: icmp: x.y.z.251 udp port 33437 unreachable [tos 0xc0] (ttl 255, id 7394) ------- [ If arp entries are set statically, there won't be an arp query, but the "timeout" and packet "loss" still happens ] Regards, -- Pekka Savola "Tell me of difficulties surmounted, Pekka.Savola@netcore.fi not those you stumble over and fall" - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu
