From owner-freebsd-net Tue Jun 18 16:18:45 2002 Delivered-To: freebsd-net@freebsd.org Received: from ebola.biohz.net (adsl-64-168-80-140.dsl.snfc21.pacbell.net [64.168.80.140]) by hub.freebsd.org (Postfix) with ESMTP id 0E4F337B420 for ; Tue, 18 Jun 2002 16:18:31 -0700 (PDT) Received: from flu (localhost [127.0.0.1]) by ebola.biohz.net (Postfix) with SMTP id 1BE3D1152FA; Tue, 18 Jun 2002 16:18:30 -0700 (PDT) Message-ID: <00c501c2171e$7538a720$011211ac@biohz.net> From: "Renaud Waldura" To: "Mike Tancsa" Cc: References: Subject: Re: tracking down strange MTU issues with PPPoE) Date: Tue, 18 Jun 2002 16:18:29 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Section 6.3 of the following document describes this issue in detail and may help you solve it. http://renaud.waldura.com/doc/freebsd/pppoe/ ----- Original Message ----- From: "Tom Samplonius" To: "Mike Tancsa" Cc: Sent: Tuesday, June 18, 2002 3:09 PM Subject: Re: tracking down strange MTU issues with PPPoE) > > Well, if you need to find the MTU, the ppp logs should tell you what the > remote end is telling you to use. > > Usually, if you are having a MTU problem, it relates to fragmentation, > MTU detection and ICMP filters. FreeBSD uses MTU detection by default. > However, MTU detection requires that ICMP "can't fragment" messages be > received, and some broken sites filter all ICMP. I know that the Redback > has an "ignore don't fragment" feature. If this is enabled, it will > fragment packets, it would normally throw away. This feature will break > MTU detection too, but at least the end user won't notice, and packets > will flow. > > > Tom > > > On Tue, 18 Jun 2002, Mike Tancsa wrote: > > > > > The DSL whole supplier we use (Bell Canada) has been turfing their Redback > > SMSes and moving to an ERX from unisphere networks. > > > > With the Redback, all was great... I had a FreeBSD box acting as a NAT > > gateway for a number of Windows boxes and all was great. Then, the > > customer got moved over to one of these ERXes and there is now some strange > > MTU problem. Couple of things. Supposedly the default MTU on the ERX is > > 1472 (or 1452) depending on who you talk to and not 1492. > > > > e.g. when doing a fetch to > > >> lynx2.8.4rel.1.tar.bz2 doesn't seem to exist in /usr/ports/distfiles/. > > >> Attempting to fetch from http://lynx.isc.org/current/. > > Receiving lynx2.8.4rel.1.tar.bz2 (1940531 bytes): 0%^C > > 16682 bytes transferred in 89.5 seconds (186.41 Bps) > > fetch: transfer interrupted > > > > Notice the speed... Its totally brutal. yet, a transfer from just a few > > hops away is fine. > > > > My question is, how can I track this problem down ? There seems to be some > > strange interaction with FreeBSD because if I put a Windows box on the > > other end, it does not suffer from this same problem. I can easily repeat > > the problem, but the question is, how can I track down the issue and then > > explain it to my telco. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message