From owner-freebsd-net Tue Jun 18 22:45:28 2002 Delivered-To: freebsd-net@freebsd.org Received: from tp.databus.com (p72-186.acedsl.com [66.114.72.186]) by hub.freebsd.org (Postfix) with ESMTP id 204BA37B400 for ; Tue, 18 Jun 2002 22:45:21 -0700 (PDT) Received: from databus.com (localhost.databus.com [127.0.0.1]) by tp.databus.com (8.12.3/8.12.3) with ESMTP id g5J5jKGC020184; Wed, 19 Jun 2002 01:45:20 -0400 (EDT) (envelope-from barney@databus.com) Received: (from barney@localhost) by databus.com (8.12.3/8.12.3/Submit) id g5J5jJFw020183; Wed, 19 Jun 2002 01:45:19 -0400 (EDT) Date: Wed, 19 Jun 2002 01:45:19 -0400 From: Barney Wolff To: Mike Tancsa Cc: Renaud Waldura , freebsd-net@FreeBSD.ORG Subject: Re: tracking down strange MTU issues with PPPoE) Message-ID: <20020619014519.A20138@tp.databus.com> References: <00c501c2171e$7538a720$011211ac@biohz.net> <5.1.0.14.0.20020618232129.0639eef8@192.168.0.12> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <5.1.0.14.0.20020618232129.0639eef8@192.168.0.12>; from mike@sentex.net on Tue, Jun 18, 2002 at 11:32:12PM -0400 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 There's something odd here - MSS does not include headers, and is 1460 on a straight ethernet connection. So your MSS of 1452 equates to an MTU of 1492. I'd try setting MTU (or MSS) way down, to 1024. If that works, you can do a binary search to find the max working value. You haven't shown enough of the dump to see if DF is set in packets from either the working or non-working host, or to see just how big the packets are. On Tue, Jun 18, 2002 at 11:32:12PM -0400, Mike Tancsa wrote: > > Looking at the TCPDump, to a host that works, I see > > iscar# tcpdump -n -i tun0 'tcp[13] & 2 != 0' > tcpdump: listening on tun0 > 23:21:37.506516 64.7.134.131.1029 > 199.212.134.1.80: S > 3285534554:3285534554(0) win 57344 59058 0> (DF) > 23:21:37.528294 199.212.134.1.80 > 64.7.134.131.1029: S > 2139469875:2139469875(0) ack 3285534555 win 65535 1,nop,nop,timestamp 67282456 59058> > > If I let this transfer go, I will see a good megabit + speeds. > > But to the host below (and from a non pppoe connection on the other side, I > get a good 5Mb/s), I see the following > > 23:21:45.400445 64.7.134.131.1030 > 204.152.184.112.80: S > 1898183196:1898183196(0) win 57344 59847 0> (DF) > 23:21:45.498440 204.152.184.112.80 > 64.7.134.131.1030: S > 1924929184:1924929184(0) ack 1898183197 win 61440 > > and the speed is a few hundred bytes /s > > But, when I do the same from my connection at home, I see the same sorts of > flags and speeds are as expected > > > > > > ---Mike > > > > At 04:18 PM 6/18/2002 -0700, Renaud Waldura wrote: > >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. > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message -- Barney Wolff I never met a computer I didn't like. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message