MTU setting and PPPoe connection

A few days ago I had posted that I was having problem on computers on my
LAN accessing some websites (security.debian.org, microsoft.com, etc.).
The problem was that the LAN laptop was working with MTU=1500. It is a
dual boot, WinXP and Debian Unstable.

In Windows, I changed the MTU values of the NIC permamently so that
works okay. However, in Debian, the default OS, I am not able to do so.
I tried putting "mtu 1490" in /etc/network/interfaces but that doesn't
take effect:
~$ cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp
MTU 1490



WHen I boot, the laptop always has MTU=1500 and needs to be changed
manuallly:
$# ifconfig eth0 mtu 1490

1)How do I make this change permanent?

2) While reading about pppoe and MTU problems I disovered I can have a
rule in the FORWARD chain in iptables on my router machine (that
connects throug high speed modem and acts as a router) to fix this problem:
#--------------------------------------------
#now we use TCPMSS to clamp the MTU value to 1490. HS,18Oct2004.
$IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \
--clamp-mss-to-pmtu
#--------------------------------------------

But this doesn't help (I just do /etc/init.d/networking restart and it
reload the iptables script, do I need to restart the router computer?).

BTW, I also have in this same firewall script(copied from internet):
#--------------------------------------------
#added by HSS, 28Jul2003.
#(from http://194.242.45.189/robert/firewal...rules.ppp.html)
## FRAGMENTS
# I have to say that fragments scare me more than anything.
# Sending lots of non-first fragments was what allowed Jolt2 to
effectively "drown"
# Firewall-1. Fragments can be overlapped, and the subsequent
interpretation of such
# fragments is very OS-dependent.
# I am not going to trust any fragments.
# Log fragments just to see if we get any, and deny them too.
$IPTABLES -A INPUT -f -j LOG --log-prefix "IPTABLES FRAGMENTS: "
$IPTABLES -A INPUT -f -j DROP
#--------------------------------------------

Would this in anyway matter with the later rule of the TCPMSS?



Finally, I also discovered I can clamp the MTU to a lower value in
/etc/ppp/peers/dsl-provider by uncommenting this line:
#pty "/usr/sbin/pppoe -I eth0 -T 80 -m 1452"

But this also doesn't seem to solve the problelm.

Am I missing something here? Are the above two approaches
(iptables/dsl-provider) supposed work (one or the other)?

Thanks,
->HS

H. S. wrote:
>
> [snip]
>
> In Windows, I changed the MTU values of the NIC permamently so that
> works okay. However, in Debian, the default OS, I am not able to do so.
> I tried putting "mtu 1490" in /etc/network/interfaces but that doesn't
> take effect:
>

pppoe mtu is set in, usually, /etc/ppp/options, but you could use
/etc/ppp/options.<tty>, where <tty> is the interface you use for pppoe,
e.g., eth0.

Use two lines in options.

mtu 1492
mru 1492

"H. S." <(E-Mail Removed)> wrote:

> A few days ago I had posted that I was having problem on computers on
> my LAN accessing some websites (security.debian.org, microsoft.com,
> etc.). The problem was that the LAN laptop was working with
> MTU=1500. It is a dual boot, WinXP and Debian Unstable.

[..]

> BTW, I also have in this same firewall script(copied from internet):
> #--------------------------------------------
> #added by HSS, 28Jul2003.
> #(from http://194.242.45.189/robert/firewal...rules.ppp.html)
> ## FRAGMENTS
> # I have to say that fragments scare me more than anything.
> # Sending lots of non-first fragments was what allowed Jolt2 to
> effectively "drown"
> # Firewall-1. Fragments can be overlapped, and the subsequent
> interpretation of such
> # fragments is very OS-dependent.
> # I am not going to trust any fragments.
> # Log fragments just to see if we get any, and deny them too.
> $IPTABLES -A INPUT -f -j LOG --log-prefix "IPTABLES FRAGMENTS: "
> $IPTABLES -A INPUT -f -j DROP
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Try to remove this line from your firewall script. It might cause your
problems. Because I am curious: Is that your *complete* firewall script?

greetz,
haaner

Up-front: I haven't ever done PPPoE although I've come to know some
things about it since it uses pppd to establish the required PPP link.

H. S. <(E-Mail Removed)> wrote:
> A few days ago I had posted that I was having problem on computers on my
> LAN accessing some websites (security.debian.org, microsoft.com, etc.).
> The problem was that the LAN laptop was working with MTU=1500. It is a
> dual boot, WinXP and Debian Unstable.

> In Windows, I changed the MTU values of the NIC permamently so that
> works okay. However, in Debian, the default OS, I am not able to do so.
> I tried putting "mtu 1490" in /etc/network/interfaces but that doesn't
> take effect:
> ~$ cat /etc/network/interfaces
> # This file describes the network interfaces available on your system
> # and how to activate them. For more information, see interfaces(5).

Have you read man 5 interfaces?

> # The loopback network interface
> auto lo
> iface lo inet loopback

> # The primary network interface
> auto eth0
> iface eth0 inet dhcp
> MTU 1490

> WHen I boot, the laptop always has MTU=1500 and needs to be changed
> manuallly:
> $# ifconfig eth0 mtu 1490

> 1)How do I make this change permanent?

Do "grep -rs ifconfig /etc" to identify the script that actually configures
the Ethernet interfaces. This is Debian specific; I don't use Debian so
I can't say where it will be found. Or look at the script iface and see
what it is doing to configure the interfaces. I can *guess* that you need
"iface eth0 inet mtu 1490 dhcp" but can't guarantee that will work (the
dhcp is probably bogus, put there so no IP address needs to be assigned
to eth0).

> 2) While reading about pppoe and MTU problems I disovered I can have a
> rule in the FORWARD chain in iptables on my router machine (that
> connects throug high speed modem and acts as a router) to fix this problem:
> #--------------------------------------------
> #now we use TCPMSS to clamp the MTU value to 1490. HS,18Oct2004.
> $IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS \
> --clamp-mss-to-pmtu
> #--------------------------------------------

> But this doesn't help (I just do /etc/init.d/networking restart and it
> reload the iptables script, do I need to restart the router computer?).

It should work for TCP/IP, that rule is an example taken from man
iptables. SYN negotiation between hosts determines the MSS that
each host will use, and the rule will limit the MSS negotiated by
hosts behind the router to the Path MTU. Doing that is equivalent
to changing the MTU of those hosts to the router MTU or less.

> BTW, I also have in this same firewall script(copied from internet):
> #--------------------------------------------
> #added by HSS, 28Jul2003.
> #(from http://194.242.45.189/robert/firewal...rules.ppp.html)
> ## FRAGMENTS
> # I have to say that fragments scare me more than anything.
> # Sending lots of non-first fragments was what allowed Jolt2 to
> effectively "drown"
> # Firewall-1. Fragments can be overlapped, and the subsequent
> interpretation of such
> # fragments is very OS-dependent.
> # I am not going to trust any fragments.
> # Log fragments just to see if we get any, and deny them too.
> $IPTABLES -A INPUT -f -j LOG --log-prefix "IPTABLES FRAGMENTS: "
> $IPTABLES -A INPUT -f -j DROP
> #--------------------------------------------

> Would this in anyway matter with the later rule of the TCPMSS?

I don't know, but I do know that I wouldn't add rules to a firewall
script unless I knew what effect they would have on the existing rules.

> Finally, I also discovered I can clamp the MTU to a lower value in
> /etc/ppp/peers/dsl-provider by uncommenting this line:
> #pty "/usr/sbin/pppoe -I eth0 -T 80 -m 1452"

> But this also doesn't seem to solve the problelm.

> Am I missing something here? Are the above two approaches
> (iptables/dsl-provider) supposed work (one or the other)?

I *think* which one should work depends on whether you are using the
rp-pppoe.so from the rp-pppoe package or the one from the pppd package.
You can uncomment the line in dsl-provider if you use adsl-start, but
otherwise you likely need to use iptables.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/

Apparently, _Clifford Kite_, on 22/10/04 12:26,typed:

>
>
> Have you read man 5 interfaces?

Yes, well almost all of it. But with the dhcp method, it doesn't talk
about specifying the mtu value.




> "iface eth0 inet mtu 1490 dhcp" but can't guarantee that will work (the


Man page of interfaces doesn't tell me this is supposed to happen. Or I
am missing something here.


>
>
> I *think* which one should work depends on whether you are using the
> rp-pppoe.so from the rp-pppoe package or the one from the pppd package.
> You can uncomment the line in dsl-provider if you use adsl-start, but
> otherwise you likely need to use iptables.
>

I am using pppoe 3.5-4. I will have a look there.

Thanks for the comments,
->HS

H. S. <(E-Mail Removed)> wrote:
> Apparently, _Clifford Kite_, on 22/10/04 12:26,typed:

>> Have you read man 5 interfaces?

> Yes, well almost all of it. But with the dhcp method, it doesn't talk
> about specifying the mtu value.

You shouldn't be required to do DHCP with PPPoE. I believe the IP
address that's needed for PPPoE is almost always negotiated by pppd
since it's for the PPP interface not the Ethernet interface.

>> "iface eth0 inet mtu 1490 dhcp" but can't guarantee that will work (the

> Man page of interfaces doesn't tell me this is supposed to happen. Or I
> am missing something here.

I don't use Debian and was guessing at what iface did, remember?
Everything on that line can be an ifconfig parameter except dhcp.
Ifconfig is required to bring up the Ethernet interface, which doesn't
need an IP address (well, you could also use iproute2).

>> I *think* which one should work depends on whether you are using the
>> rp-pppoe.so from the rp-pppoe package or the one from the pppd package.
>> You can uncomment the line in dsl-provider if you use adsl-start, but
>> otherwise you likely need to use iptables.

I've dug a little deeper and there seems to be no provision for
clamping in the rp-pppoe.so plugin that comes with pppd. So you are
likely using that plugin since the clamping line was commented out.
There aren't any man pages for the pppd plugin, although there should
be since it appears there are several parameters for it that are
equivalent to some for the RP plugin (both the pppd and RP plugin
have the same name, rp-pppoe.so, but differ).

I have to backtrack on the comment regarding adsl-start. You may be
able to do PPPoE Discovery with the RP pppoe executable using the -d
option and then start pppd to handle the traffic for a PPPoE session.

> I am using pppoe 3.5-4. I will have a look there.

Good Luck.

--
Clifford Kite Email: "echo xvgr_yvahk-(E-Mail Removed)|rot13"
PPP-Q&A links, downloads: http://ckite.no-ip.net/