From nobody@www.freebsd.org  Mon Jun 24 08:38:44 2002
Return-Path: <nobody@www.freebsd.org>
Received: from nwww.freebsd.org (www.FreeBSD.org [216.136.204.117])
	by hub.freebsd.org (Postfix) with ESMTP id 5AB7337B400
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 24 Jun 2002 08:38:44 -0700 (PDT)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by nwww.freebsd.org (8.12.2/8.12.2) with ESMTP id g5OFcihG085928
	for <freebsd-gnats-submit@FreeBSD.org>; Mon, 24 Jun 2002 08:38:44 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.2/8.12.2/Submit) id g5OFci6O085927;
	Mon, 24 Jun 2002 08:38:44 -0700 (PDT)
Message-Id: <200206241538.g5OFci6O085927@www.freebsd.org>
Date: Mon, 24 Jun 2002 08:38:44 -0700 (PDT)
From: Daniel Huang <dhuang@qobra.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: T/TCP support
X-Send-Pr-Version: www-1.0

>Number:         39787
>Category:       misc
>Synopsis:       T/TCP support
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jun 24 08:40:01 PDT 2002
>Closed-Date:    Wed Feb 19 13:23:23 PST 2003
>Last-Modified:  Wed Feb 19 13:23:23 PST 2003
>Originator:     Daniel Huang
>Release:        FreeBSD 4.5
>Organization:
Qobra Systems Inc.
>Environment:
FreeBSD  4.5-RELEASE FreeBSD 4.5-RELEASE #0: Mon Jan 28 14:31:56 GMT 2002     murray@builder.freebsdmall.com:/usr/src/sys/compile/GENERIC  i386    
>Description:
I tested the T/TCP by using the source code in <T/TCP Illustrated Volume
3> on FreeBsd 4.5. The tcpdump result as below:

09:49:10.957632 dhcp189.tor.qobra.net.1026 > dhcp189.tor.qobra.net.1028:
SFP 3873691517:3873691817(300) win 65535 <mss 16344,nop,nop,ccnew 7> (DF)

09:49:10.957748 dhcp189.tor.qobra.net.1028 > dhcp189.tor.qobra.net.1026:
S 2495134045:2495134045(0) ack 3873691518 win 65535 <mss 16344, nop, nop, cc 8, nop,nop,ccecho 7>

09:49:10.957782 dhcp189.tor.qobra.net.1026 > dhcp189.tor.qobra.net.1028:
F 301:301(0) ack 1 win 65535 <nop,nop,cc 7> (DF)

09:49:10.957834 dhcp189.tor.qobra.net.1028 > dhcp189.tor.qobra.net.1026:
ack 1 win 65535 <nop,nop,cc 8> (DF)

09:49:11.950539 dhcp189.tor.qobra.net.1026 > dhcp189.tor.qobra.net.1028:
FP 1:301(300) ack 1 win 65535 <nop,nop,cc 7> (DF)

09:49:11.950578 dhcp189.tor.qobra.net.1028 > dhcp189.tor.qobra.net.1026:
ack 302 win 65535 <nop,nop,cc 8> (DF)

09:49:11.950750 dhcp189.tor.qobra.net.1028 > dhcp189.tor.qobra.net.1026:
FP 1:401(400) ack 302 win 65535 <nop,nop,cc 8> (DF)

09:49:11.950768 dhcp189.tor.qobra.net.1026 > dhcp189.tor.qobra.net.1028:
ack 402 win 65535 <nop,nop,cc 7> (DF)

The client sent 300 bytes to server, and server reply 400 bytes to
client. It seems that step 4 and 5 are wrong, but I don't know why. I set rfc1644 on(1) and rfc1323 off(0), why step 4 sends wrong ACK and step 5 resend the message to server.

Furthermore, I couldn't get the normal T/TCP transaction result -- just 3 segments, for my test it's seem with the upper tcpdump. Could you please give me some advice? I appreciate.
    
>How-To-Repeat:
 Simply use the example T/TCP client/server source code in <TCP/IP Illustrated, Volume 3> P.17, P.18  
>Fix:
      
>Release-Note:
>Audit-Trail:

From: kenji@k2r.org
To: freebsd-gnats-submit@FreeBSD.org, dhuang@qobra.com
Cc: kenji@k2r.org
Subject: Re: misc/39787: T/TCP support
Date: 29 Oct 2002 12:00:17 +0900

 The reason of this behavior is documented in
 /usr/src/sys/netinet/tcp_syncache.c
 (I quote from the 4.6.2-RELEASE version,
 src/sys/netinet/tcp_syncache.c,v 1.5.2.6)
 as follows, just before the function syncache_add():
 
 - quote -
 
  * IMPORTANT NOTE: We do _NOT_ ACK data that might accompany the SYN.
  * Doing so would require that we hold onto the data and deliver it
  * to the application.  However, if we are the target of a SYN-flood
  * DoS attack, an attacker could send data which would eventually
  * consume all available buffer space if it were ACKed.  By not ACKing
  * the data, we avoid this DoS scenario.
 
 - unquote -
 
 So I'd rather consider this as an *intentional feature* of FreeBSD
 to block SYN-flooding.
 
 // Kenji Rikitake <kenji.rikitake@acm.org>
State-Changed-From-To: open->closed 
State-Changed-By: jlemon 
State-Changed-When: Wed Feb 19 13:22:57 PST 2003 
State-Changed-Why:  
Fixed in 5.0. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=39787 
>Unformatted:
