[FUG-BR] Problemas estabelecendo manualmente uma conexão tcp/ip

[Victor Hugo Bilouro]

2008/6/1 Victor Hugo Bilouro <bilouro em gmail.com>:
> 2008/5/30 Victor Hugo Bilouro <bilouro em gmail.com>:
>> Fala pessoal,
>>
>> Então, estou andando com o projeto do GSoC (TCP/IP Regression Test Suite)...
>> O projeto vai testar a conformidade do protocolo com as RFCs e também
>> fará verificação se bugs já resolvidos voltaram a acontecer
>> (regression).
>>
>> Seguinte, estou fazendo o handshake manualmente, ou seja, criando e
>> injetando os pacotes na rede.... e "teoricamente" tudo esta OK, porém,
>> o FreeBSD após os 3 passos do handshake (3 way handshake) esta me
>> enviando um RESET.
>>
>> Dêem uma olhada no 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
>>
>> Vocês tem alguma sugestão? Perguntei na lista internacional se a falta
>> de "tcp options" poderia ser um problema, mas, a resposta foi que
>> "definitivamente esse não seria o problema"... :(
>>
>> Aproveitando, os fontes estão no perforce.freebsd.org
>> cliente: bilouro_tcptest (//depot/projects/soc2008/bilouro_tcptest/)
>> o script do teste acima:
>> //depot/projects/soc2008/bilouro_tcptest/src/scripts/tcpconnect.py
>> (esse script é um teste sujo de como fazer o 3way handshake)
>>
>> --
>> Victor Hugo Bilouro
>> FreeBSD!
>>
>
> Pessoal, o Andre Oppermann da lista internacional deu a sugestão de
> ligar o sysctl net.inet.tcp.log_debug=1 o que faz o protocolo logar em
> /var/log/debug.log.
>
> Então agora da para o que o FreeBSD esta reclamando apesar de ainda
> não ter descobrido o porque. segue o log:
>
> 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
> 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.
>
>
> Apesar de ter certeza que o 3 passo do handshake não necessitar o
> envio de sequence, mesmo assim enviei para ver o que o log diria, e
> para minha surpresa...
>
>  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
> 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
> ---------------------------------
>
> .. o log mandou a seguinte mensagem:
> /var/log/debug.log:
> TCP [192.168.1.10]:59966 to [192.168.1.20]:22022 tcpflags 0x10<ACK>;
> syncache_expand: SEQ 874312230 != IRS+1 874312230, segment rejected.
>
>
>
> Continuarei trabalhando... Sugestões são benvindas...
> Vou torcer para descobrir o problema antes que eu tenha q
> estudar/debugar o kernel...
>
> abs
> --
> Victor Hugo Bilouro
> FreeBSD!
>

RESOLVIDO!

No passo 3 do handshake onde apenas enviamos o ack sem nenhum tcpflag,
o SEQUENCE NUMBER(SN) é obrigratório (alias ele é sempre obrigatório).

Mesmo que o tcpdump não o mostre, ele esta presente. E a regra é,
pacotes tcp que não consomem o SN devem ter o próximo SN a ser
consumido.

Então fica assim:

>  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 874312231              <--- mudança aki
> 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
> ---------------------------------

Apenas para curiosidade, o linux** e o windows 2k conectaram
normalmente, mesmo sem o SN preenchido no passo 3 do 3way handshake.

linux** -> segundo o nmap -O é um "IPCop firewall 1.4.10 - 1.4.15
(Linux 2.4.31 - 2.4.34)"

att
-- 
Victor Hugo Bilouro
FreeBSD!