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>