From owner-freebsd-net Thu Dec 14 22:45:20 2000 From owner-freebsd-net@FreeBSD.ORG Thu Dec 14 22:45:17 2000 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from modemcable101.200-201-24.mtl.mc.videotron.ca (modemcable140.61-201-24.mtl.mc.videotron.ca [24.201.61.140]) by hub.freebsd.org (Postfix) with SMTP id 3FA6037B400 for ; Thu, 14 Dec 2000 22:45:17 -0800 (PST) Received: (qmail 1504 invoked from network); 15 Dec 2000 06:45:16 -0000 Received: from patrak.local.mindstep.com (HELO PATRAK) (192.168.10.4) by jacuzzi.local.mindstep.com with SMTP; 15 Dec 2000 06:45:16 -0000 From: "Patrick Bihan-Faou" To: Subject: Re: PPPoE w/ nat auto fragmentation hack? Date: Fri, 15 Dec 2000 01:46:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! ""Matthew Emmerton"" wrote in message news:<002101c0663a$d0270b90$1200a8c0@gsicomp.on.ca>... > > > I'm happy to announce this problem has finally found its final solution > > > in ppp version >= 11/28/2000: the new option "tcpmssfixup" (enabled by > > > default!) corrects the outgoing TCP MSS and solves the problem for good. > > > This functionality is strictly identical to what the tcpmssd port does, > > > but it's now included in ppp, so no need to run an external program with > > > divert sockets etc. > > I've been watching this thread (since when I used to use DSL & PPPoE I used > to see this problem, although at the time I didn't know what it was) and am > amazed at how everyone's worked together to detect and fix this problem. > > Now, I'm not trying to play devil's advocate (although that would make me a > friend of Chucky, right?) but I'm wondering if user-ppp is the right place > to make this change. Isn't the problem specific to PPPoE? If that's the > case, then shouldn't it be ng_pppoe that gets updated, so that anything that > uses ng_pppoe will have the option of enabling the 'tcpmssfixup' option? Actually this is not specific to PPPoE. PPPoE shows the problem, but any link with "small" MTU and poorly configured routers suffers from this problem. This is why I initially advocated to get the TCP MSS fixup feature in libalias where it made more sense (to me). But this has been ruled out, and my initial patch was moved to the autonomous tcpmssd daemon, which was felt as an adequate solution by everybody. I am happy to see that with this recent change in PPP, we can get away without an external daemon specifically for this (and the problems related to getting it working right). This is a good thing. My main argument for having this in libalias were: - what this "TCP MSS fixup" thing does is really similar to other NAT functions - the purpose of NAT is to make a network look like a single machine, and if it was really a "single" machine, the TCP MSS would be set to the correct (small) value in the first place (which is why you don't see the problem if you connect a windows machine directly to your ADSL link). - we now have 2 implementations of the same functionality: ppp and tcpmssd So anyway to answer your question quickly, this feature does not belong to ng_pppoe. PPP is a much better place for it, libalias would (for me) be even better. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message