>Number:         15743
>Category:       port-i386
>Synopsis:       TCP-Handshake not established with Raptor when delay-bit set in ip-Header
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-i386-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 26 08:35:00 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     Dejan Ivkovic
>Release:        1.4 1.5.x ...
>Organization:
Faber-Castell CONSULTING GmbH
>Environment:
Not known, as we are using Raptor on Windows NT and the ISP (where theproblem occures is not able to get this behaviour fixed) 
>Description:
While TCP-Handshake with a NetBSD System to our Firewall Raptor (Windows NT SP6, Symantec Raptor 6.5) the connections is not established on regurarly base. 

Error (or effect) looks like that:
gmc-instruments.com is a system behind our firewall
FW0.IX.VIP.AT is the provider

15:02:06.120600 FW0.IX.VIP.AT.16676 > mail.gmc-instruments.com.smtp: S 551788808:551788808(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 1181755 0> [tos 0x10] (ttl 50, id 52038)
	 4510 003c cb46 0000 3206 e00a d410 3a3d          
	 c33f 0bce 4124 0019 20e3 a108 0000 0000          
	 a002 4000 2237 0000 0204 05b4 0103 0300          
	 0101 080a 0012 083b 0000 0000                    
15:02:06.120600 mail.gmc-instruments.com.smtp > FW0.IX.VIP.AT.16676: . 3742178487:3742178507(20) ack 552788808 win 16384 [tos 0x10] (ttl 49, id 52038)
	 4510 003c cb46 0000 3106 e10a c33f 0bce          
	 d410 3a3d 0019 4124 df0d 1cb7 20f2 e348          
	 5010 4000 3415 0000 0204 05b4 0103 0300          
	 0101 080a 0012 083b 0000 0000               

As you can see, out firewall answeres the ACK with the same seq-number, which is not correct.

OK lets have another dump, a dump with a working  session:

15:13:09.697408 NS1.TPLUS.AT.53911 > mail.gmc-instruments.com.smtp: S 4098861626:4098861626(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 17606585 0> (ttl 49, id 11066)
	 4500 003c 2b3a 0000 3106 1622 d94c a006          
	 c33f 0bce d297 0019 f44f aa3a 0000 0000          
	 a002 4000 a8a6 0000 0204 05b4 0103 0300          
	 0101 080a 010c a7b9 0000 0000                    
15:13:09.697408 mail.gmc-instruments.com.smtp > NS1.TPLUS.AT.53911: S 2813437290:2813437290(0) ack 4098861627 win 8760 <mss 1460> (DF) (ttl 64, id 64753)
	 4500 002c fcf1 4000 4006 f579 c33f 0bce         
	 d94c a006 0019 d297 a7b1 a56a f44f aa3b         
	 6012 2238 6f25 0000 0204 05b4                   

Depends on system on side of the provider, which runs several NetBSD Firewalls (1.4.x 1.5.x) on several Systems, the handshake establishes or not. The provider (hiw words) is able a connection after penetrating our firewall with lots of pings, after that a tcp connection (e.g. Port 25) is able. But this is not accurate. 


>How-To-Repeat:
Everytime you try! just open a tcp connection, via telnet or application
>Fix:
When you compare the dumps, you can see a difference, where (IMHO) a difference should:

1. not appear
2. not conflict the handshake

The second byte of the ip-Header, which is the TOS one, has the Delay-Bit set up in non-working handshake, and the Delay-Bit cleared in working handshake scene

4510 (non)
4500 (working)

Ok, It's up to you to check this behaviour if this situation is a bug or a feature.

Right now, we are discussing this also with the developement device of symantec, but first tenor of them is:...as the raptor did not "see" this effect (no logging occures, while this happen, so the raptor is not able to get this error) is should not be an pure raptor error)...

Anyway, I would say, that both parties should get this run.

NetBSD for settings this bit
Raptor, because only with this combination (Raptor on Microsoft NT) this error occures..


>Release-Note:
>Audit-Trail:
>Unformatted: