From owner-freebsd-net  Fri Dec 15  3: 8: 4 2000
From owner-freebsd-net@FreeBSD.ORG  Fri Dec 15 03:08:02 2000
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mail.interware.hu (mail.interware.hu [195.70.32.130])
	by hub.freebsd.org (Postfix) with ESMTP id 9BBAF37B400
	for <freebsd-net@freebsd.org>; Fri, 15 Dec 2000 03:08:01 -0800 (PST)
Received: from monrovia-31.budapest.interware.hu ([195.70.53.223] helo=elischer.org)
	by mail.interware.hu with esmtp (Exim 3.16 #1 (Debian))
	id 146siV-000246-00; Fri, 15 Dec 2000 12:07:59 +0100
Sender: julian@FreeBSD.ORG
Message-ID: <3A39FB67.C26703D5@elischer.org>
Date: Fri, 15 Dec 2000 03:07:19 -0800
From: Julian Elischer <julian@elischer.org>
X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 5.0-CURRENT i386)
X-Accept-Language: en, hu
MIME-Version: 1.0
To: Matthew Emmerton <matt@gsicomp.on.ca>
Cc: freebsd-net@FreeBSD.ORG
Subject: Re: PPPoE w/ nat auto fragmentation hack?
References: <200012150103.eBF13aU52009@hak.lan.Awfulhak.org> <002101c0663a$d0270b90$1200a8c0@gsicomp.on.ca>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-net@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.org

Matthew Emmerton wrote:
> 
> > > 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.

pppoe is the main place this happens NOW but I have used that functionality
with good effect to reduce the packet size on transfers through my machine,
where
MTU discovery doesn't work and there is an unreliable link.
In this case, you want small packets, but you have to force the other machines
to decide
to use them..

> 
> 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?

I was wondering this yesterday..
either that or a separate mss-hack node.. but it needs to look into the tcp 
packets which means it would have to decode the PPP packets and the IP packets 
as well as the TCP headers, so I think that either we do it in the IP stack 
(with help from tcp) or ppp is the right place, because it already has access to
all the
information (for it's packet filters).

We COULD make it a function of libNAT as well of course.. :-)

> 
> --
> Matthew Emmerton
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-net" in the body of the message

-- 
      __--_|\  Julian Elischer
     /       \ julian@elischer.org
    (   OZ    ) World tour 2000
---> X_.---._/  presently in:  Budapest
            v


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message