Debian Bug report logs - #432709
pppoeconf not setting correct MTU

version graph

Package: pppoeconf; Maintainer for pppoeconf is Gregory Colpart <reg@debian.org>; Source for pppoeconf is src:pppoeconf.

Reported by: Miguel Martins Feitosa Filho <mfeitosa@certificadoranorte.com.br>

Date: Wed, 11 Jul 2007 14:18:01 UTC

Severity: normal

Tags: moreinfo

Found in version pppoeconf/1.16

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Gregory Colpart (evolix) <reg@evolix.fr>:
Bug#432709; Package pppoeconf. Full text and rfc822 format available.

Acknowledgement sent to Miguel Martins Feitosa Filho <mfeitosa@certificadoranorte.com.br>:
New Bug report received and forwarded. Copy sent to Gregory Colpart (evolix) <reg@evolix.fr>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Miguel Martins Feitosa Filho <mfeitosa@certificadoranorte.com.br>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: pppoeconf not setting correct MTU
Date: Wed, 11 Jul 2007 10:16:48 -0400
Package: pppoeconf
Version: 1.16
Severity: important

Hi,

This problem could either be pppoeconf or debian installer related.
It is a problem related to the correct configuration of 
/etc/ppp/peers/provider relative to the MTU setting. 
I believe the MTU issue has been discussed very intensly but the issue caught
me by surprise.

I performed a Debian testing install with net-inst, my internet link is
pppoe.
Debian installer configured pppoe, I assume the installer uses
pppoeconf but that might not be the case.
The system being installed is a small office gateway.
PPPOE came up correctly and was fine during the installation process.
After reboot, internet showed intermittent problems from the other
office computers but not from the gateway itself. The internet worked on
the gateway and not from the other computers in the office.
The problem was intermittent, ping worked, telnet worked, google worked,
other internet sites hanged etc.
This problem was tracked down after a long time to the lack of MTU
setting in my ppp provider file. After running pppoeconf a couple times,
I finally got a configuration that worked for all computers...

tatarana:/home/mfeitosa# cat /etc/ppp/peers/dsl-provider 
# Minimalistic default options file for DSL/PPPoE connections

noipdefault
defaultroute
replacedefaultroute
hide-password
#lcp-echo-interval 30
#lcp-echo-failure 4
noauth
persist
mtu 1492
plugin rp-pppoe.so eth2
user "auser@brturbo.com"

I have only very limited knowledge on ppp and pppoe so the questions
below may seem trivial:

A) Should pppoeconf set the mtu ? (Mine was commented out). Is there
a situation where pppoe links do not use the MTU when they are
forwarding packets?
B) Do all pppoe links need this limitation ?
C) How  can a novice user be aware of this problem, should pppoeconf
warn him 
D) Is their any test that could be done by pppoeconf on the link to
assert the need for this setting and a reasonable value
E) Is the 1492 limitation correct for all pppoe links? When will it be
higher, when will it be lower?

I spent many many hours reviewing my kernel, iptables and other gateway
settings and it never occurred to me that the pppoe link could be
dropping TCP/IP packets coming from the other computers and not from the
gw itself. 

What was also a problem is that I have configured many dozen pppoe systems on
other linux variants, debian and windows and this setting was never a problem.

How where the other configurators solving the MTU setting?

The aim of this bug report is to help find a way for other novice users
to not get stuck on this setting like I did.

Thank you,
Miguel Feitosa




-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.18-4-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages pppoeconf depends on:
ii  gettext-base                  0.16.1-1   GNU Internationalization utilities
ii  modconf                       0.3.3      Device Driver Configuration
ii  ppp                           2.4.4rel-9 Point-to-Point Protocol (PPP) daem
ii  sed                           4.1.5-2    The GNU sed stream editor
ii  whiptail [whiptail-provider]  0.52.2-10  Displays user-friendly dialog boxe

Versions of packages pppoeconf recommends:
ii  locales                       2.5-9      GNU C Library: National Language (

-- no debconf information



Information forwarded to debian-bugs-dist@lists.debian.org, Gregory Colpart (evolix) <reg@evolix.fr>:
Bug#432709; Package pppoeconf. Full text and rfc822 format available.

Acknowledgement sent to Gregory Colpart <reg@evolix.fr>:
Extra info received and forwarded to list. Copy sent to Gregory Colpart (evolix) <reg@evolix.fr>. Full text and rfc822 format available.

Message #10 received at 432709@bugs.debian.org (full text, mbox):

From: Gregory Colpart <reg@evolix.fr>
To: 432709@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#432709: pppoeconf not setting correct MTU
Date: Sat, 14 Jul 2007 02:38:28 +0200
severity 432709 normal
tags 432709 moreinfo
thanks

Hi,

On Wed, Jul 11, 2007 at 10:16:48AM -0400, Miguel Martins Feitosa Filho wrote:
> 
> This problem could either be pppoeconf or debian installer related.
> [...]
> I performed a Debian testing install with net-inst, my internet link is
> pppoe.
> Debian installer configured pppoe, I assume the installer uses
> pppoeconf but that might not be the case.

debian-installer doesn't use pppoeconf. If you want report
bugs for it, please report against ppp-udeb package.


> The system being installed is a small office gateway.
> PPPOE came up correctly and was fine during the installation process.
> After reboot, internet showed intermittent problems from the other
> office computers but not from the gateway itself. The internet worked on
> the gateway and not from the other computers in the office.
> The problem was intermittent, ping worked, telnet worked, google worked,
> other internet sites hanged etc.
> This problem was tracked down after a long time to the lack of MTU
> setting in my ppp provider file. After running pppoeconf a couple times,
> I finally got a configuration that worked for all computers...

Your problem is typical when you have a gateway with PPPoE
connection and Ethernet LAN. You must clamp the TCP maximum
segment size (MSS) at 1452 (or 1412) to avoid too big size for
your Ethernet packets. When you use pppoe support in the kernel
(like you), pppoeconf add an iptables rule in your
/etc/ppp/ip-up.d/0clampmss file. When your use userland pppoe,
pppoeconf adjust '-m MSS' option in your dsl-provider file.

Then, pppoeconf takes care of this problem in 'LIMITED MSS
PROBLEM' step. Please read this step more carefully.


> I have only very limited knowledge on ppp and pppoe so the questions
> below may seem trivial:
> 
> A) Should pppoeconf set the mtu ? (Mine was commented out). Is there
> a situation where pppoe links do not use the MTU when they are
> forwarding packets?

- See MTU of your ppp* interface with ifconfig command. MTU is
  often determined via MRU negotiation with your ISP. pppoeconf
  let ppp do this mechanism and it's OK with a commented value
  for mtu pppd option by default.
- You misundertand what is MTU. See docs on web, for example:
  http://en.wikipedia.org/wiki/Maximum_transmission_unit
  MTU is always use by an interface.


> B) Do all pppoe links need this limitation ?

- MTU of PPPoE can't be higher than 1492 (RFC 1661).
  See RFC 4638 for discuss about exceptions.


> C) How  can a novice user be aware of this problem, should pppoeconf
> warn him

- pppoeconf warns user in 'LIMITED MSS PROBLEM' step.


> D) Is their any test that could be done by pppoeconf on the link to
> assert the need for this setting and a reasonable value

- In 'LIMITED MSS PROBLEM' step, pppoeconf says "If unsure, say
  yes." and with clamping MSS at 1452 bytes, it will be OK for a
  very large majority of users. If you have an idea to guess the
  best settings, send me your patch ;)


> E) Is the 1492 limitation correct for all pppoe links? When will it be
> higher, when will it be lower?

- See above.


I think you should read docs about MTU and MSS. I will close
this bug except you describe a real problem with pppoeconf.


Regards,
-- 
Gregory Colpart <reg@evolix.fr>  GnuPG:1024D/C1027A0E
Evolix - Informatique et Logiciels Libres http://www.evolix.fr/



Severity set to `normal' from `important' Request was from Gregory Colpart <reg@evolix.fr> to control@bugs.debian.org. (Sat, 14 Jul 2007 00:42:02 GMT) Full text and rfc822 format available.

Tags added: moreinfo Request was from Gregory Colpart <reg@evolix.fr> to control@bugs.debian.org. (Sat, 14 Jul 2007 00:42:03 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Gregory Colpart (evolix) <reg@evolix.fr>:
Bug#432709; Package pppoeconf. (Thu, 30 Oct 2008 23:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter <webwiz@pl.net>:
Extra info received and forwarded to list. Copy sent to Gregory Colpart (evolix) <reg@evolix.fr>. (Thu, 30 Oct 2008 23:18:02 GMT) Full text and rfc822 format available.

Message #19 received at 432709@bugs.debian.org (full text, mbox):

From: Peter <webwiz@pl.net>
To: 432709@bugs.debian.org
Subject: Same mss not working issue
Date: Fri, 31 Oct 2008 12:13:45 +1300
I have the same problem, mss clamp isnt working.

I dont know which i have kernal or user, i just did 
  aptitude install pppoe pppoeconf 
on a up to date etch box.

then at the mss clamp pppoeconf dialog i said yes, clamp to 1452. However the dsl-provider file did not uncommment any of the pppoe lines as it says it should in 

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=425448

8<--------------------------------
#pty "pppoe -I eth0 -T 80"
pty "pppoe -I eth0 -T 80 -m 1452"
#pty "pppoe -I eth0 -T 80 -m 1412"
8<--------------------------------

Nor does it add any pppoeconf adjust '-m MSS' to provider file.

" When you use pppoe support in the kernel
(like you), pppoeconf add an iptables rule in your
/etc/ppp/ip-up.d/0clampmss file. "

This file exists but does not appear to be invoked anywhere.

find /etc -name '*clamp*'
/etc/ppp/ip-down.d/0clampmss
/etc/ppp/ip-up.d/0clampmss

grep '0clampmss' /etc -r

nada

grep '1452' /etc -r

/etc/ppp/peers/dsl-provider:#pty "/usr/sbin/pppoe -I eth0 -T 80 -m 1452"
/etc/ppp/peers/dsl-provider:# don't work using -m 1452...

more nada 

iptables -L FORWARD -vn
Chain FORWARD (policy ACCEPT 4208 packets, 933K bytes)
 pkts bytes target    prot opt in   out  source      destination
 9467 4393K Accounting 0   --  *    *   0.0.0.0/0    0.0.0.0/0
 5259 3460K ACCEPT     0  --  ppp0  *   0.0.0.0/0     0.0.0.0/0  state   RELATED,ESTABLISHED
    0     0 ACCEPT     tcp  --  ppp0   *  0.0.0.0/0     0.0.0.0/0      tcp dpt:18802 state NEW
    0     0 Firewall   0    --  ppp0   *   0.0.0.0/0      0.0.0.0/0     state INVALID,NEW


How do i tell which mode im using?
Is the package broken or did i use it wrong?

And could the man page be clearer about mss, the two references seem to conflict, one says (vaguely) about using mss and further down the other says you should change your lan clients aswell. mss is a hack but seems to be a necessary evil with pppoe.

Lastly is there a definitive pppoe on debian howto any place?

Thanks

Peter








Information forwarded to debian-bugs-dist@lists.debian.org, Gregory Colpart (evolix) <reg@evolix.fr>:
Bug#432709; Package pppoeconf. (Fri, 31 Oct 2008 00:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter <webwiz@pl.net>:
Extra info received and forwarded to list. Copy sent to Gregory Colpart (evolix) <reg@evolix.fr>. (Fri, 31 Oct 2008 00:21:02 GMT) Full text and rfc822 format available.

Message #24 received at 432709@bugs.debian.org (full text, mbox):

From: Peter <webwiz@pl.net>
To: 432709@bugs.debian.org
Subject: Same mss not working issue
Date: Fri, 31 Oct 2008 13:17:39 +1300
Just to clarify im running this on a gateway box (like theres many other reasons id be using pppoe)

Actually the rule(s) are there, MY MISTAKE:

iptables-save > fw.txt
less fw.txt
-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1412 -j
TCPMSS --clamp-mss-to-pmtu
-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:15
36 -j TCPMSS --clamp-mss-to-pmtu
-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1452 -j
TCPMSS --clamp-mss-to-pmtu

Why theres three, i couldnt say. One for every eth1 restart i guess. Thats not good, shouldnt it check for the rule existing before adding it again. Or remove it at if-down. I dont know what effect the 3 rules would have, so i edit the 0clampmss file to say 1412 then reboot the box.

Now ive got one rule 

-A FORWARD -o ppp0 -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1412 -j
TCPMSS --clamp-mss-to-pmtu

But still dont know how to specify mss value in pppoeconf. 

Anyway so then i remove the mtu=1492 patch from the lan client, and...

Problem recurs, http-post hangs.

Windows XP (mtu 1500) ping test:

pings ok up to 1464 bytes, 
1465 - 1472 inclusive 'request timed out',
1473+ return 'needs fragment but df set'. 

Do i need to go even lower with mss? Or is something else likely the cause?

Firewall maybe? Ive got ICMP type 3 allowed incoming.

Regards

Peter




Information forwarded to debian-bugs-dist@lists.debian.org, Gregory Colpart (evolix) <reg@evolix.fr>:
Bug#432709; Package pppoeconf. (Sat, 01 Nov 2008 00:39:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Peter <webwiz@pl.net>:
Extra info received and forwarded to list. Copy sent to Gregory Colpart (evolix) <reg@evolix.fr>. (Sat, 01 Nov 2008 00:39:02 GMT) Full text and rfc822 format available.

Message #29 received at 432709@bugs.debian.org (full text, mbox):

From: Peter <webwiz@pl.net>
To: 432709@bugs.debian.org
Subject: Same mss not working issue
Date: Sat, 01 Nov 2008 13:36:33 +1300
Ok, my problem is solved. The rule pppoe inserts doesnt work when the pppoe is a 'pppoe pass trough' feature found in Draytek Vigor series of modems. THis is because the modems translation from pppoa to pppoe sheilds the correct operation of mss negotiation. Hence :

--clamp-mss-to-pmtu 

does not work and you must specify the mss manually.

In my case modifying the rule to:

iptables -t mangle -I FORWARD 1 -p tcp --tcp-flags SYN,RST SYN \
 -j TCPMSS --set-mss 1444

works and further documentation of this issue can be found here:

http://wiki.linux.net.nz/Draytek%20Vigor

As far as pppoeconf goes, you are never going to be able to cover every situation, and so you probably shouldnt try. Instead of installing that rule, i would suggest not installing one at all ( especially as theres no mention at all of it doing so, and say read "here" for advice about adding a rule to your ruleset. The pppoe mss step is dated and there is no longer any ref at all to mss in dsl-provider (excpet for the misleading commented lines which dont do anything in the default kernal mode). Hence the suggestion to try 1412 if you have troubles is not clear given there is no where to set this anymore and even if you choose yes, the mss rule DOES NOT clamp mss to 1452 as stated but uses --clamp-mss-to-pmtu , and in some instances this method will fail.

Thanks.

P.





Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 12:06:03 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.