From owner-freebsd-hackers Tue Jan 27 13:16:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA12446 for hackers-outgoing; Tue, 27 Jan 1998 13:16:13 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from heron.doc.ic.ac.uk (nynCvn3o1k5pmnNLgL/C/L1DBLlOtV7v@heron.doc.ic.ac.uk [146.169.2.31]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id NAA12390 for ; Tue, 27 Jan 1998 13:15:58 -0800 (PST) (envelope-from njs3@doc.ic.ac.uk) Received: from oak67.doc.ic.ac.uk [146.169.33.67] ([fif53kAoURyuRFkGy4yd4mVhMOBcd3sU]) by heron.doc.ic.ac.uk with smtp (Exim 1.62 #3) id 0xxINa-0002zm-00; Tue, 27 Jan 1998 21:17:10 +0000 Received: from njs3 by oak67.doc.ic.ac.uk with local (Exim 1.62 #3) id 0xxIMD-0001jw-00; Tue, 27 Jan 1998 21:15:45 +0000 From: njs3@doc.ic.ac.uk (Niall Smart) Date: Tue, 27 Jan 1998 21:15:45 +0000 In-Reply-To: Stefan Bethke "Re: TCP_MAXSEG and path MTU discovery" (Jan 27, 9:29pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Stefan Bethke , Niall Smart Subject: Re: TCP_MAXSEG and path MTU discovery Cc: hackers@FreeBSD.ORG Message-Id: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk On Jan 27, 9:29pm, Stefan Bethke wrote: } Subject: Re: TCP_MAXSEG and path MTU discovery > --On Die, 27. Jan 1998 19:10 Uhr +0000 "Niall Smart" > wrote: > > > if (setsockopt(fd, IPPROTO_TCP, TCP_MAXSEG, &opt, optlen) < 0) > > perror("setsockopt"), exit(1); > > > > if (connect(fd, (struct sockaddr*) &sin, sizeof(sin)) < 0) > > perror("connect"), exit(1); > > > With argv[3] == "300", I'm getting this, 146.169.50.56 being my host. > > > > 19:04:07.726242 146.169.50.56.1171 > 146.169.46.7.21: S > 1185413053:1185413053(0) win 16384 0,nop,nop,timestamp[|tcp]> (DF) > > 19:04:07.728505 146.169.46.7.21 > 146.169.50.56.1171: S > 4095294624:4095294624(0) ack 1185413054 win 8760 (DF) > > 19:04:07.728603 146.169.50.56.1171 > 146.169.46.7.21: . ack 4095294625 win > 17520 (DF) > > > > What happened to my maximum segment size?? (Yes, the program prints 1460) > > Quoting from Stevens, TCP/IP Illustrated, Vol. II, pp. 1022: > > TCP_MAXSEG option > [...] When a SYN is received from the other end with a MSS option, tcp_input > calls tcp_mss, and t_maxseg can be set as high as the outgoing interface > MTU. [1460 for Ethernet ...] Therefore, after a call to socket but before a > connection is established, a process can only decrease the MSS from its > default of 512. After a connection is established, the process can decrease > the MSS from whatever was selected by tcp_mss. > > The logic here seems to be that a SYN with MSS is the equivalent of a > setsockopt(TCP_MAXSEG). > > I've haven't read enought to say *why* this is useful, and Net/3 even > doesn't include path MTU discovery, so Stevens doesn't explain it's > implementation. Stefen, As far as I can see, this processing is only done on incoming SYN segments (nothing to do with incoming SYN|ACK segments, or outgoing SYN segments) >From tcp_input.c:1947 * * NOTE that this routine is only called when we process an incoming * segment, for outgoing segments only tcp_mssopt is called. * The function tcp_mssopt is commented: /* * Determine the MSS option to send on an outgoing SYN. */ (Bingo?) It uses a simple algorithm: rt = tcp_rtlookup(tp->t_inpcb); if (rt == NULL) return tcp_mssdflt; return rt->rt_ifp->if_mtu - sizeof(struct tcpiphdr); I'm not familiar with the sockets data structures, but shouldn't this function lookup the current value for t_maxseg and if it is valid, use it? I'll look a little more into this now and send another email soon. Regards Niall