Date: Sun, 05 Mar 2000 02:20:15 +0000 From: Brian Somers <brian@Awfulhak.org> To: Dermot McNally <dermot@mcnally.de> Cc: Brian Somers <brian@Awfulhak.org>, Dermot McNally <dermo@mcnally.de>, freebsd-net@FreeBSD.org, peter@FreeBSD.org, jkh@FreeBSD.org, joe@FreeBSD.org, brian@hak.lan.Awfulhak.org Subject: Re: NAT issues with ppp - a fix Message-ID: <200003050220.CAA02369@hak.lan.Awfulhak.org> In-Reply-To: Message from Dermot McNally <dermot@mcnally.de> of "Sun, 05 Mar 2000 01:29:54 %2B0100." <4.2.0.58.20000305012120.02aa77e0@tim>
next in thread | previous in thread | raw e-mail | index | archive | help
> At 02:18 04.03.2000 +0000, Brian Somers wrote: > >Hi, > > > >Because of a recent change in the way I connect to the net > >(PPPoUDPoPPPoISDN), I'm now seeing this problem ! > > > >Can you try the attached patch ? I believe this fixes the problem ! > > Bad news on my side - it doesn't appear to have helped. My test case: > Before applying the patch, I cvsupped to today's current and rebuilt the > world. Then I set the gateway box and a FreeBSD alpha box on my internal > network back to an MTU of 1500. I connected to confirm that the problem was > still there (it was). > > Then I applied the patch, rebuilt and installed ppp. Same test. Same > problem - well, same symptoms anyway. My two tests were, using Lynx to > connect to effectively any WWW site and using fetch to download a biggish > file. Fetch determines the file size (which I don't recall it managing to > do before), but doesn't actually get any further with the download. Lynx > manages to look up the site to which I try to connect, but then hangs at > the "waiting for response" stage. > > I can packet sniff this if you think it will help - my setup is slightly > different to yours: PPPoE via a DSL "modem". Mine is even more tricky... I've been battling this for some time now. I've actually got laptop <mtu 1500>-ethernet-<mtu 1500>gate<mtu 1466>-PPPoUDPoPPPoISDN-<mtu 1466> - PPPoISDN gateway - <mtu 1500> 'net - <mtu 1500> - PPPoUDP gateway - 'net The tricky bit is that I have to run the PPPoUDP link in MP mode using a 1466 byte MRRU. This will make the IP layer fragment the traffic to 1466 bytes, allowing ppp to pile a UDP/IP header of 28 bytes back on the front (and to add the 2/4 byte MP header and 1/2 byte protocol header) before sending out the UDP datagram. It's vital that the PPP/UDP/IP packet is no more than 1500 bytes as it's going to pop up at my gateway and then must travel across the 'net to the PPP/UDP gateway before it's unpacked and reassembled into what was sent out originally. I *think* this should work now - assuming the fragmentation side of things is functional. I haven't proven things yet though. I'll follow up.... > Slightly related: Assuming you do manage to fix things so that fragmented > packets are properly aliased (and it's probably a good thing, overall), a > convenient side effect of the current problem is that we notice that > fragmentation is occurring and drop our MTUs to avoid it. Since > fragmentation is worth avoiding anyway, is there value in having PPP log a > warning if it is seen to occur? Logging a warning may be a bit severe, but keeping a count of fragmented IP packets may be useful :-) > Cheers, > Dermot -- Brian <brian@Awfulhak.org> <brian@[uk.]FreeBSD.org> <http://www.Awfulhak.org> <brian@[uk.]OpenBSD.org> Don't _EVER_ lose your sense of humour ! 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?200003050220.CAA02369>