On Thu, 22 Jul 2004, neotjah wrote:

> You were most likely letting the modem do NAT. This explains why the modem
> hanged up, a lot of (home)-hardwarerouters have the same problem: A lot of
> connections, and it locks up. When the modem is in bridgemode, slap me if
> I'm wrong ;), it only passes data from one interface to the next. You could
> try to set the modem in bridgemode since you are behind the m0n0wall box.

While it's true that a NAT implementation with a limited number of entries
can get in trouble with a large number of connections, NAT is completely
orthogonal to the use of bridging.  You can choose whether to use the
modem's NAT feature (if available), but the usual choice between bridging
and PPTP is determined by the ISP.

> Van: lola at yais dot net [mailto:lola at yais dot net]
> Verzonden: woensdag 21 juli 2004 18:31
> 
> i had the same problems! and i discovered that resetting the modem solved
> the problem also. my dsl modem couldn't handle all the connections my
> filesahring tools made. i am know using traffic shaper to limit all outgoing
> traffic to 90% of my upload bandwidth. no more hangups since then.
> 
> > Von: "Fred Mol" <fredlist at xs4all dot nl>
> > Datum: Wed, 21 Jul 2004 18:20:03 +0200 (CEST)
> > 
> > lola at yais dot net said:
> >> this is a bandwith problem. your filesharing tools blow your dsl 
> >> modem with too many connections or with heavy uploads.
> > 
> > What do you mean with "blow your dsl modem". The modem has been used 
> > for over 2 years with a Linux box with a home-brew iptables firewall 
> > and I didn't see a single lockup. I've had three lockups last week 
> > with m0n0wall. BTW, I didn't have any lockups with m0n0wall 1.0, but I 
> > only used that for a few weeks, because that has problems with 
> > incoming pptp vpn connections from Windows XP.
> > 
> > Also, when the connection freezes, the only way to "unfreeze" it, is 
> > to restart the connection (i.e. restart mpd) _on m0n0wall_. The modem 
> > isn't touched at all. Stopping the filetransfers does not cure the the 
> > problem either.

The one common thing between "restarting the connection" and "resetting
the modem" is shutting down and restarting the PPTP link between m0n0wall
and the modem, which I suspect is where the problem lies.

> > So how can this be a bandwith problem or a modem problem? It looks 
> > like a software problem to me, and my primary suspect is mpd.

Actually not MPD per se.  With MPD, the forwarding of the "real" traffic
is done in the kernel as set up by MPD.  So the state information of
interest is really in the kernel.  Unfortunately, I don't know of an easy
way to look at it.

The fact that packets aren't being forwarded (I think you said that in
another post) doesn't mean that something is truly dead.  In spite of
nominally being a link-layer tunnel providing datagram service, PPTP has
its own windowing and acknowledgment mechanism (thank you, Microsoft).  
If the ACKs get too far behind, it's *not allowed* to forward additional
packets.  There's a timeout mechanism to recover from this, which is
probably what makes it be "slow" instead of "dead" when it gets in
trouble.

I suspect that there's a bug getting sequence and ACK numbers out of sync,
but it's not clear which end of the wire it's on.  A packet trace might
shed some light on it, though it might have to start from the
"working" state to make it clear who screwed up.

					Fred Wright