From owner-freebsd-net@FreeBSD.ORG Mon Jun 2 17:06:03 2008 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91395106568B for ; Mon, 2 Jun 2008 17:06:03 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.freebsd.org (Postfix) with ESMTP id 483AC8FC18 for ; Mon, 2 Jun 2008 17:06:03 +0000 (UTC) (envelope-from bilouro@bilouro.com) Received: by an-out-0708.google.com with SMTP id b33so856478ana.13 for ; Mon, 02 Jun 2008 10:06:02 -0700 (PDT) Received: by 10.100.208.6 with SMTP id f6mr1296435ang.21.1212426357997; Mon, 02 Jun 2008 10:05:57 -0700 (PDT) Received: by 10.100.216.6 with HTTP; Mon, 2 Jun 2008 10:05:57 -0700 (PDT) Message-ID: Date: Mon, 2 Jun 2008 14:05:57 -0300 From: "Victor Hugo Bilouro" To: "Andre Oppermann" In-Reply-To: <4843D926.8010402@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <483E62D9.8000308@freebsd.org> <4842814C.3000508@freebsd.org> <48430A59.5090604@freebsd.org> <4843A615.90809@freebsd.org> <4843D926.8010402@freebsd.org> Cc: net@freebsd.org Subject: Re: establish connection without tcp options X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2008 17:06:03 -0000 Hi, On Mon, Jun 2, 2008 at 8:27 AM, Andre Oppermann wrote: > Victor Hugo Bilouro wrote: >> >> On Mon, Jun 2, 2008 at 4:49 AM, Andre Oppermann wrote: >>> >>> Victor Hugo Bilouro wrote: >>>> >>>> On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann >>>> 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; >>>>>> 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 >> 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 >> 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!