> The second is after ursula notices that it got no ack for the first.
> They have the same data, but the first try at sending the segment did
> not have the tcp timestamp options. Instead ursula (or somebody)
> filled that area with a bunch of zeroes (option <eol>).
>
It might be interesting to see if I can find a machine to try
and see if I can see what it thinks it is sending out.
The one machine I can think of that I have root access on that
is not behind a bizarro firewall and not on my local net doesn't seem to
exhibit the problem. It is a solaris 2.6 (with suggested patches) machine.
> Ursula and peace did both negotiate sack and timestamp at the beginning
> of the transfer, but then ursula doesn't send timestamp sometimes. When
> it does, it gets them correct. Should it not be the case that a tcp
> receiver should just accept the packet even if there's no timestamp?
>
Gregory Maxwell <greg@linuxpower.cx> had the most helpful suggestion of
turning off timestamps by doing:
echo -n 0 > /proc/sys/net/ipv4/tcp_timestamps
which worked like a charm, as you might imagine. Much faster than
my old sparc ever was :-)
> Are you doing anything funky with filtering in your LAN? Can you also
> take a look at /proc/net/snmp and see if the Tcp InErrs counter goes up
> during such a session? I wonder if the checksum is off. My test ftp
> to ursula did not exhibit the oddness you're seeing.
No, nothing funky at all. Yes, the errors counter does increase.
Austin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Mar 23 2000 - 21:00:20 EST