*** This message was also posted on the MPD mailing list ***

OK. This is a bit funny.

Now I can definitely say that the problem relates to Windows XP's 1400 bytes
MTU on PPP not going to well with the 1396 bytes MTU on NG-interfaces.

Suddenly I could not reproduce the problem - and my IPFILTER logs showed
maximum packets of 1300 bytes.
It seems that a newly installed Cisco VPN client had altered MTU settings on
all interfaces in XP - Physical as well as logical.

After digging a bit I found the MTU of NdisWan (used for PPP) in Windows
Registry - and it was set to 1300.
The value was set here:
"HKEY_LOCAL_MACHINE\System\CurrentControlSet\ServicesNdisWan\Parameters\Prot
ocols\0\ProtocolMTU"

Setting it back to the default 1400 recreated the problem whereas setting it
to 1396 solved it again.

Archie: do you still need logs?
Looking around a bit on the net brings me to believe that XP does not even
use Path MTU Discovery on the NdisWan-interface but simply sets a static
value of 1400 bytes.

All other interfaces either have static MTU set here:
"HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Inter
faces\[Adapter ID]"

Or they have PMTUD enabled here:
"HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Enabl
ePMTUDiscover"

However, enabling the PMTU does only seem to affect my physical interfaces -
not the NDISWAN/PPTP.

So it seems clear to me that there IS an MTU conflict - and although I could
easily solve it on my setup by changing XP's MTU I believe that this is
quite a mouthful for all existing XP users ;o)

/Martin

-----Original Message-----
From: Manuel Kasper [mailto:mk at neon1 dot net] 
Sent: 28. marts 2004 19:40
To: Martin Holst
Cc: m0n0wall at lists dot m0n0 dot ch; steven at honson dot org
Subject: Re: [m0n0wall] Re: Beta version 1.1b1 available

On 28.03.2004 15:27 +0200, Martin Holst wrote:

> I believe that the problems browsing through a PPTP-tunnel are
> MTU-related. I would still like to know if this IS a bug or not?
> (Manuel?)

OK, based on this feedback, I decided to investigate this issue, and
was able to reproduce it. It is a bug, but like countless other
times, 

*it is not a bug in m0n0wall itself*,

but in MPD.

>  - PPTP access from DMZ to LAN is OK
>  - PPTP access from WAN to LAN is OK
>  - PPTP access from DMZ to WAN fails due to MTU-related problem.

In addition to the MTU handshaking bug between XP and MPD, it looks
like ipnat has troubles calculating the checksum for the "ICMP
unreachable - need to frag" packets, which might be why path MTU
discovery fails too, even with Internet hosts that do not block ICMP
packets (while it works with LAN hosts - no ipnat there). ipfilter
3.4.32 was supposed to fix that ("checksum adjustment corrections for
ICMP & NAT") though (and m0n0wall 1.1b1 uses ipfilter 3.4.33).

Anyway - turns out that this patch:
<http://sourceforge.net/mailarchive/message.php?msg_id=6759334>
kinda "solves" the problem. Steven has confirmed this too. It even
works if you only add 4 instead of 6 bytes in that MRU calculation.

XP likes to request an MSS of 1360 (corresponding to a packet size of
1400 bytes) when it opens a TCP connection through the PPTP tunnel -
1400 is the MRU that XP and MPD decide upon during LCP negotiation,
but MPD subtracts 4 bytes from that figure for MPPE and MPPC
(encryption/compression) overhead - that's why it sets ng1's MTU to
1396. The question is: who's right? It's probably time to dig out the
packet sniffer and see how much additional overhead there is in
reality. In case it helps, MPD performs those overhead calculations
in bund.c in the function BundUpdateParams().

To me, the patch mentioned above doesn't look like the proper way to
solve this problem, and it could create problems with PPPoE (where
MPD is used as well).

I'm quite weary of fixing other people's software, so for now I'll
leave it to those who really want that kind of PPTP setup working to
find a solution. Maybe it's as simple as posting a message to the MPD
mailing list, explaining the situation - I don't know. Sometimes I
wonder if we'd have been better off using /usr/sbin/ppp and poptop...
But targeting embedded platforms calls for efficiency - something
userland PPP cannot provide.

BTW, I also noticed that the recent ng_pptpgre patch to disable the
PPTP ACK window mechanism (and therefore resolve the packet loss
problem) caused a performance drop by disabling delayed ACKs
(surprise, surprise)... But probably still better than 50% packet
loss.

And before anyone asks - no, MPD 3.17 does not solve this problem
either.

- Manuel