Prev: Routing to multiple gateways from a single NIC
Next: DHCP client and ifconfig
From: Moe Trin on 5 Apr 2008 19:54
On Sat, 5 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in article
<cht8tf.0k7.ln(a)corncob.inetport.tld>, Clifford Kite wrote:

>Moe Trin <ibuprofin(a)painkiller.example.tld> wrote:

>> Looking at the man page or the source file for ~/pppd/options.c there
>> is no '-mru' option. The Changes-2.3 file stated for 2.3.0
>
>Hi Moe!

Hi Clifford!

>Man pages don't always include dated options while the source may but
>not always where one would expect.

You caught me there - I knew the option was still included, as pppd
would be barfing otherwise. I thought that option was in ppps/options.c
with the rest of the mess. ;-)

>~/shop/pppd/ppp-2.4.4/pppd$ grep -Irs '\-mru' .
>./lcp.c: { "default-mru", o_bool, &lcp_wantoptions[0].neg_mru,
>./lcp.c: { "-mru", o_bool, &lcp_wantoptions[0].neg_mru,

Ah well - learn something new.

>./pppd.8:.B default\-mru

Now that's the man page... OK - it's the title of an option. The
section reads:

.B default\-mru
Disable MRU [Maximum Receive Unit] negotiation. With this option,
pppd will use the default MRU value of 1500 bytes for both the
transmit and receive direction.
.TP

which turns out to read:

default-mru
Disable MRU [Maximum Receive Unit] negotiation. With this
option, pppd will use the default MRU value of 1500 bytes
for both the transmit and receive direction.

when displayed with the man command.

>Unfortunately I have nothing else to offer the OP in the way of help. :(
>But I would be suspicious of the Java applet. Or the new Java versions
>of M$:

I thought of that, except he indicated he got it working by setting the
MRU up to 1500.

I guess I tracked it down to the packet size again. Except this time
I needed to add -mru to /etc/ppp/options to get it working. Which
sets the MRU to 1500.

Now what he _could_ be seeing is different versions on a pool of servers
with the same name. Wouldn't be the first time that has occurred. I also
didn't understand (or comment upon) this item in his original post:

I generally run the network at an MTU of 576. If I don't connect
with my ISP at that MTU, it generally dials out again about every two
minutes. Any idea why it works on the router and not any computers
connecting through it?

To the O/P - if this is still a problem, I suggest running a packet
sniffer, or at least putting a command in /etc/ppp/ip.up that reads

/bin/netstat -anptu > /tmp/ppp.traffic

which will run that command when the link comes up. You MAY need to
precede it with a five or ten second 'sleep' command. If you have
tcpdump installed, you could use

/usr/sbin/tcpdump -ni ppp0 -c 20 -w /tmp/ppp.tcpdump

which will put the first twenty packets over the ppp0 interface into
a packet dump file named '/tmp/ppp.tcpdump'

Old guy
From: Shadow_7 on 5 Apr 2008 22:07
I guess I should clarify. The current router is running debian sarge.
About six months to a year and a half out of date. I used it a lot in
2006, but have gotten better machines since then. I set it up to replace
the old router in case of an unresolvable issue. Which is what it's
currently doing.

This replaced an older box with mobo battery issues and various other
upgrade issues. It originated from debian woody. As well as a video card
that likes to zap monitors out of commission. But it made a good router.
I've since replaced the battery and installed Debian Etch on it. But I've
yet to get the modem working on it. Every thing else on it is up to
baring a 2.6.24.x kernel that has the SA_INTERRUPT stuff replaced with
IRQF_Shared (+/- off the top of my head). Although not an issue in this
case as it's currently offline and not used.

Beyond that my laptop the one trying to play the game is on Debian Etch
and up to date for the most part. A new video driver out now, and
kernel 2.6.24.2 is no longer the most recent. The other game playing
desktop is running Knoppix 2007.0. With the most recent java from sun.
And various other boxes, but we'll leave them out of it for now.

I like dialing out to my ISP at an MTU of 576. This gives me the most
throughput and the best queueing of packets. At 576 I can download about
15MB per hour and things are more responsive. At 1500 I can download
about 12MB per hour. And pages with a lot of little pictures, ads, and
other things take upward of five minutes just to do the initial render
(mail.yahoo.com). I prefer to run at 576 given a choice.

In the past I worked around this same issue by changing my internal
network from 576 to 1500. Ethernet and wireless. And changed it back a
month later when it no longer seemed to be an issue with pogo. Now here's
the catch, since the current router is my old desktop, it has X and java
and all that jazz. Pogo works fine on it at 576. So there's probably some
greater issue with pppd versioning and NAT with iptables. Kernel 2.6.21 on
that box.

For this time around I not only had to adjust the internal network to
1500, but I had to connect to my ISP at that same packet size. AND I had
to up the mru, or at least explicitly state a value for it, where
previously it was just a commented line of configuration. I imagine that
I could set everything back to how it used to be in six weeks and all will
be fine again. With that one site and java applets.

I've also had packet size issues with other sites (tracfone.com). Where
that website wouldn't load at all until I changed my packet sizes. But I
think it too worked at one point six months later with the older
configuration. Now it may not be a packet size issue at all. All I know
is that making a change in the packet sizes seems to get things working
again. Normally I just touch the MTU (which is rough enough for windows).
But this time some effort on the MRU was needed. Now it may have been
something else, I did change a few things. But it seemed to start working
immediately after touching the MRU. I hope this clarifies it a bit.
From: Moe Trin on 6 Apr 2008 15:41
On Sat, 05 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <4Iednat_YaX4rWXanZ2dnUVZ_rzinZ2d(a)earthlink.com>, Shadow_7 wrote:

>I guess I should clarify. The current router is running debian sarge.
>About six months to a year and a half out of date.

Sarge - released 06 Jun 2005 - went through several updates.

>I've since replaced the battery and installed Debian Etch on it. But I've
>yet to get the modem working on it.

Etch - released in Apr 2007. Your 'sarge' box was probably running
ppp-2.4.3 (released November 2004), while 'etch' is almost certain to be
running ppp-2.4.4. The README file in 2.4.4 (which details changes made
since the previous versions) mentions adding /etc/ppp/ip-pre-up, fixing
bugs in the area of demand-dialed and persistent connections, and a
change in the rp-pppoe plugin. I don't _know_ of any significant changes
other than that - perhaps Clifford Kite has more to add.

>I like dialing out to my ISP at an MTU of 576. This gives me the most
>throughput and the best queueing of packets. At 576 I can download about
>15MB per hour and things are more responsive. At 1500 I can download
>about 12MB per hour. And pages with a lot of little pictures, ads, and
>other things take upward of five minutes just to do the initial render
>(mail.yahoo.com). I prefer to run at 576 given a choice.

MTU only speaks of traffic you are generating. Unless you are setting
the MRU, this shouldn't have a problem about packet size you are
receiving. I guess you are downloading tiny things (files less than
1450 bytes total), as normally the larger packets should be slightly
(about 6 percent) faster.

>In the past I worked around this same issue by changing my internal
>network from 576 to 1500. Ethernet and wireless. And changed it back a
>month later when it no longer seemed to be an issue with pogo. Now here's
>the catch, since the current router is my old desktop, it has X and java
>and all that jazz. Pogo works fine on it at 576. So there's probably some
>greater issue with pppd versioning and NAT with iptables.

The only thing that jumps out at me would be PMTU problems, and that could
be caused by firewall rules, where the last box on a 1500 byte MSS has to
fragment the packet for a subsequent 576 byte link. If that box is unable
to generate a ICMP Type 3 Code 4 error message OR routers between it and
the source are dropping ICMP, then the remote server will never hear
anything from "here", and time out the connection. Both problems are
common enough.

>For this time around I not only had to adjust the internal network to
>1500, but I had to connect to my ISP at that same packet size. AND I had
>to up the mru, or at least explicitly state a value for it, where
>previously it was just a commented line of configuration.

That's a bit of confusion. If your ppp link is not explicitly told to use
a smaller MTU/MRU, it should default to 1500 bytes. If it's coming up with
something less unless you include the '-mru' or 'default-mru' options,
then it's being told to request that lesser figure. You would see this in
the debug output from pppd

Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfReq id=0x1 <magic
0x8bab12d4> <pcomp> <accomp>]
Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfReq id=0x2 <mru 1524>
<auth pap> <pcomp> <accomp>]
Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfAck id=0x1 <magic
0x8bab12d4> <pcomp> <accomp>]
Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfAck id=0x2 <mru 1524>
<auth pap> <pcomp> <accomp>]

Here, this box asked only for 'magic', 'pcomp' and 'accomp' options,
while the peer (an ISP) asked for an MRU of 1524, PAP authentication,
'pcomp' and 'accomp' but no 'magic'. This means the link from the
ISP to here would have a MRU of 1500 (the default), while the link in
the opposite direction would have an MRU of 1524 (although this end
was not configured with the 'mtu 1524' option, so the packets sent
from this side would be a maximum of 1500 bytes - which is after all,
less than the requested maximum of 1524). When 'mru' is not
negotiated, the default value of 1500 applies. The pppd 'dump' option
should allow you to see if an 'mru' is being set at the command line or
one of the options files.

>I've also had packet size issues with other sites (tracfone.com). Where
>that website wouldn't load at all until I changed my packet sizes. But I
>think it too worked at one point six months later with the older
>configuration. Now it may not be a packet size issue at all. All I know
>is that making a change in the packet sizes seems to get things working
>again.

I'd be looking at the possibility of PMTU discovery problems - firewall
rules typically. Without being able to put a packet sniffer at both ends
of the link, all you would see here is the 3-way handshake went OK, and
perhaps one or a few small packets, then nothing.

>Normally I just touch the MTU (which is rough enough for windows).

If you mean setting the MTU in pppd, that only affects the size of the
packets you are sending, not the packets you will receive. If you are
setting the MTU on your local LAN (Ethernet or wireless), I can't see
why this would have any effect on packets over the ppp link (other than
sent packets being smaller). Even end-to-end packets on the dialin would
leave plenty of space between packets on the original 3Base5 Ethernet,
never mind the ancient (1984) 10 megabit Ethernet.

Old guy
From: Shadow_7 on 6 Apr 2008 18:40
>>I like dialing out to my ISP at an MTU of 576. This gives me the most
>>throughput and the best queueing of packets. At 576 I can download about
>>15MB per hour and things are more responsive. At 1500 I can download
>>about 12MB per hour. And pages with a lot of little pictures, ads, and
>>other things take upward of five minutes just to do the initial render
>>(mail.yahoo.com). I prefer to run at 576 given a choice.
>
> MTU only speaks of traffic you are generating. Unless you are setting
> the MRU, this shouldn't have a problem about packet size you are
> receiving. I guess you are downloading tiny things (files less than
> 1450 bytes total), as normally the larger packets should be slightly
> (about 6 percent) faster.

On dialup at least for earthlink not really the case. Granted that some
of the increased throughput is packet headers. But not to the tune of 3MB
per hour. 15% or more units of data per unit of time (guestimate).
Previous mru was unused. Negotiation with earthlink is CHAP. When I
initially set it up on the old router I found that I had to use passive in
/etc/ppp/options or NAT didn't work. To make it more complex, google.com
at http 1.1 loaded, at least the initial page via NAT across the network.
And sometimes search results. Where yahoo.com http 1.0 didn't. This was
quite a while ago. And just changing passive in pppd's options fixed it.
Traffic on the originating machine worked fine in that case too. As far as
pogo and tracfone issues of old, not having 1500 MTU's didn't mean that
they didn't load. But that loading them could take upwards of fifteen
minutes to load. With virtually nothing loaded in the first five minutes.
Under normal conditions they'd load entirely in under two minutes.


>>I've also had packet size issues with other sites (tracfone.com). Where
>>that website wouldn't load at all until I changed my packet sizes. But
>>I think it too worked at one point six months later with the older
>>configuration. Now it may not be a packet size issue at all. All I
>>know is that making a change in the packet sizes seems to get things
>>working again.
>
> I'd be looking at the possibility of PMTU discovery problems - firewall
> rules typically. Without being able to put a packet sniffer at both ends
> of the link, all you would see here is the 3-way handshake went OK, and
> perhaps one or a few small packets, then nothing.

Which describes the typical packet behavior when there's an issue.
Although nothing usually turned into something if you waited upwards of
fifteen minutes. Even this last spurt pogo games would load about one out
of twenty times, if you're waiting thirty minutes to three hours for it to
start after launching the game. Typically an initial burst of 17 to 33
packets then a long delay.

>>Normally I just touch the MTU (which is rough enough for windows).
>
> If you mean setting the MTU in pppd, that only affects the size of the
> packets you are sending, not the packets you will receive.

Yes, in the case of previous issues I only changed the MTU for packets on
the internal interfaces (eth0, wlan0) and left ppp0 untouched. Now when
the neice brings over her XBox 360 and wants to game online, I have to
change all MTU's to 1500. Otherwise it fails to even negotiate the
wireless connection to the router. Without 1500 on ppp0 it fails to
negotiate anything with the internet. Not that gaming with team speak
worked all that great once working. But it did work somewhat.
From: Andy Furniss on 6 Apr 2008 20:35
Shadow_7 wrote:

> Yes, in the case of previous issues I only changed the MTU for packets on
> the internal interfaces (eth0, wlan0) and left ppp0 untouched. Now when
> the neice brings over her XBox 360 and wants to game online, I have to
> change all MTU's to 1500. Otherwise it fails to even negotiate the
> wireless connection to the router. Without 1500 on ppp0 it fails to
> negotiate anything with the internet. Not that gaming with team speak
> worked all that great once working. But it did work somewhat.

Asking for a MRU < 1500 or setting MTU < 1500 on lan facing ifs is
asking for PMTUD problems. If you want 576 either mss clamp with
iptables & set 576 on ppp or set MTU to 576 on the client PCs (this will
affect packets both ways).

Other thoughts - IIRC ppp gets a 3 packet txqueuelength. This doesn't
usually hurt as devices tend to have fair sized buffers beyond ppp, but
maybe yours doesn't so it may be worth putting

ifconfig ppp0 txqueuelen 20

in /etc/ppp/ip-up.

If you get link layer packet loss on the wireless then that will hurt
throughput. If I had to use dialup today I would consider running
something like squid as a transparent proxy on the router.

Andy.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Routing to multiple gateways from a single NIC
Next: DHCP client and ifconfig