Debian Bug report logs - #330973
ppp: possible MTU problem when using mppe

version graph

Package: ppp; Maintainer for ppp is Marco d'Itri <md@linux.it>; Source for ppp is src:ppp.

Reported by: Alexander Weber <alex@weberclan.org>

Date: Fri, 30 Sep 2005 19:03:23 UTC

Severity: normal

Tags: help, upstream

Found in version ppp/2.4.3-20050321+2

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, alex@weberclan.org, Marco d'Itri <md@linux.it>:
Bug#330973; Package ppp. Full text and rfc822 format available.

Acknowledgement sent to Alexander Weber <alex@weberclan.org>:
New Bug report received and forwarded. Copy sent to alex@weberclan.org, Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

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

From: Alexander Weber <alex@weberclan.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: ppp: possible MTU problem when using mppe
Date: Fri, 30 Sep 2005 20:59:35 +0200
Package: ppp
Version: 2.4.3-20050321+2
Severity: normal

When using poptop as an VPN server for a Windows Client, the connection
is established without errors. Transmission of small packets seems to
work as well.
However, when transmitting large packets kern.log receives the message:

mppe_compress[1]: osize too small! (have: 1400 need: 1404)

ppp is configured to require 128-bit encryption.
Altering the MTU value in the pppd options file does not help. After
reducing the MTU by four bytes the messages changes to:

mppe_compress[1]: osize too small! (have: 1396 need: 1400)

So it seems ppp wants 4 more bytes regardless of what the MTU is set to.

What does help is enabling multilink in the pppd options. However, then
the pppd process does not terminate when the peer closes the connection,
requiring an manual "kill" to allow further connections.
The server connects with pppoe (DSL) line to the outside world and it's
VPN clients.

Search engine results indicate that pppd has to be patched in order to
resolve this issue.

I'm sorry if this happens to be a false bug report.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686-smp
Locale: LANG=de_DE@euro, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15)

Versions of packages ppp depends on:
ii  libc6                  2.3.2.ds1-22      GNU C Library: Shared libraries an
ii  libpam-modules         0.76-22           Pluggable Authentication Modules f
ii  libpam-runtime         0.76-22           Runtime support for the PAM librar
ii  libpam0g               0.76-22           Pluggable Authentication Modules l
ii  libpcap0.7             0.7.2-7           System interface for user-level pa
ii  makedev                2.3.1-77          creates device files in /dev
ii  netbase                4.21              Basic TCP/IP networking system
ii  procps                 1:3.2.1-2         The /proc file system utilities
ii  zlib1g                 1:1.2.2-4.sarge.2 compression library - runtime

-- no debconf information



Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#330973; Package ppp. Full text and rfc822 format available.

Acknowledgement sent to md@Linux.IT (Marco d'Itri):
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

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

From: md@Linux.IT (Marco d'Itri)
To: Alexander Weber <alex@weberclan.org>, 330973@bugs.debian.org
Cc: control@bugs.debian.org
Subject: Re: Bug#330973: ppp: possible MTU problem when using mppe
Date: Fri, 30 Sep 2005 21:05:27 +0200
[Message part 1 (text/plain, inline)]
tag 330973 upstream help
thanks

On Sep 30, Alexander Weber <alex@weberclan.org> wrote:

> mppe_compress[1]: osize too small! (have: 1400 need: 1404)
I do not use MPPE and do not know well how it works.
If you want to see this fixed please research the issue and provide a
patch.

-- 
ciao,
Marco
[signature.asc (application/pgp-signature, inline)]

Tags added: upstream, help Request was from md@Linux.IT (Marco d'Itri) to control@bugs.debian.org. Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#330973; Package ppp. Full text and rfc822 format available.

Acknowledgement sent to "Alexander P. Weber" <alex@weberclan.org>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. Full text and rfc822 format available.

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

From: "Alexander P. Weber" <alex@weberclan.org>
To: md@Linux.IT (Marco d'Itri)
Cc: 330973@bugs.debian.org, control@bugs.debian.org
Subject: Re: Bug#330973: ppp: possible MTU problem when using mppe
Date: Fri, 30 Sep 2005 23:49:44 +0200
>> mppe_compress[1]: osize too small! (have: 1400 need: 1404)
> I do not use MPPE and do not know well how it works.
> If you want to see this fixed please research the issue and provide a
> patch.

As much as I would like to - I'll not be able to provide a patch. I
could not find any suitable patch and my poor programming skills will
not suffice.
However, I have done some more tests. Maybe this will help someone.

1. Set MTU and MRU in pppd options to 1404
2. Leave Windows' MTU setting alone (according to M$, this results in a MTU setting of
1400 on VPN links)
3. Establish connection, transfer some chunks of data

As a result, kern.log contains:
osize too small! (have: 1400 need: 1404)

This makes me believe that it is Windows XP that is requesting an MTU
of 1400. The pppd man page states that the configured pppd mtu value
is ignored when the peer requests a smaller MTU size.
Forthermore, in the ppp sources in pppd/ccp.c around line 1190 (search
for "MPPE_PAD") pppd sets the interface's MTU to (original MTU - 4).
This seems correct, given that MPPE will add 4 bytes. 1396 plus 4
equals 1400 bytes - just right.

What I don't understand: When I set the interface's MTU to 1404
("ifconfig ppp1 mtu 1404" in my case) it seems to work. I cannot tell
if it has any impact on performance (fragmentation?), but at least the
errors are gone.

So I wonder:
- Why does it work?
- Is it a suitable fix to *not* reduce the MTU according to the peers
request?
- Will this break anything?

As a quick fix, it should be possible to add the "ifconfig pppX mtu"
command to a script file that is to be executed after the link has
been established.

BTW: This does also help with the pppd process that does not exit after the
link terminates, because the multilink option is not required anymore
and that particular problem only occurs with multilink allowed.

-- 
Mit freundlichen Grüßen / best regards
Alexander P. Weber





Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#330973; Package ppp. (Fri, 19 Apr 2013 18:45:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daniel Sokolowski <gro.naibed@danols.com>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Fri, 19 Apr 2013 18:45:04 GMT) Full text and rfc822 format available.

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

From: Daniel Sokolowski <gro.naibed@danols.com>
To: 330973@bugs.debian.org
Subject: Issue still present as of pppd version 2.4.5
Date: Fri, 19 Apr 2013 14:11:36 -0400
[Message part 1 (text/plain, inline)]
Issue still present as of pppd version 2.4.5 and when Windows 7 machine 
VPN is used, there appears to be two solutions:
1. This old patch - 
http://us.generation-nt.com/bug-273333-ppp-mppe-pmtud-breakage-workaround-patch-help-165417731.html which 
I lack experience on  how to implement.
2. Or as Alexander suggested using the ifconfig which I did.
For anyone having this problem here is my workaround ip-up script - 
http://danielsokolowski.blogspot.com/2013/04/mppecompress0-osize-too-small-have-1404.html
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Marco d'Itri <md@linux.it>:
Bug#330973; Package ppp. (Fri, 11 Oct 2013 12:21:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Helmut Grohne <h.grohne@cygnusnetworks.de>:
Extra info received and forwarded to list. Copy sent to Marco d'Itri <md@linux.it>. (Fri, 11 Oct 2013 12:21:05 GMT) Full text and rfc822 format available.

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

From: Helmut Grohne <h.grohne@cygnusnetworks.de>
To: Alexander Weber <alex@weberclan.org>, 330973@bugs.debian.org
Subject: Re: Bug#330973: ppp: possible MTU problem when using mppe
Date: Fri, 11 Oct 2013 14:08:48 +0200
On Fri, Sep 30, 2005 at 08:59:35PM +0200, Alexander Weber wrote:
> mppe_compress[1]: osize too small! (have: 1400 need: 1404)
> 
> ppp is configured to require 128-bit encryption.
> Altering the MTU value in the pppd options file does not help. After
> reducing the MTU by four bytes the messages changes to:
> 
> mppe_compress[1]: osize too small! (have: 1396 need: 1400)
> 
> So it seems ppp wants 4 more bytes regardless of what the MTU is set to.

Let me add a little detail here. The "need" value printed by the kernel
is bogus. Have a look at the relevant source:

drivers/net/ppp/ppp_mppe.c:
|        /* Make sure we have enough room to generate an encrypted packet. */
|        if (osize < isize + MPPE_OVHD + 2) {
|                /* Drop the packet if we should encrypt it, but can't. */
|                printk(KERN_DEBUG "mppe_compress[%d]: osize too small! "
|                       "(have: %d need: %d)\n", state->unit,
|                       osize, osize + MPPE_OVHD + 2);
|                return -1;
|        }

You can see that the value printed as "need" is not the one being
compared. Instead it is always 4 greater than the "have" value
regardless of the actual isize given. You might need to lower the MTU
even further.

Helmut



Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 13:25:00 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.