Hi Alexey,
> > Claims were made that according the RFCs ICMP Host Unreachable should
> > be ignored and that 2.2.x does this correctly.
>
> Well, claims are the claims, but 2.2 really should behave
> exactly as 2.0 did in this case. At least, there were no deliberate
> actions to break it 8)8)8)
OK.
> I cannot reproduce the fault on my net.
I just tried it again: it's very easy to do on my machine:
I just try some IP-numbers close to the original 207.90.112.142 till I get
ICMP Host Unreachables back from some router (instead of RST packets from
the target itself !). A plain telnet on a 2.2.2-ac7 machine waits patiently
while a telnet on 2.0.36 quits immediatly with "No route to host".
I just tried again and found that 207.90.112.145 works at this moment.
> Actually, it would be better, if you did full hexadecimal tcpdump
> of this tcp connection and icmp. Or much better: get my tcpdump from
> ftp.inr.ac.ru and start it with options "-n -vv".
Here is some output for you (prepared with "tcpdump -s 1500 -x -vvv" from
Red Hat 5.2):
23:48:26.990650 verdi.et.tudelft.nl.1568 > dlp1164.dayton.eri.net.telnet: S
2451224203:2451224203(0) win 32696 <mss 536,sackOK,timestamp 21771424 0,nop,wscale 0>
(DF) [tos 0x10] (ttl 64, id 20934)
4510 003c 51c6 4000 4006 ffba 82a1 269e
cf5a 7091 0620 0017 921a b68b 0000 0000
a002 7fb8 5df6 0000 0204 0218 0402 080a
014c 34a0 0000 0000 0103 0300
23:48:27.285413 dayusr19.eri.net > verdi.et.tudelft.nl: icmp: host
dlp1164.dayton.eri.net unreachable (ttl 241, id 6781)
4500 0038 1a7d 0000 f101 51b0 cf00 e557
82a1 269e 0301 bedc 0000 0000 4510 003c
51c6 4000 2f06 0000 82a1 269e cf5a 7091
0620 0017 921a b68b
23:48:29.988009 verdi.et.tudelft.nl.1568 > dlp1164.dayton.eri.net.telnet: S
2451224203:2451224203(0) win 32696 <mss 536,sackOK,timestamp 21771724 0,nop,wscale 0>
(DF) [tos 0x10] (ttl 64, id 20943)
4510 003c 51cf 4000 4006 ffb1 82a1 269e
cf5a 7091 0620 0017 921a b68b 0000 0000
a002 7fb8 5cca 0000 0204 0218 0402 080a
014c 35cc 0000 0000 0103 0300
23:48:30.244596 dayusr19.eri.net > verdi.et.tudelft.nl: icmp: host
dlp1164.dayton.eri.net unreachable (ttl 241, id 6783)
4500 0038 1a7f 0000 f101 51ae cf00 e557
82a1 269e 0301 bed3 0000 0000 4510 003c
51cf 4000 2f06 0000 82a1 269e cf5a 7091
0620 0017 921a b68b
23:48:35.988418 verdi.et.tudelft.nl.1568 > dlp1164.dayton.eri.net.telnet: S
2451224203:2451224203(0) win 32696 <mss 536,sackOK,timestamp 21772324 0,nop,wscale 0>
(DF) [tos 0x10] (ttl 64, id 20944)
4510 003c 51d0 4000 4006 ffb0 82a1 269e
cf5a 7091 0620 0017 921a b68b 0000 0000
a002 7fb8 5a72 0000 0204 0218 0402 080a
014c 3824 0000 0000 0103 0300
23:48:36.232975 dayusr19.eri.net > verdi.et.tudelft.nl: icmp: host
dlp1164.dayton.eri.net unreachable (ttl 241, id 6786)
4500 0038 1a82 0000 f101 51ab cf00 e557
82a1 269e 0301 bed2 0000 0000 4510 003c
51d0 4000 2f06 0000 82a1 269e cf5a 7091
0620 0017 921a b68b
> I believe, router is broken and randomly corrupts packets.
Could be. But I just double-hecked to make sure: On 2.0.36 the telnet to
the *same* host *immediately* returns with the "No route to host" error
while telnet on 2.2.2-ac7 just keeps waiting.
[robn@berlioz ~]$ telnet 207.90.112.145
Trying 207.90.112.145...
telnet: Unable to connect to remote host: No route to host
So there is a *different* behaviour between 2.0.36 and 2.2.2-ac7.
(another option would be that the ICMPs returned on the SYN packets from
2.2.2-ac7 (with all those TCP options) get garbled in a different way
than the simpler 2.0.36 SYN packets ...)
Please contact me if you want more/other measurements made !
Greetings,
Rob van Nieuwkerk
-
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to [EMAIL PROTECTED]
