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,
[EMAIL PROTECTED] not those you stumble over and fall"
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
