[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HELP: tcp wierdness...
On Wed, 16 Dec 1998, Marco S Hyman wrote:
> > even first packet goes already with those wierd flags "<nop,nop,timestamp,
> > [|tcp]>"... and this doesn't happen when i connect to the absolutely same
> > address from another computer in the same network!
Oh :) thanks, yep, 'RTFM'... i haven't read all related rfc. practiacally
my assume, that the flags are wierd, because i've never seen them before,
is lame. Yes, [|tcp] is also my fault, i had to increase tha value.
But wait, at the bottom you say handshaking is not completed (by packet
logs). If so, i feel i'm disunderstanding the basic things, i used to
think BSD tcp/ip stack returns a connected socket at once as the socket
is successfully connected (i.e. handshaking is done). But why does telnet
say "Connected to XXX, escape character is ^]", or lynx says "Connected,
sending request, waiting for reply"... they get connected sockets and
send their data (at least the write they do). This is really wierd.
Anyways, maybe the problem is in routers/modems(on leased line) of
my provider? Can their devices be so old/lame that not implement some
modern tcp options? The other thing, can these modern ip extentions
be switched off in kernel's config file?
> Uhh, what's wierd about those flags? The timestamp option is well
> defined and part of modern ip implementations. See rfc1323 (6 years
> old, now). Per appendix A of that document...
> APPENDIX A: IMPLEMENTATION SUGGESTIONS
> The following layouts are recommended for sending options on non-SYN
> segments, to achieve maximum feasible alignment of 32-bit and 64-bit
> | NOP | NOP | TSopt | 10 |
> | TSval timestamp |
> | TSecr timestamp |
> What you call your "normal" machine is simply one using a minimal
> (or very old) tcp stack.
> The [|tcp] is explained in the tcpdump man page.
> -s Snarf snaplen bytes of data from each packet rather
> than the default of 68 (with SunOS's NIT, the mini-
> mum is actually 96). 68 bytes is adequate for IP,
> ICMP, TCP and UDP but may truncate protocol infor-
> mation from name server and NFS packets (see
> below). Packets truncated because of a limited
> snapshot are indicated in the output with
> ``[|proto]'', where proto is the name of the proto-
> col level at which the truncation has occurred.
> BTW: Your "wierd" dump shows that the three way handshake is NOT
> complete. The far end keeps repeating
> S 11212238:11212238(0) ack 1729262871
> which indicates that it did not seen the ack to its syn-ack. Why it
> didn't see the ack I do not know.
> // marc