2008/6/1 Victor Hugo Bilouro <[EMAIL PROTECTED]>: > 2008/5/30 Victor Hugo Bilouro <[EMAIL PROTECTED]>: >> 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! ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd