Date: 13 May 2002 09:24:02 +1000 From: Andrew Reilly <areilly@bigpond.net.au> To: Archie Cobbs <archie@dellroad.org> Cc: freebsd-questions@freebsd.org Subject: Re: Network problems in recent -stable Message-ID: <1021245843.590.26.camel@gurney.reilly.home> In-Reply-To: <200205121734.g4CHYRg16909@arch20m.dellroad.org> References: <200205121734.g4CHYRg16909@arch20m.dellroad.org>
index | next in thread | previous in thread | raw e-mail
Hi Archie,
Thanks for the help.
On Mon, 2002-05-13 at 03:34, Archie Cobbs wrote:
> Andrew Reilly writes:
> > I maintain an MS-PPTP VPN link between my FreeBSD system and my office
> > network, using the mpd port and netgraph. This has, historically, been
> > really reliable, and works well. Lately, I've been having problems,
> > though:
> >
> > Often, mail sent _to_ the office mail server will hang, and qmail-send
> > will note a time-out. Mail from the server is almost never a problem
> > (fetchmail), and messages sent manually, by typing SMTP through a telnet
> > session also always work fine.
[etc...]
> First, a question: what is the PPTP machine at the other end? Is it
> a MS machine or are both ends using mpd?
The other-end machine is an MS-NT5 or W2000 box. Only my end is using
mpd. I upgraded to mpd-3.8 (from 3.7) over the weekend. Not sure if
anything was changed in that?
> What is supposed to happen is this: your local machine sends a large
> TCP packet to the office with the 'DF' bit set (this is path MTU
> discovery). The mpd machine sees that it must fragment the packet
> (because the packet is larger than the MTU on the 'ng0' interface).
> But the 'DF' (don't fragment) bit is set, so the mpd machine should
> send an ICMP packet back to the local machine, which should adjust
> accordingly.
>
> So some step in that process may not be happening; this should be
> verifyable with tcpdump.
>
> A possible workaround is to enable multi-link PPP, if both ends support
> doing that.
>
> Another thing to play with is manually adjusting the MTU on the 'ng0'
> interface to see if that changes things. Also, see if larget ping
> packets get through ('ping -s 2000 ...') when send from either the mpd
> machine or the local machine.
One of the respondents on the local BUGS mailing list suggested that
too, and I have the following to report:
Running:
jot 1000 1300 | while read i; do sudo ping -c 1 -s $i corvus;
done>ping_log 2>&1
(corvus is a FreeBSD-4 server box on the network in the office).
The simultaneously running tcpdump -i ng0 said "ip reassembly time
exceeded" a few times, and ping_log looked normal everywhere except for
the entry where "1478 bytes from 192.168.10.13: ..." should have been,
where we got instead:
ping: sendto: Message too long
I'm not sure that it's necessarily packet size specific, because I saw
this happen when I was doing random sizes manually, when the ping -s
argument was 1468.
Unless you've done something to mpd-3.8 to fix things, I can report that
the problem has gone away as a result of adding the following line to my
ipfw rules:
add allow all from any to any frag
Since this change was added to rc.firewall in November 1999, I suspect
that something else must be at work, because I haven't had that rule in
place, _and_ I haven't been having problems until a couple of weeks ago.
Weird, but thankfully, all seems OK now.
Thanks again for your help.
--
Andrew
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1021245843.590.26.camel>