[ previous ] [ next ] [ threads ]
 From:  Omer Faruk Sen <ofsen at enderunix dot org>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: Beta version 1.1b1 available
 Date:  Tue, 30 Mar 2004 14:30:38 +0300
Is there an improvement about this problem? Or is it possible for us to be 
informed if any improvement happens.. 

Martin Holst writes: 

> Thanks a lot Manuel!
> It was nice to get some confirmation that I wasn't the only one experiencing
> the problem ;o) 
> I believe that Steven might already have contacted the MPD mailing list? 
> Once again: Thanks for responding so quick - and for digging thoroughly into
> the problem. 
> /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 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: m0n0wall dash unsubscribe at lists dot m0n0 dot ch
> For additional commands, e-mail: m0n0wall dash help at lists dot m0n0 dot ch 

Omer Faruk Sen
Software Development Team @ Turkey
For Public key: http://www.enderunix.org/ofsen/ofsen.asc