Date: Fri, 15 Dec 2000 10:01:54 -0500 From: "Matthew Emmerton" <matt@gsicomp.on.ca> To: "Julian Elischer" <julian@elischer.org>, "Patrick Bihan-Faou" <patrick@netzuno.com> Cc: <freebsd-net@FreeBSD.ORG> Subject: Re: PPPoE w/ nat auto fragmentation hack? Message-ID: <003f01c066a7$f75135c0$1200a8c0@gsicomp.on.ca> References: <200012150103.eBF13aU52009@hak.lan.Awfulhak.org> <002101c0663a$d0270b90$1200a8c0@gsicomp.on.ca> <3A39FB67.C26703D5@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Matthew Emmerton wrote: > Julian Elischer wrote: > > 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.. :-) According to Patrick Bihan-Faou, he suggested this a while ago and it was shot down in favour of the tcpmssd solution, which was later merged into user-ppp. If this problem exists with other protocols, or if the solution can be used with other protocols (in certain situations), then it would make sense to have it somewhere central so that we can avoid kludging up each implementation of each protocol that wants to take advantage of it (user-ppp, ng_ppp, etc). With this in mind, it really needs to be a part of the IP stack or libalias, at least. Perhaps now that the ppp folk have given us a nice reference implementation, we can work on integrating it more tightly with the system? -- Matt Emmerton To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003f01c066a7$f75135c0$1200a8c0>