From owner-freebsd-net@FreeBSD.ORG Sat Jan 28 17:53:02 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F58716A420 for ; Sat, 28 Jan 2006 17:53:02 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from smtp.omnis.com (smtp.omnis.com [216.239.128.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACE4043D45 for ; Sat, 28 Jan 2006 17:53:01 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from [10.2.2.50] (24-158-230-170.dhcp.leds.al.charter.com [24.158.230.170]) by smtp-relay.omnis.com (Postfix) with ESMTP id 9E63B1407765; Sat, 28 Jan 2006 09:53:00 -0800 (PST) Message-ID: <43DBAF98.5010101@dellroad.org> Date: Sat, 28 Jan 2006 11:53:28 -0600 From: Archie Cobbs User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Candler References: <20060105110404.GA25737@uk.tiscali.com> <20060127130048.GA60219@uk.tiscali.com> <43DA30AD.5040907@dellroad.org> <20060127155649.GA60799@uk.tiscali.com> <43DA4CAC.3070906@dellroad.org> <20060128104455.GA63806@uk.tiscali.com> In-Reply-To: <20060128104455.GA63806@uk.tiscali.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: sl2tps, MRU, MTU, and MSS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2006 17:53:02 -0000 Brian Candler wrote: > As an observation: when you ifconfig ng0, you can't set separate "transmit > MTU" and "receive MTU". So I imagine that the configured MTU only applies to > outbound datagrams, i.e. it means "don't transmit any datagram larger than > this on this interface". If ng0 were to *receive* a datagram larger than the > MTU I don't know for sure what would happen, but given that it was > successfully received, I see no reason why the kernel should discard it. Right.. the kernel will happily receive any size packet that shows up. >> In any case, in the FreeBSD -> WinXP direction, you say we could send 1400 >> byte packets out the ng0 interface, but this is not necessarily true. What >> is the MRU that the WinXP machine asked for? If it's 1400, then the ng0 >> interface must definitely be < 1400, because of PPP overhead (e.g., IPCP). >> The 1400 negiotiated by LCP applies to PPP frame payload, not IP size. > > I think you're mistaken; see here in RFC 1661 The PPP MTU and the IP interface MTU can be the same only as long as there is no intermediate protocol doing compression or encryption. Even VJ compression has overhead (I think). So this is not necessarily true in general. You're right though that if straight IPCP is being used then PPP MTU == IP MTU. > So yes you're right, if FreeBSD is going to choose an MTU of 1376 in step > 1c, then it could propose an MRU of 1376 in step 2a, so that Windows would > choose an MSS of 1376-40. > > However I don't see how it could do this (easily), since it would have to > wait until it has finished negotiating the MRU from WinXP (step 1a/1b) > before it could even offer an MRU in the opposite direction (step 2a). It actually wouldn't be hard.. we'd just send another Config-Request, forcing a renegotiation with the smaller value. Alternately, one could implement the "MSS hack" that is implemented in ppp(8) and mpd that does a transparent "fixup" of the MSS as it flys by. > This does seem to be a lot of hoops to jump through, when you could simply > fix step 1c: if the WinXP machine says it can receive 1400-byte datagrams, > then configure the interface to send it datagrams of up to 1400 bytes! Well, this didn't work at one time. It may now in a SP2 world... so then this boils down to which brokenness (WinXP or the PIX) do you label as the real problem and which do you label as the unfortunate circumstance that we should work around. Since there's no right answer, it should be left up to the user to (re)configure as needed. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com