T/TCP useless on FreeBSD 4.7?
michael rabinovich
misha at research.att.com
Fri Aug 1 08:14:15 PDT 2003
Hi,
Does anyone know the status of T/TCP support on FreeBSD 4.7?
A simple test using the ttcpcli and ttcpserv
examples from Stevens' T/TCP book shows basically the
same behavior as described in Sec. 3.7 of the book as "Solaris bug":
the server drops the data in the initial SYN
segment from the client, causing the client to timeout and retransmit
the data.
Specifically, tcpdump (see below) shows that both hosts do
exchange proper TTCP options (CC + CCecho), so TTCP is indeed used.
It's just that the server drops the data and causes a
timeout+retransmission on the client side.
The source code in /sys/netinet/tcp_syncache.c seems to support this
guess (see the snippet below).
For the test, I used FreeBSD 4.7 Release 2
as a client and FreeBSD 4.7 Release 0 as the server.
Am I missing something (after all, FreeBSD is supposed to be a ref
implementation of T/TCP!) and if not is there is a simple way around
this problem, short of going back to earlier FreeBSD releases?
Thanks so much in advance,
Michael Rabinovich
----------------------------------------------------------
Michael Rabinovich misha at research.att.com
AT&T Labs - Research (973)360-8778 (voice)
180 Park Ave, (973)360-8871 (fax)
Florham Park, NJ 07932 www.research.att.com/~misha
----------------------------------------------------------
*******************************************************
Here is the source code snippet from /sys/netinet/tcp_syncache.c:
*******************************************************
/*
* Given a LISTEN socket and an inbound SYN request, add
* this to the syn cache, and send back a segment:
* <SEQ=ISS><ACK=RCV_NXT><CTL=SYN,ACK>
* to the source.
*
* 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.
*/
int
syncache_add(inc, to, th, sop, m)
struct in_conninfo *inc;
struct tcpopt *to;
struct tcphdr *th;
struct socket **sop;
struct mbuf *m;
{
**********************************************************************
Here is the TCP dump with CC options (I produced it with "-s 0" option
but removed some of the packet payloads for brevity):
**********************************************************************
15:40:37.716398 gs1.research.att.com.3000 > cdn2.research.att.com.8888: SFP 2663030787:2663031187(400) win 57600 <mss 1460,nop,wscale 0,nop,nop,timestamp 241716793 0,nop,nop,cc 166881> (DF)
0x0000 4500 01d4 1861 4000 4006 0000 87cf 0e2d E....a at .@......-
0x0010 87cf 0e22 0bb8 22b8 9eba a003 0000 0000 ..."..".........
0x0020 c00b e100 2db4 0000 0204 05b4 0103 0300 ....-...........
0x0030 0101 080a 0e68 4e39 0000 0000 0101 0b06 .....hN9........
0x0040 0002 8be1 5265 7120 6672 6f6d 2067 7331 ....Req.from.gs1
0x0050 2074 6f20 6364 6e32 00c7 0585 0000 0000 .to.cdn2........
0x0060 35db 0485 7084 0408 c2f5 0685 1ad8 0485 5...p...........
15:40:37.716695 cdn2.research.att.com.8888 > gs1.research.att.com.3000: S 2005557341:2005557341(0) ack 2663030788 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 206354147 241716793,nop,nop,cc 1088,nop,nop,ccecho 166881> (DF)
0x0000 4500 004c d61a 4000 4006 38a4 87cf 0e22 E..L.. at .@.8...."
0x0010 87cf 0e2d 22b8 0bb8 778a 605d 9eba a004 ...-"...w.`]....
0x0020 e012 e000 efdf 0000 0204 05b4 0103 0300 ................
0x0030 0101 080a 0c4c b6e3 0e68 4e39 0101 0b06 .....L...hN9....
0x0040 0000 0440 0101 0d06 0002 8be1 ... at ........
15:40:37.716715 gs1.research.att.com.3000 > cdn2.research.att.com.8888: F 401:401(0) ack 1 win 57600 <nop,nop,timestamp 241716793 206354147,nop,nop,cc 166881> (DF)
0x0000 4500 003c 1862 4000 4006 0000 87cf 0e2d E..<.b at .@......-
0x0010 87cf 0e22 0bb8 22b8 9eba a194 778a 605e ..."..".....w.`^
0x0020 a011 e100 2c1c 0000 0101 080a 0e68 4e39 ....,........hN9
0x0030 0c4c b6e3 0101 0b06 0002 8be1 .L..........
15:40:37.716843 cdn2.research.att.com.8888 > gs1.research.att.com.3000: . ack 1 win 57600 <nop,nop,timestamp 206354147 241716793,nop,nop,cc 1088> (DF)
0x0000 4500 003c d61b 4000 4006 38b3 87cf 0e22 E..<.. at .@.8...."
0x0010 87cf 0e2d 22b8 0bb8 778a 605e 9eba a004 ...-"...w.`^....
0x0020 a010 e100 d496 0000 0101 080a 0c4c b6e3 .............L..
0x0030 0e68 4e39 0101 0b06 0000 0440 .hN9.......@
15:40:38.913084 gs1.research.att.com.3000 > cdn2.research.att.com.8888: FP 1:401(400) ack 1 win 57600 <nop,nop,timestamp 241716913 206354147,nop,nop,cc 166881> (DF)
0x0000 4500 01cc 1865 4000 4006 0000 87cf 0e2d E....e at .@......-
0x0010 87cf 0e22 0bb8 22b8 9eba a004 778a 605e ..."..".....w.`^
0x0020 a019 e100 2dac 0000 0101 080a 0e68 4eb1 ....-........hN.
0x0030 0c4c b6e3 0101 0b06 0002 8be1 5265 7120 .L..........Req.
0x0040 6672 6f6d 2067 7331 2074 6f20 6364 6e32 from.gs1.to.cdn2
0x0050 00c7 0585 0000 0000 35db 0485 7084 0408 ........5...p...
15:40:38.913240 cdn2.research.att.com.8888 > gs1.research.att.com.3000: . ack 402 win 57200 <nop,nop,timestamp 206354267 241716913,nop,nop,cc 1088> (DF)
0x0000 4500 003c d61c 4000 4006 38b2 87cf 0e22 E..<.. at .@.8...."
0x0010 87cf 0e2d 22b8 0bb8 778a 605e 9eba a195 ...-"...w.`^....
0x0020 a010 df70 d3a5 0000 0101 080a 0c4c b75b ...p.........L.[
0x0030 0e68 4eb1 0101 0b06 0000 0440 .hN........@
15:40:38.913678 cdn2.research.att.com.8888 > gs1.research.att.com.3000: FP 1:401(400) ack 402 win 57600 <nop,nop,timestamp 206354267 241716913,nop,nop,cc 1088> (DF)
0x0000 4500 01cc d61f 4000 4006 371f 87cf 0e22 E..... at .@.7...."
0x0010 87cf 0e2d 22b8 0bb8 778a 605e 9eba a195 ...-"...w.`^....
0x0020 a019 e100 dedd 0000 0101 080a 0c4c b75b .............L.[
0x0030 0e68 4eb1 0101 0b06 0000 0440 5265 706c .hN........ at Repl
0x0040 2066 726f 6d20 6364 6e32 2074 6f20 6773 .from.cdn2.to.gs
0x0050 313b 2052 6571 2065 6368 6f3a 2052 6571 1;.Req.echo:.Req
0x0060 2066 726f 6d20 6773 3120 746f 2063 646e .from.gs1.to.cdn
0x0070 3200 0000 6c02 0000 f904 0000 c505 0000 2...l...........
15:40:38.913691 gs1.research.att.com.3000 > cdn2.research.att.com.8888: . ack 402 win 57200 <nop,nop,timestamp 241716913 206354267,nop,nop,cc 166881> (DF)
0x0000 4500 003c 1866 4000 4006 0000 87cf 0e2d E..<.f at .@......-
0x0010 87cf 0e22 0bb8 22b8 9eba a195 778a 61ef ..."..".....w.a.
0x0020 a010 df70 2c1c 0000 0101 080a 0e68 4eb1 ...p,........hN.
0x0030 0c4c b75b 0101 0b06 0002 8be1 .L.[........
More information about the freebsd-net
mailing list