From owner-freebsd-net@FreeBSD.ORG Fri Jan 27 14:39:19 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 33BB916A420 for ; Fri, 27 Jan 2006 14:39:19 +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 E50C044111 for ; Fri, 27 Jan 2006 14:39:18 +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 140C21880C3E; Fri, 27 Jan 2006 06:39:15 -0800 (PST) Message-ID: <43DA30AD.5040907@dellroad.org> Date: Fri, 27 Jan 2006 08:39:41 -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> In-Reply-To: <20060127130048.GA60219@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: Fri, 27 Jan 2006 14:39:19 -0000 Brian Candler wrote: >> 1. PPP negotiates an MRU of 1400 >> 2. However, ifconfig ng0 shows an MTU of 1376 (where does that come from?) >> 3. When the client opens a TCP connection, it offers an MSS of 1360 > > ...and then fragmentation problems occur, because the remote server sends IP > datagrams which are 1400 bytes with DF bit set, the ng0 interface with MTU > 1376 rejects them, the generated ICMP messages are discarded by an > intervening NAT gateway, and the TCP connection fails. Sounds like the NAT gateway is the root cause of all this, no? While all the MTU logic in slt2ps is probably not optimal, in theory it shouldn't matter if it's not optimal because ICMP should be working. A router is supposed to be able to reduce the MTU if it needs to and things should continue to work. Instead of "fixing" sl2ps to work in your particular situation (and breaking it in other situations), is it possible to fix/replace the broken gateway instead? (Try a FreeBSD box instead :-) Some background as best as I can remember... The reduction of MTU to account for PPP protocol overhead (MPPE) is not controversial. Obviously if the hard MTU is (say) 1400 and you've got 4 bytes of MPPE overhead, then the interface MTU should be <= 1396. You're right that this shouldn't really happen unless MPPE is actually negotiated, but that's harder to do.. MPPE negotiation happens after link negotiation. To avoid this, disable MPPE if you can. The WinXP hack is something that at some time was deemed necessary to work around a bug in Windows XP. As I recall, it would advertise a MRU that was actually bigger than what it would really accept. Since there was no easy way to detect WinXP clients, we had to put in this workaround unconditionally. This may have only been a bug in pre-SP2 WinXP. It was (IIRC) when trying to do L2TP over IPSec, not PPTP. Hope this helps. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com