PPPoE, MTU, Linux

[clm]

I was trying to set up my Linux box to share my ADSL connection to my housemates and came across problems which, after googling for a bit, seem to be MTU related. My modem (Netgear DM602) is set to bridge mode and I'm running rp-pppoe to handle the connection.

In my /etc/ppp/peers/dsl-providers file I have these two lines:

pty "/usr/sbin/pppoe -I eth1 -T 80 -m 1452"
mtu 1452

Is there anything else I have to do? Computers behind the NAT can do small things (ping, small web pages) but not large things. Do I have to set the MTU of all the computers using the shared Internet to 1452 as well? That sounds a bit inconvenient, especially if a friend brings over a computer and wants to just plug it in and work.

I read on one of the other threads here that PPPoA doesn't have the overhead that PPPoE does and lets you have the full 1500 byte frames. But is it possible for my Linux box to do the PPPoA connection (keeping my Netgear thing in bridging mode)? I have a feeling that I can't do this -- because it's actually an Ethernet connection between the modem and my computer, and not an ATM connection.

Any clues?

Thanks,

Cameron

[clm]

*bump*

Anyone? DSL_Tech? I really want to get my Internet sharing box working. :-)

[Sadin]

I don't personally have any files under /etc/ppp/peers/*, but try checking your /etc/ppp/pppoe.conf file. Half way through should be an option saying:

CLAMPMSS=1412

uncomment that if it is commented, and comment the line saying:

CLAMPMSS=no

That should fix it. All your PCs behind the linux box that try send a bigger packet should get an ICMP MTU too large message and they will reduce their size. Here is an example with ping that proves this message comes from the gateway:
(ping of size 1470 should be able to get through if the mtu was 1500)

C:\>ping -f -l 1470 www.google.com

Pinging www.google.akadns.net [216.239.53.99] with 1470 bytes of data:

Reply from 10.0.1.1: Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 216.239.53.99:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms


If this doesn't seem to do the job, what exact problems are you having? because it may not be MTU related.

[Zoolander]

When using PPPOE and sharing the connection you either have to set every client computer to use a lower MTU, or you have to enable what's known as clamping. The roaring penguin software has it built in you just have to make sure it's set to be on, the configuration file is /etc/ppp/pppoe.conf usually like Sadin says.

If you use the kernel mode though you have to use iptables to do the clamping I made a post about it here

http://forum.swiftdsl.com.au/showthread.php?s=&threadid=1680

[clm]

I was just trying to get this to work again on the weekend. The MSS should be being clamped by rp-pppoe, as I am using the -m 1452 option to it. (I also tried 1412.) Should I be leaving ppp's mtu option at 1492? (This sets the MTU of the actual ppp interface, yes?)

When I use -m 1452, small packets get through but larger ones don't. When I drop it down to 1412 I can't get anything through at all. This is just on the host connected to the modem, not worrying about the machines NATed behind it yet.

I don't have an /etc/ppp/pppoe.conf, but I suspect the variables have the same effect as the command line options to rp-pppoe that Debian's dsl-provider pppd peers file is using.

How should I proceed in trying to diagnose the problem?

Thanks,

Cameron

[Zoolander]

I guess on one of your client computers you could try lowering the MTU to 1460 or something like that and seeing if that makes everything work, if it does the command line option just must not be working properly.

If you would like to know how to do that with windows it's not that hard you just have to edit the registry, i'd search on google if I was you to find out how to do it exactly.

If you do that and it still doesn't work it must be something else, just try loading web pages and stuff don't take too much notice of using large pings because of course large packets may need to be fragmented as you can't use an mtu of 1500 with pppoe, the max is 1492 and you should see that when you type in 'ifconfig'.

[clm]

Ok, but I get the large-packets-not-working problem on this Linux box connected to the modem. This is without any NATing or anything going on to any other computers. It is just:

Linux box running rp-pppoe <---(eth)---> ADSL modem

with the appropriate MSS clamping going on (or at least, it should be). On the Linux box I can type:

$ telnet www.google.com.au 80
GET http://www.google.com.au/ HTTP/1.0



and back comes part of the web page, after which it just stops. I also notice I can do things like ping Monash hosts, but not Unimelb ones. (This is with -m 1452. With -m 1412 nothing works.)

[Zoolander]

Ok i'm not sure what it could be but since you aren't even checking on a NATed client just on the actual box I don't think it's going to have anything to do with the clamping then as the clamping is only for when you share, there's no point doing it unless you are going to NAT so the problems must be from something else then, also it's for TCP so it has no bearing on ICMP or UDP etc. I'd try just turning it off completely to start with.

[clm]

Mmmm, ok, thanks for your help.

So if MSS is only specified for TCP segments and not, say, UDP datagrams, what happens if you are using a UDP-based program like ICQ which is behind a network with a low MTU?

[Zoolander]

Ok this is where it gets a bit above my head but my guess is that most programs that use UDP use small enough packets in the first place.

I could have a look with iptraf I guess but I remember that when you play say quake or starcraft or the like the size of the UDP packets never gets near 1500 usually alot lower but alot of that is a guess.

[Sadin]

MSS does not only refer to TCP. It refers to "IP" packets in general. UDP can still get fragmented, as fragmentation is a feature of the IP layer, so whatver you apply will apply to all IP packets regardless of their type.

[clm]

Really? I thought MSS, standing for "Maximum Segment Size" would apply only to TCP (TCP terminology being "segments").

Anyway, I have had no luck getting my modem to work properly in bridged mode in Linux. At the moment I have the modem in router mode with my Linux box set as the DMZ so that incoming connections to my mail/web/etc. servers work ok. It's not ideal, but it's working ok at the moment.

[Zoolander]

Originally posted by Sadin
MSS does not only refer to TCP. It refers to "IP" packets in general. UDP can still get fragmented, as fragmentation is a feature of the IP layer, so whatver you apply will apply to all IP packets regardless of their type.

Ok I stand corrected, that's good to know thanks. I assumed wrongly that it was TCP only because it's called TCPMSS.

EDIT: Hmm I looked around on google and most places seem to say it's only TCP that is effected by clamping but it's only TCP that usually has problems anyway.

[Zoolander]

You could take a look at this website and see what it says

http://www.speedguide.net/analyzer.php

It reports my MTU to be 1492 and my MSS to be 1452 and everything works fine for me. I wouldnt bother with the rest of the stuff on that site though I'm a firm believer in not messing with registries unless totally necessary =)

[taso]

Originally posted by Zoolander
You could take a look at this website and see what it says

http://www.speedguide.net/analyzer.php

It reports my MTU to be 1492 and my MSS to be 1452 and everything works fine for me. I wouldnt bother with the rest of the stuff on that site though I'm a firm believer in not messing with registries unless totally necessary =)

That same site says my MTU is 1460 whereas I know it's 1500.

[Sadin]

Originally posted by taso
That same site says my MTU is 1460 whereas I know it's 1500.

Your PC may be 1500, but your intermediate device (i.e. your bridged linux box if you have one, or your ADSL modem) is reducing your MTU size. So the site is probably right.

As I explained earlier in this thread, try doing:

ping -f -l 1400 www.google.com

and then keep increasing the value until you get a "Packet needs to be fragmented" message. When you see this message, the first one will be accompanied by the IP address of the device that is telling your PCs MTU is too high and to reduce it.

[taso]

Originally posted by Sadin
Your PC may be 1500, but your intermediate device (i.e. your bridged linux box if you have one, or your ADSL modem) is reducing your MTU size. So the site is probably right.

As I explained earlier in this thread, try doing:

ping -f -l 1400 www.google.com

and then keep increasing the value until you get a "Packet needs to be fragmented" message. When you see this message, the first one will be accompanied by the IP address of the device that is telling your PCs MTU is too high and to reduce it.


The intermediate device is a 741ge, PPPoA encapsulation with a MTU of 1500.

Nonetheless, throwing a large ping packet at the intermediate routers to a problem destination produces some interesting results. Some respond to the ping, some don't respond at all, some actually respond with "fragmentation needed".

(I don't remember what -f means on DOS ping - I presume it's not flood ping.)

[Gnuthad]

Originally posted by taso
(I don't remember what -f means on DOS ping - I presume it's not flood ping.)

It sets the DNF (Do Not Fragment) flag in the IP options