From owner-freebsd-hackers Thu Jan 16 18:36:15 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id SAA04440 for hackers-outgoing; Thu, 16 Jan 1997 18:36:15 -0800 (PST) Received: from hemi.com (hemi.com [204.132.158.10]) by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id SAA04433 for ; Thu, 16 Jan 1997 18:36:10 -0800 (PST) Received: (from mbarkah@localhost) by hemi.com (8.8.4/8.7.3) id TAA26017; Thu, 16 Jan 1997 19:35:33 -0700 (MST) From: Ade Barkah Message-Id: <199701170235.TAA26017@hemi.com> Subject: Re: bug in setsockopt()... ? To: eka@werty.wasantara.net.id (Eka Kelana) Date: Thu, 16 Jan 1997 19:35:33 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <25801E10313@bandung.wasantara.net.id> from Eka Kelana at "Jan 17, 97 07:54:05 am" X-Mailer: ELM [version 2.4ME+ PL22 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Eka Kelana wrote: > 2. The first window size advertised by the sender (in the first SYN segment) > will always be 16384. This is the default socket buffer size. Even changing > the sender socket buffer size, wouldn't change the window size in this first > SYN segment. The above is not true. The advertised window size for the SYN packet will be whatever the SO_RCVBUF value is. For example, I wrote a sample code that sets the SO_RCVBUF to 1024, and here's what tcpdump says on connect: | 19:03:35.329442 gw.barkah.org.2087 > sushi.barkah.org.telnet: | S 1719751503:1719751503(0) win 1024 (DF) As you can see, the win size is 1024, despite the default 16384. > 3. The window size advertised by the receiver in the next SYN|ACK segment, > will be whatever the receiver socket buffer size. The window size advertised by the receiver is independent of the sender, as it should be. Here's an example response from a Cisco router: | 19:12:52.041976 hemi-csn.hemi.com.telnet > gw.barkah.org.2090: | S 1021634672:1021634672(0) ack 1826196096 win 2144 Here's output of a simple code which sets the receive buffer size to 1024, then connects to a remote host, then resets the buffer size and sends packets. The "Current receive buffer size" message prints out the value returned from getsockopt(): | ./a.out | Socket created, fd=3. | Current receive buffer size is: 16384 <-- Initial value | Setting buffer size to 1024 <-- Ok, make it 1k | Current receive buffer size is: 1024 <-- Check, looks good | Connect() to remote host successful | Current receive buffer size is: 17520 <-- After connect, bug gets us | Resetting buffer size to 1024 <-- See if we can set it to 1k | Current receive buffer size is: 1024 <-- Looks good | Sending packet to remote host <-- Ok, send something | Current receive buffer size is: 1024 <-- Size unchanged after send | Sending packet to remote host <-- Try again for the heck of it | Current receive buffer size is: 1024 <-- Still 1k. > Well, my question is: is this really a bug or just what mr. Barkah > said ? As David Greenman points out, bug related to path mtu discovery code (reasonable explanation to me, since the receive buffer size after the connect() does vary with different MTU values.) Regards, -Ade ------------------------------------------------------------------- Inet: mbarkah@hemi.com - HEMISPHERE ONLINE - -------------------------------------------------------------------