comp.os.linux.networking

On Sat, 05 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <4Iednat_YaX4rWXanZ2dnUVZ_rzinZ2d@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 0x8bab12d4> ]
Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfReq id=0x2
]
Jul 3 09:55:27 gtech pppd[924]: rcvd [LCP ConfAck id=0x1 0x8bab12d4> ]
Jul 3 09:55:27 gtech pppd[924]: sent [LCP ConfAck id=0x2
]

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