Date: Mon, 02 Jun 2008 13:27:34 +0200 From: Andre Oppermann <andre@freebsd.org> To: Victor Hugo Bilouro <bilouro@bilouro.com> Cc: net@freebsd.org Subject: Re: establish connection without tcp options Message-ID: <4843D926.8010402@freebsd.org> In-Reply-To: <ed5dcca30806020336mf5434c4la03d7a0b8b68332d@mail.gmail.com> References: <ed5dcca30805282340v22302581p457d0be0d9ca81e2@mail.gmail.com> <483E62D9.8000308@freebsd.org> <ed5dcca30805301514r7f33adebja650b0b872c33869@mail.gmail.com> <4842814C.3000508@freebsd.org> <ed5dcca30806011232jc56078apd8b5b65d03e15e07@mail.gmail.com> <48430A59.5090604@freebsd.org> <ed5dcca30806011851s7b67473dy61c4df03178402f6@mail.gmail.com> <4843A615.90809@freebsd.org> <ed5dcca30806020336mf5434c4la03d7a0b8b68332d@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Victor Hugo Bilouro wrote: > On Mon, Jun 2, 2008 at 4:49 AM, Andre Oppermann <andre@freebsd.org> wrote: >> Victor Hugo Bilouro wrote: >>> On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann <andre@freebsd.org> wrote: >>>> Victor Hugo Bilouro wrote: >>>>> syn--------------------------------- >>>>> sport 59966 >>>>> dport 22022 >>>>> sequence 874312230 >>>>> ack_number 0 >>>>> offset 5 >>>>> reserved 0 >>>>> urgent 0 >>>>> ack 0 >>>>> push 0 >>>>> reset 0 >>>>> syn 1 >>>>> fin 0 >>>>> window 65535 >>>>> checksum 50667 >>>>> urg_pointer 0 >>>>> >>>>> --------------------------------- >>>>> >>>>> syn+ack----------------------------- >>>>> sport 22022 >>>>> dport 59966 >>>>> sequence 2755934977 >>>>> ack_number 874312231 >>>>> offset 6 >>>>> reserved 0 >>>>> urgent 0 >>>>> ack 1 >>>>> push 2 >>>>> reset 4 >>>>> syn 9 >>>>> fin 0 >>>>> window 65535 >>>>> checksum 52952 >>>>> urg_pointer 0 >>>>> >>>>> --------------------------------- >>>>> >>>>> ack--------------------------------- >>>>> sport 59966 >>>>> dport 22022 >>>>> sequence 874312230 >>>> ^^^^^^^^^^^^^^ increment by one for SYN you sent. >>>> See also the ACK you got back above. >>>> >>>>> ack_number 2755934978 >>>>> offset 5 >>>>> reserved 0 >>>>> urgent 0 >>>>> ack 1 >>>>> push 0 >>>>> reset 0 >>>>> syn 0 >>>>> fin 0 >>>>> window 65535 >>>>> checksum 59030 >>>>> urg_pointer 0 >>>>> --------------------------------- >>>>> >>>>> ...and the log showed: >>>>> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10<ACK>; >>>>> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected. >>>>> >>>>> I'm still working... >>>> You should familiarize yourself some more with the sequence number >>>> system TCP uses. The Stevens books "TCP/IP Illustrated" Volume 1+2 >>>> are very good for that. >>>> >>>> -- >>>> Andre >>>> >>> PS.: I forgot to copy the list in the previous email exchanging, so >>> I'm doing now.... >>> >>> >>> Andre, thank you SO VERY MUCH. It's working fine! >>> >>> As every book show tcpdump examples of connection establishment , and >>> when the SYN flag is 0(as step #3 of three way handshake), sequence >>> number(SN) are omitted of dump, BUT, it's present. >> You should use the "-S" option to tcpdump. It will show absolute >> sequence number instead of relative ones (as guessed by tcpdump). >> >>> The thing is, the SN is present but it isn't consumed. So, packets >>> that don't consumes the SN, must have the last consumed SN + 1. >>> >>> Only for curiosity, linux and windows 2k accomplished without >>> problems the three way handshake without Sequence Number filled on >>> step #3. >> I have a hard time believing that. At most they may have sent you >> a retransmit or a challenge-ACK. >> >> -- >> Andre >> > > I will post here the tcpdump and tcptest dumps for both windows and > linux with ACK with sequence 0. > > windows tcpdump: (tcpdump -i ed0 -S tcp) > 17:01:46.420016 IP 192.168.1.10.59537 > 192.168.1.101.http: S > 770272892:770272892(0) win 65535 > 17:01:46.421835 IP 192.168.1.101.http > 192.168.1.10.59537: S > 1681202755:1681202755(0) ack 770272893 win 64240 <mss 1460> > 17:01:46.834808 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack > 1681202756 win 65535 > 17:01:46.839584 IP 192.168.1.10.59537 > 192.168.1.101.http: F > 770272893:770272893(0) ack 1681202756 win 65535 > 17:01:46.840613 IP 192.168.1.101.http > 192.168.1.10.59537: . ack > 770272894 win 64240 > 17:01:46.840675 IP 192.168.1.101.http > 192.168.1.10.59537: F > 1681202756:1681202756(0) ack 770272894 win 64240 > 17:01:47.297816 IP 192.168.1.10.59537 > 192.168.1.101.http: . ack > 1681202757 win 65535 That's interesting. I don't see any rationale why that should be acceptable. We enforce the sequence number to be present and valid in the ACK. This hasn't caused any complaints or incompatibilities so far. What version/service-pack of Windows and Linux (kernel) are you testing against? According to RFC793, Section 3.9, Page 69 the first check is actually testing the SEG.SEQ as follows: RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND. RCV.NXT is obviously the SEG.SEQ you sent with your SYN segment. It seems that Windows and Linux are ignoring this test because you didn't send any data with the ACK. Or they are simply ignoring the segment as invalid and your FIN packet (with the correct SEG.SEQ and SEG.ACK) causes the internal state transition. One may discuss which response, none (just ignore segment) or sending a RST (as we do currently) is better. I tend to argue the latter as it makes problems/bugs much more evident as we've witnessed with your test. -- Andre > windows dump of tcptest (every packet of connection establishment and > finalization) > SYN--------------------------------- > sport 56121 > dport 80 > sequence 1046947043 > ack_number 0 > offset 5 > reserved 0 > urgent 0 > ack 0 > push 0 > reset 0 > syn 1 > fin 0 > window 65535 > checksum 60750 > urg_pointer 0 > > --------------------------------- > > SYN+ACK--------------------------------- > sport 80 > dport 56121 > sequence 1494256296 > ack_number 1046947044 > offset 6 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 9 > fin 0 > window 64240 > checksum 63191 > urg_pointer 0 > > --------------------------------- > > ACK (SYN)--------------------------------- > sport 56121 > dport 80 > sequence 0 > ack_number 1494256297 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 27857 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 56121 > dport 80 > sequence 1046947044 > ack_number 1494256297 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 1 > window 65535 > checksum 2437 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 80 > dport 56121 > sequence 1494256297 > ack_number 1046947045 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 0 > window 64240 > checksum 3732 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 80 > dport 56121 > sequence 1494256297 > ack_number 1046947045 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 1 > window 64240 > checksum 3731 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 56121 > dport 80 > sequence 1046947045 > ack_number 1494256298 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 2436 > urg_pointer 0 > > --------------------------------- > > > > > > > > > linux tcpdump: (tcpdump -i ed0 -S tcp) > 17:06:12.493737 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: S > 501941873:501941873(0) win 65535 > 17:06:12.934559 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: S > 1436097196:1436097196(0) ack 501941874 win 5840 <mss 1460> > 17:06:13.313919 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . > ack 1436097197 win 65535 > 17:06:13.320533 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: F > 501941874:501941874(0) ack 1436097197 win 65535 > 17:06:13.331289 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: . > ack 501941874 win 5840 > 17:06:13.337751 IP hm389.locaweb.com.br.http > 192.168.1.10.54458: F > 1436097197:1436097197(0) ack 501941875 win 5840 > 17:06:13.762246 IP 192.168.1.10.54458 > hm389.locaweb.com.br.http: . > ack 1436097198 win 65535 > > > > > linux dump of tcptest (every packet of connection establishment and > finalization) > SYN--------------------------------- > sport 54458 > dport 80 > sequence 501941873 > ack_number 0 > offset 5 > reserved 0 > urgent 0 > ack 0 > push 0 > reset 0 > syn 1 > fin 0 > window 65535 > checksum 25507 > urg_pointer 0 > > --------------------------------- > > SYN+ACK--------------------------------- > sport 80 > dport 54458 > sequence 1436097196 > ack_number 501941874 > offset 6 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 9 > fin 0 > window 5840 > checksum 50368 > urg_pointer 0 > > --------------------------------- > > ACK (SYN)--------------------------------- > sport 54458 > dport 80 > sequence 0 > ack_number 1436097197 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 6059 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 54458 > dport 80 > sequence 501941874 > ack_number 1436097197 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 1 > window 65535 > checksum 62284 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 80 > dport 54458 > sequence 1436097197 > ack_number 501941874 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 0 > window 5840 > checksum 56445 > urg_pointer 0 > > --------------------------------- > > FIN--------------------------------- > sport 80 > dport 54458 > sequence 1436097197 > ack_number 501941875 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 2 > reset 4 > syn 8 > fin 1 > window 5840 > checksum 56443 > urg_pointer 0 > > --------------------------------- > > ACK (FIN)--------------------------------- > sport 54458 > dport 80 > sequence 501941875 > ack_number 1436097198 > offset 5 > reserved 0 > urgent 0 > ack 1 > push 0 > reset 0 > syn 0 > fin 0 > window 65535 > checksum 62283 > urg_pointer 0 > > --------------------------------- > > It was the first test conformance result of tcptest! > > > cheers
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4843D926.8010402>