From owner-freebsd-questions@FreeBSD.ORG Sun Jan 8 18:57:44 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F284F16A41F for ; Sun, 8 Jan 2006 18:57:43 +0000 (GMT) (envelope-from moxiefreak@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7675643D45 for ; Sun, 8 Jan 2006 18:57:43 +0000 (GMT) (envelope-from moxiefreak@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so3044525wra for ; Sun, 08 Jan 2006 10:57:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=FlBPB1QaFEqs2Up0uW11pCrEbw8YdabzAhHGlZgr+ouVqmVZwd4KHj+j0ys4IdGyJu2OmcVKGSXaxqd6eNVT4XJwLvd6PfOB6dQpxgm8qCd2qyjCrgoNVgtvQ7Upn6ORvP3KI6bTsKy4Tc7s6SOhXkHDvr8Kq8hZDQ+XHC6zKSk= Received: by 10.64.148.14 with SMTP id v14mr2321809qbd; Sun, 08 Jan 2006 10:57:42 -0800 (PST) Received: by 10.65.113.5 with HTTP; Sun, 8 Jan 2006 10:57:42 -0800 (PST) Message-ID: <6061fc420601081057u4c1c34f1w548e57dfe4408abb@mail.gmail.com> Date: Sun, 8 Jan 2006 13:57:42 -0500 From: Steve Bernacki To: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Userland PPP MSS miscalculation? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2006 18:57:44 -0000 I think that I've stumbled upon a miscalculation that userland-PPP makes when "mssfixup" is enabled and I wanted to run it by a larger audience before I submitted a problem report. By default, FreeBSD calculates the TCP MSS value of a new TCP connection by taking the MTU of the egress interface and subtracting 40 -- 20 for ip headers, and 20 for tcp headers. Thus, A TCP SYN packet exiting an interface with an MTU of 1500 will have an MSS of 1460. Well behaved TCP implementations seem to know that MSS is a value that does NOT include any TCP options; the number of bytes that TCP options consume are effectively subtracted from the agreed-upon MSS value. So, for a "full" packet (1500mtu/1460mss) with 12 bytes of TCP options, the maximum data payload size is 1448. 1448 (payload) + 12 (TCP options) + 20 (TCP headers) + 20 (I= P headers) =3D 1500. In userland-PPP, the MSS value of an outgoing TCP SYN packet is calculated as such: tcpmss.c: line 73: [tcpmss.c,v 1.7.2.1] #define MAXMSS(mtu) ((mtu) - sizeof(struct ip) - sizeof(struct tcphdr) - 12= ) A change was made on 6/29/2004 to tcpmss.c to subtract 12 from the MAXMSS calculation (See < http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/ppp/tcpmss.c.diff?r1=3D1= .6&r2=3D1.7&f=3Dh>. According to the PR report that caused the change (bin/32717), this was don= e to pad additional space for TCP options that might be present. The author, Koji Mori, presents a test case that involves connecting to www.netbsd.org, but I suspect that the bug was actually in NetBSD's MSS calculation, although I've not done any research to see if this is the case. By removing the -12 from the MAXMSS calculation and recompiling ppp, outgoing SYN packets on my PPPoE-connected system now have an MSS value of 1452, which works perfectly well. With the -12 included, the MSS is calculated as 1440. This works perfectly well of course, but it wastes 12 extra bytes that could be included in a packet's payload. Am I missing something here, or is my evaluation correct? If it is correct= , I'll go ahead and submit a PR to revert the "-12" change. Thanks, Steve