Date: Wed, 19 Jun 2002 08:24:58 -0400 From: Mike Tancsa <mike@sentex.net> To: Barney Wolff <barney@tp.databus.com> Cc: Renaud Waldura <renaud@waldura.com>, freebsd-net@FreeBSD.ORG Subject: Re: tracking down strange MTU issues with PPPoE) Message-ID: <5.1.0.14.0.20020619082306.059ac010@192.168.0.12> In-Reply-To: <20020619014519.A20138@tp.databus.com> References: <5.1.0.14.0.20020618232129.0639eef8@192.168.0.12> <Pine.BSF.4.05.10206181454460.23627-100000@misery.sdf.com> <00c501c2171e$7538a720$011211ac@biohz.net> <5.1.0.14.0.20020618232129.0639eef8@192.168.0.12>
next in thread | previous in thread | raw e-mail | index | archive | help
At 01:45 AM 6/19/2002 -0400, Barney Wolff wrote:
>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.
Hi,
I tried going way down to 512 and 576 and with the same results :-(
>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.
What flags should I use to provide the necessary info ? Unfortunately at
this level my knowledge is rather tenuous :(
---Mike
>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 <mss 1452,nop,wscale
> 0,nop,nop,timestamp
> > 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 <mss 1452,nop,wscale
> > 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 <mss 1452,nop,wscale
> 0,nop,nop,timestamp
> > 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 <mss 1452,nop,wscale 0>
> >
> > 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" <tom@sdf.com>
> > >To: "Mike Tancsa" <mike@sentex.net>
> > >Cc: <freebsd-net@FreeBSD.ORG>
> > >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.
--------------------------------------------------------------------
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5.1.0.14.0.20020619082306.059ac010>