> On Fri, 12 Feb 1999, Mike Galbraith wrote:
>
> >ftp.porcupine.org is one of these for me.. _always_ times out when I
> >do 'dir' in the /pub/security directory. (tcpdump attached). If I..
> > echo 0 > /proc/sys/net/ipv4/tcp_timestamps
> >..it works fine. Anyone know why?
>
> Looking at your trace I noticed that ftp.porcupine.org echo the tsval of
> the syn in the syn-ack, while linux doesn't. But the timestamp in the syn
> and synack should be needed only to initialize paws to avoid wrapped
> sequence number, so I think linux is doing a more efficient choice without
> echoing the tp->tsrecent in the synack packet. I am not 100% sure though
> because I never seen rfc1323.txt before today (and I am not uptodate with
> latest tcp-impl-drafts).
Do you have a pointer to the rfc? I need to do some serious reading and
head scratching to understand what you just said.
correction:
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,
and I only ran into it recently.
Have time for a question? I cut the ftp port stuff out as it seems to
be ok, and just stared at the ftp-data communication.
timestamps on
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)
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)
918804877.837935 193.203.186.200.1159 > 168.100.187.42.20: F 1:1(0) ack 1 win 32120 <nop,nop,timestamp 1960203 3027207> (DF) (ttl 64, id 10043)
918804878.215092 168.100.187.42.20 > 193.203.186.200.1159: . ack 2 win 17376 <nop,nop,timestamp 3027268 1960203> (DF) (ttl 46, id 4958)
timestamps off
918890122.897796 168.100.187.42.20 > 193.203.186.200.1033: S 2259242845:2259242845(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 3197808 0,nop,nop,ccnew 45607> (DF) (ttl 46, id 60566)
918890122.898047 193.203.186.200.1033 > 168.100.187.42.20: S 2120612729:2120612729(0) ack 2259242846 win 32120 <mss 1460,nop,wscale 0> (DF) (ttl 64, id 232)
918890123.224313 168.100.187.42.20 > 193.203.186.200.1033: . ack 1 win 17520 (DF) (ttl 46, id 60568)
918890123.822483 168.100.187.42.20 > 193.203.186.200.1033: . 1:1461(1460) ack 1 win 17520 (DF) (ttl 46, id 60570)
918890123.822614 193.203.186.200.1033 > 168.100.187.42.20: . ack 1461 win 30660 (DF) (ttl 64, id 235)
918890124.087527 168.100.187.42.20 > 193.203.186.200.1033: FP 2921:3262(341) ack 1 win 17520 (DF) (ttl 46, id 60573)
918890124.087722 193.203.186.200.1033 > 168.100.187.42.20: . ack 1461 win 32120 (DF) (ttl 64, id 236)
918890124.377733 168.100.187.42.20 > 193.203.186.200.1033: . 1461:2921(1460) ack 1 win 17520 (DF) (ttl 46, id 60572)
918890124.377855 193.203.186.200.1033 > 168.100.187.42.20: . ack 3263 win 30660 (DF) (ttl 64, id 237)
918890124.995310 193.203.186.200.1033 > 168.100.187.42.20: F 1:1(0) ack 3263 win 32120 (DF) (ttl 64, id 238)
918890125.303913 168.100.187.42.20 > 193.203.186.200.1033: . ack 2 win 17520 (DF) (ttl 46, id 60574)
It looks to me like my box is screwing up on the second packet after syn
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
looks to me like it's my box's turn to xmit but it doesn't; likely because
the packet was munged and got tossed. It looks like we both just sit there
and wait until my box gets bored (30 second attention span) and says heck
with it. Shouldn't there be some.... :-/ retrans.... oh bugger.
(Gee.. that's exactly what Dave said isn't it. We drop packet - porcupine
waits forever to retransmit because he's a little bit broken -ding- 8*)
ok..
Anyone see exactly this problem on a _non_ isdn connection?
How can I find out if porky is sending a bad packet in a 100% repeatable
manner when timestamps are on, or if I'm stepping on a perfectly good
packet 100% of the time? Is this another known property of this already
known to be broken stack? If so, sorry for wasting air and case closed.
-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/