Prev: Routing to multiple gateways from a single NIC
Next: DHCP client and ifconfig
From: Moe Trin on 7 Apr 2008 15:54
On Sun, 06 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <44GdnZSEBprJzGTanZ2dnUVZ_vninZ2d(a)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
From: Clifford Kite on 7 Apr 2008 21:15
Shadow_7 <wwwShadow7(a)nospamyahoo.comnospam> 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.

If an XBox can't "negotiate the wireless connection to the router"
when wlan0 has a 576 MTU then it makes me wonder if an XBox is PMTU
Discovery enabled.

--
Clifford Kite
From: Shadow_7 on 8 Apr 2008 15:49
> If an XBox can't "negotiate the wireless connection to the router"
> when wlan0 has a 576 MTU then it makes me wonder if an XBox is PMTU
> Discovery enabled.

I think it was more that the XBox had an MTU of 1500 and no customization
of that value. Although I wasn't the one on the other end of the
controller making the changes. I don't run DHCP on the home network, so
everything is for the most part hard coded. Which is only an issue when
relatives come to visit with their tech gear. I'm probably more tech
savvy than them, just not tech current.
From: Moe Trin on 9 Apr 2008 16:01
On Tue, 08 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <TpSdnVo5VJ38UWbanZ2dnUVZ_qPinZ2d(a)earthlink.com>, Shadow_7 wrote:

>> If an XBox can't "negotiate the wireless connection to the router"
>> when wlan0 has a 576 MTU then it makes me wonder if an XBox is PMTU
>> Discovery enabled.
>
>I think it was more that the XBox had an MTU of 1500 and no customization
>of that value.

Next time your niece brings the XBox over, set the MTU on your LAN to
576, and then run /usr/sbin/tcpdump -n on that LAN side NIC. What you
are looking for is

12:34:56.780000 192.168.10.20.4283 > 192.168.33.55.53: S
1759784758:1759784758(0) win 60352 (DF)

which shows time, source_IP.port > destination_IP.port SYN_flag
sequence_number:sequence_number(0) window_size (DF)

and the key is the last item - the Don't_Fragment flag. If you see
that flag (Ethereal/wireshark would also show the flag, but in a more
user-friendly format), the system is set for PMTU discovery. In this
particular case, the LAN MTU was large enough to carry the packet
without fragmenting, and there would be subsequent packets from the
destination making the handshake. A bit later, this host is going to
send a packet that is to big (the number in parentheses following the
sequence number will be something greater than ~540), and what SHOULD
happen is that the "router" should send an ICMP Type 3 Code 4 error
indicating that the packet is to large. That one you may see (if you
don't, then you've discovered your problem is the router or relay
between the router and your local host), but if the remote host this
box is conversing with sends a packet that is to large, _IT_ should
receive a similar ICMP Type 3 Code 4 error (which you won't see as
it's directed at the remote). That remote host should send the reply
in a smaller packet (perhaps without the DF flag set).

Seeing as how many DSL setups are using PPPoE (which requires an
MTU of 1492 rather than the 1500 normally used), I'd really expect
the XBox to be ready to reset the packet size, or not use the DF
flag, but only if it receives that ICMP error. But conversations
are two-way, so both sides need to know about the lower than normal
MTU so that they can adjust for it.

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