> On Sat, 13 Feb 1999, Mike Galbraith wrote:
>
> >Do you have a pointer to the rfc? I need to do some serious reading and
> >head scratching to understand what you just said.
>
> andrea@laser:~$ grep ftp /usr/doc/doc-rfc/copyright
> It was put together from <ftp://ftp.germany.eu.net/pub/documents/rfc>,
> <ftp://venera.isi.edu/in-notes/rfc-editor>, and
> andrea@laser:~$
Thanks a bunch.
> >I had stated that this was a recent thing.. damn lie that. I started
> >a binary search to see (curiosity) when this started, and ran into it
> >immediately in stock 2.1.108. I guess it's been there for a long while,
>
> You mean that everything is fine in 2.1.107? If so could you send me the
> TCP diffs included in patch-2.1.108?
No, I started at 108 because it's the oldest source I have.
> >918804847.288893 168.100.187.42.20 > 193.203.186.200.1159: S 3082754207:3082754207(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 3027206 0,nop,nop,ccnew 43642> (DF) (ttl 46, id 4950)
> >918804847.290704 193.203.186.200.1159 > 168.100.187.42.20:
> >S 2264398605:2264398605(0) ack 3082754208 win 32120 <mss 1460,nop,nop,
> >timestamp 1957148 0,nop,wscale 0> (DF) (ttl 64, id 10040)
> ^ this is the bit I am talking about
>
> porcupine doesn't put a 0 in such place but it would put the timestamp
> 3027206 instead. This looks the natural way to handle timestamps but after
> my yesterday very (and only) short read of the RFC it seems not strictly
> requested so I can't tell you that Linux is buggy putting _always_ a 0 in
> the tsecr of every syn-ack.
>
> >918804847.836983 168.100.187.42.20 > 193.203.186.200.1159: . ack 1 win 17376 <nop,nop,timestamp 3027207 1957148> (DF) (ttl 46, id 4952)
> >918804848.671411 truncated-ip - 7 bytes missing!168.100.187.42.20 > 193.203.186.200.1159: . 1:1449(1448) ack 1 win 17376 <nop,nop,timestamp 3027207 1957148> (DF) (ttl 46, id 4954)
>
> This is something of crazy and should be a bug in porcupine or in the
> middle man.
>
> >and porcupine is waiting for my ack. Does it look like receiver troubles
> >to you?.. or is this just coincidence and tcpdump is being a PITA? It
>
> Don't know. Trusting the SOCK_PACKET code looks like it's a sender bug to
> me.
Looks like tcpdump _is_ being a PITA because....
> Would it be possible that porky (or some other men in the middle) when
> receive the syn-ack it just does (jiffies - tsecr) and use the computed
> value to set a bogus RTO and/or to do some other mess? I don't think it's
> the case but to give a try I changed the 2.2.2-pre2 linux TCP stack to do
> exactly what porcupine does (reverse engeneered from the tcpdump, I don't
> have the time to see which OS is running porcupine) in the synack
> timestamp case.
>
> You may want to give a try to this my patch and see if the bad behavior
> will go away.
[snip patch]
:) cool, porky talks with timestamps just fine now, as does ftp.x.org.
Tcpdump still says truncated-ip, but the packet sequence is the same
as with no timestamps and there's no timeout.
-Mike
-
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/