comp.os.linux.networking

On Fri, 04 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article , Shadow_7 wrote:

>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.

In your original post you stated this is Debian Etch and this is a dialup
connection. I'm not using Etch, but the latest version of pppd is 2.4.4
available at ftp://ftp.samba.org/pub/ppp

-rw-r--r-- 1 ftp ftp 688763 Jun 28 2006 ppp-2.4.4.tar.gz

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

* Pppd options beginning with - or + have been renamed, e.g. -ip
became noip, +chap became require-chap, etc. The old options are
still accepted for compatibility but may be removed in future.

though there never was a "nomru" option. There is a

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.

which might be suitable. However, without the 'mru' option, pppd
should default to 1500, so I'm not sure why things are changing for you.
You might try temporarily adding the 'dump' option

dump With the dump option, pppd will print out all the option
values which have been set. This option is like the dryrun
option except that pppd proceeds as normal rather than
exiting.

to see if something is "helping" you by screwing with the MRU.

>I'm not quite sure why I have to keep changing my configuration to
>maintain a connection with this one website. On the local machines the
>MTU is still 576. Having larger packet sizes really screws with the
>queuing of packets. And otherwise makes it feel and behave slower than
>it really is on this already slow shared dial-up connection.

Firewall issue?

1191 Path MTU discovery. J.C. Mogul, S.E. Deering. November 1990.
(Format: TXT=47936 bytes) (Obsoletes RFC1063) (Status: DRAFT
STANDARD)

2923 TCP Problems with Path MTU Discovery. K. Lahey. September 2000.
(Format: TXT=30976 bytes) (Status: INFORMATIONAL)

Those two RFCs (you can find them using any search engine) might explain
the problem. PMTU tries to discover the largest packet that can be sent
from "a" to "b". It does this by trying large packets with the "Don't
Fragment" flag set in the IP header. A host enroute that has a smaller
link MTU will send back an ICMP Type 3 Code 4 message ("Fragmentation
needed, but don't fragment bit set"), but some router may be dropping
ICMP packets (because they think it improves security or something).
The result is effectively a black hole. You can detect this using
a packet sniffer - you'll see the 3-way handshake establishing the
connection, maybe one or two additional packets, and then nothing.

Another possible problem (nearly unheard-of now) is ECN packet drops.
When the 2.4.0 kernel was released in 2000, it included ECN by default,
and some routers on the Internet were dropping packets with the (then
comparatively unknown) ECN flag bit set in the IP header. There was a
kernel work-around, of sticking a zero into /proc/sys/net/ipv4/tcp_ecn
but that was over six years ago, and I can't believe someone could be
still running ancient versions of router software.

I'm not sure why you are having queuing problems. Setting MTU to a
smaller figure _was_ done to improve interaction in FTP when there were
slow links (1980s), and _is_ done where you are running PPPoE links
(the PPPoE protocol adds 8 bits to a packet, and the maximum packet
size on standard Ethernet is 1500 octets - so PPPoE links have an
MTU set at 1492 to avoid fragmentation).

Old guy