comp.os.linux.networking

On Sun, 06 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <44GdnZSEBprJzGTanZ2dnUVZ_vninZ2d@earthlink.com>, Shadow_7 wrote:

[I wrote]

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

The advantage of smaller packets is that this lessens the wait to be
able to stick in "competing" traffic. I've only seen that on simplex
links with highly interactive traffic. If you were downloading a huge
file (such as a kernel tarball), large packets would be the only way
to go. But if you are also trying to read Usenet at the same time, the
smaller packets allow traffic to co-exist better.

>Previous mru was unused. Negotiation with earthlink is CHAP

Authentication is not a factor here.

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

That doesn't sound right at-all. The ppp 'passive' option relates to
how your peer attempts to start a ppp _link_ with the peer at the other
end. Once the peer answers the initial '[LCP ConfReq' packet, the
option has no further effect. ON THE OTHER HAND, the 'passiv' option
may be desired with the 'ftp' file transfer protocol. That option to
ftp tells the remote ftp server to use the existing control connection
for data transfer rather than opening a separate data connection. That
simplifies the firewall setup significantly.

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

Both providers use a bewildering number of secondary page sources. I
can see where that would be a problem.

>This was quite a while ago. And just changing passive in pppd's
>options fixed it.

But I can't see that at all. Looking at the man page for pppd, that
option only effects the initial Link Control Protocol stage of setting
up a link (see also RFC1661 section 3.1). Once the link setup
progresses to the IP address negotiation stage (where the peers agree
on what IP addresses each will use), the next time you will use LCP
is when you are tearing down the link, and hanging up the phone.

>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 fiftee minutes to load. With virtually nothing loaded in the first
>five minutes. Under normal conditions they'd load entirely in under
>two minutes.

That still sounds like PMTU discovery problems.

>Yes, in the case of previous issues I only changed the MTU for packets
>on the internal interfaces (eth0, wlan0) and left ppp0 untouched.

When you do that, packets that you create are all "small", and they
stay that way. On the other hand, the rest of the world (more or less)
is generating packets on the assumption that everyone uses 1492 to
1500 octet MTUs, and if these can't be fragmented, your link is
isolated. On the box with the modem (which I expect is running your
iptables setup), I'd suggest looking at the rules you have
(/sbin/iptables -L) to see if there is anything related to the ICMP
protocol.

Old guy