Date: Sun, 1 Jun 2008 22:51:06 -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: <ed5dcca30806011851s7b67473dy61c4df03178402f6@mail.gmail.com> In-Reply-To: <48430A59.5090604@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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann <andre@freebsd.org> wrote: > Victor Hugo Bilouro wrote: >> >> On Sun, Jun 1, 2008 at 8:00 AM, Andre Oppermann <andre@freebsd.org> wrote: >>> >>> Victor Hugo Bilouro wrote: >>>> >>>> On Thu, May 29, 2008 at 5:01 AM, Andre Oppermann <andre@freebsd.org> >>>> wrote: >>>>> >>>>> Victor Hugo Bilouro wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> I'm working into establish manually a tcp connection. >>>>>> >>>>>> Does anyone knows if freebsd 7.0 stable agree, a connection >>>>>> establishment without TCP options set? >>>>> >>>>> Yes, certainly it does. If you send a SYN w/o any options it >>>>> won't use any. If you establish a connection from FreeBSD you >>>>> may ignore any options in SYN and in your SYN-ACK not send any. >>>>> If you want FreeBSD not to send any options you can set the >>>>> socket option TCP_NOOPT before you do the connect. >>>>> >>>>> -- >>>>> Andre >>>>> >>>> Hello, >>>> >>>> First thanks Andre! >>>> >>>> So, as I told before, I'm trying to connect manually, but, something >>>> wrong is occurring, after accomplish 3way-handshake, the server >>>> (passive open) is sending a RESET. >>>> You can see by tcpdump dump, that everything is OK. >>>> >>>> tcpdump -ied0 -S -vv tcp >>>> >>>> 08:58:21.302052 IP (tos 0x0, ttl 64, id 55136, offset 0, flags [none], >>>> proto TCP (6), length 40) 192.168.1.10.53639 > 192.168.1.20.22022: S, >>>> cksum 0x2a4d (correct), 3204258715:3204258715(0) win 65535 >>>> >>>> 08:58:21.302125 IP (tos 0x0, ttl 64, id 411, offset 0, flags [DF], >>>> proto TCP (6), length 44) 192.168.1.20.22022 > 192.168.1.10.53639: S, >>>> cksum 0xba99 (correct), 400703492:400703492(0) ack 3204258716 win >>>> 65535 <mss 1460> >>>> >>>> 08:58:21.697561 IP (tos 0x0, ttl 64, id 55137, offset 0, flags [none], >>>> proto TCP (6), length 40) 192.168.1.10.53639 > 192.168.1.20.22022: ., >>>> cksum 0xacf0 (correct), 0:0(0) ack 400703493 win 65535 >>>> >>>> 08:58:21.697632 IP (tos 0x0, ttl 64, id 412, offset 0, flags [DF], >>>> proto TCP (6), length 40) 192.168.1.20.22022 > 192.168.1.10.53639: R, >>>> cksum 0xacfc (correct), 400703493:400703493(0) win 0 >>>> >>>> >>>> Any suggestions? >>> >>> Enable net.inet.tcp.log_debug=1 and watch the log output. It will >>> tell you where it stumbled. >>> >>> -- >>> Andre >>> >>>> BTW, I'm GSoC student, doing TCP/IP Regression Test Suite. >>>> This code at bilouro_tcptest client at perfoce. >>>> (//depot/projects/soc2008/bilouro_tcptest/) >>>> This script: >>>> //depot/projects/soc2008/bilouro_tcptest/src/scripts/tcpconnect.py >>>> >>>> Best >>> >> >> cool I didn't know this... >> >> I'm seeing /var/log/debug.log and actually something is wrong.... >> >> syn--------------------------------- >> sport 56054 >> dport 22022 >> sequence 2992965889 >> ack_number 0 >> offset 5 >> reserved 0 >> urgent 0 >> ack 0 >> push 0 >> reset 0 >> syn 1 >> fin 0 >> window 65535 >> checksum 16400 >> urg_pointer 0 >> --------------------------------- >> >> syn+ack----------------------------- >> sport 22022 >> dport 56054 >> sequence 2079194755 >> ack_number 2992965890 >> offset 6 >> reserved 0 >> urgent 0 >> ack 1 >> push 2 >> reset 4 >> syn 9 >> fin 0 >> window 65535 >> checksum 44497 >> urg_pointer 0 >> --------------------------------- >> >> ack--------------------------------- >> sport 56054 >> dport 22022 >> sequence 0 > > ^^^^^^^^^^^^^ should be 2992965890 > >> ack_number 2079194756 >> offset 5 >> reserved 0 >> urgent 0 >> ack 1 >> push 0 >> reset 0 >> syn 0 >> fin 0 >> window 65535 >> checksum 33014 >> urg_pointer 0 >> --------------------------------- >> >> /var/log/debug.log: >> TCP [192.168.1.10]:56054 to [192.168.1.20]:22022 tcpflags 0x10<ACK>; >> syncache_expand: SEQ 0 != IRS+1 2992965889, segment rejected. > > The sequence number of your segment is neither the previous value > not is incremented by one to account for the SYN. > >> Even though I know in step #3 of 3way-handshake I don't need pass the >> sequence, I sent a sequence... > > You do have to pass the sequence number at any time. And it has > to be correct all the time. > >> 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. 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. More one time, thanks! -- Victor Hugo Bilouro FreeBSD!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ed5dcca30806011851s7b67473dy61c4df03178402f6>