establish connection without tcp options

Mon Jun 2 17:06:03 UTC 2008

Hi,

On Mon, Jun 2, 2008 at 8:27 AM, Andre Oppermann <andre at freebsd.org> wrote:
> Victor Hugo Bilouro wrote:
>>
>> On Mon, Jun 2, 2008 at 4:49 AM, Andre Oppermann <andre at freebsd.org> wrote:
>>>
>>> Victor Hugo Bilouro wrote:
>>>>
>>>> On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann <andre at 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!