From owner-freebsd-questions Sun May 12 16:24:12 2002 Delivered-To: freebsd-questions@freebsd.org Received: from areilly.bpc-users.org (CPE-144-132-243-222.nsw.bigpond.net.au [144.132.243.222]) by hub.freebsd.org (Postfix) with SMTP id C532437B404 for ; Sun, 12 May 2002 16:24:04 -0700 (PDT) Received: (qmail 5644 invoked from network); 12 May 2002 23:24:03 -0000 Received: from localhost (andrew@127.0.0.1) by localhost with SMTP; 12 May 2002 23:24:03 -0000 Subject: Re: Network problems in recent -stable From: Andrew Reilly To: Archie Cobbs Cc: freebsd-questions@freebsd.org In-Reply-To: <200205121734.g4CHYRg16909@arch20m.dellroad.org> References: <200205121734.g4CHYRg16909@arch20m.dellroad.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.4 Date: 13 May 2002 09:24:02 +1000 Message-Id: <1021245843.590.26.camel@gurney.reilly.home> Mime-Version: 1.0 Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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