Bug 11966 - TCP copies send and receive socket buffer sizes from routing information even when user applications set them
Summary: TCP copies send and receive socket buffer sizes from routing information even...
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 2.2.6-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: ru
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 1999-05-31 22:20 UTC by aron
Modified: 2002-07-29 08:31 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description aron 1999-05-31 22:20:01 UTC
TCP (enabled with rfc1323 extensions) exchanges the window scale option
only during connection establishment in its SYN packet. Thus, it is 
imperative that applications should set the socket buffer sizes *before*
establishing the TCP connection. 

However, in function tcp_mss() (in netinet/tcp_input.c), the socket
buffer size is set from old information contained in the routing tables.
Thus even if the application had set the socketbuffer size, this 
part of the code completely ignores that and goes ahead and sets the
socket buffer size itself. As a result, TCP operates with the flow
control window size determined from past information rather than what
the user has set.

Fix: 

The socket code should keep track of the fact whether the socket 
buffer size was set explicitly by the user or whether it contains the
default setting. It should be copied over from the routing information
only if it contains the default setting.
How-To-Repeat: Start a TCP transfer between two hosts (or just do a telnet) with the
default settings of socket buffer sizes. Then try starting a transfer
again transfer and try setting the TCP rcv socket buffer size on the 
TCP receiver to a large value. Check the size of the window scale option
exchanged - it'll still be small (perhaps 0). This is the result of
the user information being completely discarded away.
Comment 1 iedowse freebsd_committer freebsd_triage 2002-01-20 17:55:44 UTC
State Changed
From-To: open->feedback


Does this problem still exist?
Comment 2 ru freebsd_committer freebsd_triage 2002-01-24 12:59:38 UTC
On Sun, Jan 20, 2002 at 09:56:02AM -0800, iedowse@FreeBSD.ORG wrote:
> Synopsis: TCP copies send and receive socket buffer sizes from routing information even when user applications set them
> 
> State-Changed-From-To: open->feedback
> State-Changed-By: iedowse
> State-Changed-When: Sun Jan 20 09:55:44 PST 2002
> State-Changed-Why: 
> 
> Does this problem still exist?
> 
Yes, and I think this patch (sitting in my RELENG_4 tree for over
a year now, and I now almost forgot what it's about) should fix it:

Index: tcp_input.c
===================================================================
RCS file: /home/ncvs/src/sys/netinet/tcp_input.c,v
retrieving revision 1.107.2.20
diff -u -p -r1.107.2.20 tcp_input.c
--- tcp_input.c	2001/12/14 20:21:12	1.107.2.20
+++ tcp_input.c	2002/01/24 12:55:22
@@ -2615,7 +2615,8 @@ tcp_mss(tp, offer)
 		bufsize = roundup(bufsize, mss);
 		if (bufsize > sb_max)
 			bufsize = sb_max;
-		(void)sbreserve(&so->so_snd, bufsize, so, NULL);
+		if (bufsize > so->so_snd.sb_hiwat)
+			(void)sbreserve(&so->so_snd, bufsize, so, NULL);
 	}
 	tp->t_maxseg = mss;
 
@@ -2627,7 +2628,8 @@ tcp_mss(tp, offer)
 		bufsize = roundup(bufsize, mss);
 		if (bufsize > sb_max)
 			bufsize = sb_max;
-		(void)sbreserve(&so->so_rcv, bufsize, so, NULL);
+		if (bufsize > so->so_rcv.sb_hiwat)
+			(void)sbreserve(&so->so_rcv, bufsize, so, NULL);
 	}
 
 	/*


Cheers,
-- 
Ruslan Ermilov		Oracle Developer/DBA,
ru@sunbay.com		Sunbay Software AG,
ru@FreeBSD.org		FreeBSD committer,
+380.652.512.251	Simferopol, Ukraine

http://www.FreeBSD.org	The Power To Serve
http://www.oracle.com	Enabling The Information Age
Comment 3 Sheldon Hearn 2002-01-31 15:14:10 UTC
On Thu, 24 Jan 2002 05:00:02 PST, Ruslan Ermilov wrote:

>  Yes, and I think this patch (sitting in my RELENG_4 tree for over
>  a year now, and I now almost forgot what it's about) should fix it:

You want to commit your patch to tcp_input.c yourself, or shall I assign
this PR to jlemon?

Ciao,
Sheldon.
Comment 4 Sheldon Hearn freebsd_committer freebsd_triage 2002-01-31 15:27:40 UTC
State Changed
From-To: feedback->open

Ruslan will commit his patch when he has time. 


Comment 5 Sheldon Hearn freebsd_committer freebsd_triage 2002-01-31 15:27:40 UTC
Responsible Changed
From-To: freebsd-bugs->ru

Ruslan will commit his patch when he has time.
Comment 6 hiten pandya 2002-04-16 12:46:58 UTC
Hi,

ru@, have you committed this patch, or does it simply need updating?  Just 
a reminder. :)

  -- Hiten Pandya
  -- <hiten@uk.FreeBSD.org>

__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
Comment 7 gte743n 2002-06-19 21:36:25 UTC
a patch is there and has been open for a while
can this pr be closed?

-- 
Holland King        
gte743n@cad.gatech.edu
Comment 8 ru freebsd_committer freebsd_triage 2002-07-22 23:37:53 UTC
State Changed
From-To: open->patched

Fixed in 5.0-CURRENT, sys/netinet/tcp_input.c,v 1.166.
Comment 9 ru freebsd_committer freebsd_triage 2002-07-29 08:30:42 UTC
State Changed
From-To: patched->closed

Fixed in 4.6-STABLE, sys/netinet/tcp_input.c,v 1.107.2.25.