Victor Hugo Bilouro wrote:
On Mon, Jun 2, 2008 at 4:49 AM, Andre Oppermann <[EMAIL PROTECTED]> wrote:
Victor Hugo Bilouro wrote:
On Sun, Jun 1, 2008 at 5:45 PM, Andre Oppermann <[EMAIL PROTECTED]> 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?
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.
--
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
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
