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.
tag 330973 upstream help thanks 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.
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.
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
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