On Fri, 13 Aug 2004, Fred Mol wrote:
> 
> I stared at some tcpdumps after the last freeze and I noticed the same
> problems as before: packets from m0n0wall -> internet on the ng0 interface
> don't have corresponding packets on the interface that talks to the adsl modem.

Unfortunately, to get an idea of the cause, you'd need to collect packets
from *before* the freeze.  That means you either need to be prepared for a
*humongous* amount of data, or you need to be able to capture to a
circular buffer.  Ethereal (and tethereal) can do the latter, but tcpdump
can't AFAIK.  Both have the option to use multiple files in order to limit
the size of an individual file.

> Apparently when the packets are dropped, the transmit window is full, or
> at least the pptp module thinks it's full. By disabling windowing, packets
> are always sent, regardless of the transmit window. If we assume that the
> transmit window is not really full, but the whole flow control has somehow
> gotton out of sync, that option should fix the problem.

Exactly.  What's of interest is what the last SEQ and ACK numbers were
prior to the freeze.  And whether there's something "interesting" like
32-bit wraparound at that point, or the other direction's being blocked by
windowing.

On Sat, 14 Aug 2004, Manuel Kasper wrote:

> This makes sense, because the kernel in 1.1b17 now includes the
> ng_pptpgre.c/.h from -STABLE, which has a new parameter for the
> ng_pptpgre node to turn windowing on/off, whereas with the previous

Sounds like buggy PPTP implementations abound. :-) Disabling windowing
violates RFC2637, but may be necessary to get around broken receivers.

There *should* have been an option in the protocol to allow the *receiver*
to disable windowing when it's not needed (e.g. by letting 0 mean infinity
in the call setup).  The main reason it exists is to avoid choking
userland PPTP implementations with too much data.  In an implementation
like ng_pptpger, where the handling happens in the kernel, I see no reason
to throttle the sender at all.  Since m0n0wall's MPD can't specify this
directly, perhaps it should just do the next best thing and offer 65535 as
the receive window.  Or perhaps 32767 to get around broken peers that
incorrectly treat the window as a signed number (like some SCO TCPs :-)).

> This means I'll disable windowing for the WAN PPTP client altogether
> in 1.1-release.

That should probably still be optional, for a couple of reasons:

1) Making something RFC-noncompliant unconditionally seems like a bad idea
in general.

2) Since there really is a bottleneck on the other side of the modem,
there's a risk that some modems might get in trouble with unrestricted
sending.  For example, I know that the SpeedTouch's webserver can be
killed (to the point of needing to power-cycle the modem) by making
connections to it too quickly, either by nmap or by a browser configured
for too many simultaneous connections; it's not too much of a stretch to
imagine a modem running out of buffer space if it's "constipated" with
excessive upstream traffic.

Since the RTT to the modem is very small, it's unlikely that windowing has
any adverse impact on performance except when it screws up (and has a
*big* impact on performance :-)).  This differs from VPN PPTP, where
insufficient window can limit throughput.


BTW, was the conflict between the WAN PPTP client and the PPTP server ever
resolved?

					Fred Wright