Date: Mon, 20 Mar 2000 08:35:30 +0000 From: Brian Somers <brian@Awfulhak.org> To: Dermot McNally <dermot@mcnally.de> Cc: freebsd-net@FreeBSD.ORG Subject: Re: NAT issues with ppp - a fix Message-ID: <200003200835.IAA00371@hak.lan.Awfulhak.org> In-Reply-To: Message from Brian Somers <brian@Awfulhak.org> of "Sun, 05 Mar 2000 22:13:39 GMT." <200003052213.WAA07676@hak.lan.Awfulhak.org>
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.
I should correct myself here. I don't *have* to run MP. I thought I
did because I was somehow under the misconception that UDP packets
wouldn't fragment :-/ I don't know why....
> > > 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.
*sigh*, excuse the rantings.
> > > 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....
[.....]
> > I guess I'm gonna have to try to set up a proper PPPoE environment
> > here. I'll follow-up when I can.
>
> Hmm, I take that back. I'm still having problems. The problems can
> be circumvented with an MRU/MTU of 1000 and an MRRU of 1500 - causing
> ppp to set the iface to 1500 and chop the results up into 1000 byte
> frames.
>
> This'll need more testing before I can even look at trying to
> reproduce something consistently :-/
[.....]
Still ranting (but with a reduced cc list)....
It looks like this has nothing to do with fragmentation - not in my
case anyway. I've added diagnostics to the fragmentation code in
nat_cmd.c, and there is no unexpected lossage.
Is anyone in a position to try this (or a similar) scenario *without*
-nat (with real IP numbers - something I haven't got enough of) ? Do
things behave strangely ?
One other thing, I found this in my daily report this morning:
> ipfw: -1 Refuse TCP 199.185.137.3 172.16.0.12 in via tun0 Fragment = 184
> ipfw: -1 Refuse TCP 199.185.137.3 172.16.0.12 in via tun0 Fragment = 184
> ipfw: -1 Refuse TCP 199.185.137.3 172.16.0.12 in via tun0 Fragment = 184
> ipfw: -1 Refuse TCP 199.185.137.3 172.16.0.12 in via tun0 Fragment = 184
> ipfw: -1 Refuse TCP 199.185.137.3 172.16.0.12 in via tun0 Fragment = 184
while ipfw list says:
00100 allow ip from any to any via lo0
00200 deny ip from any to 127.0.0.0/8
65535 allow ip from any to any
This is very strange (172.16.0.12 is the interior machine), but not
even close in volume to being the cause of my dodgy connections....
Oh well, still looking.
--
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?200003200835.IAA00371>