Date: Mon, 2 Jun 2008 14:05:57 -0300 From: "Victor Hugo Bilouro" <bilouro@bilouro.com> To: "Andre Oppermann" <andre@freebsd.org> Cc: net@freebsd.org Subject: Re: establish connection without tcp options Message-ID: <ed5dcca30806021005y4889c5c6w81a4a1223873c115@mail.gmail.com> In-Reply-To: <4843D926.8010402@freebsd.org> 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> <4843D926.8010402@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Mon, Jun 2, 2008 at 8:27 AM, Andre Oppermann <andre@freebsd.org> wrote: > 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? nmap -O (it's my hoster) "IPCop firewall 1.4.10 - 1.4.15 (Linux 2.4.31 - 2.4.34)" Windows Xp professional Service pack 1 build 2600.xpsp1.020828-1920 > > 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. Now I know that a sucessful test of FreeBSD is receive back a Reset Packet. Test cataloged. > > -- > 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 > > -- Victor Hugo Bilouro FreeBSD!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ed5dcca30806021005y4889c5c6w81a4a1223873c115>