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

[Victor Hugo Bilouro]

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!