netfilter buglog - Dec 2004 - [Bug 40] system hangs, Availability problems, maybe conntrack bug, possible reason here.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=40





------- Additional Comments From netfilter@linuxace.com  2004-12-30 20:16 MET
-------
Any further word on this?  Bug report is getting stale...

-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=40





------- Additional Comments From pmccurdy@net-itech.com  2005-01-06 20:38 MET
-------
Created an attachment (id=71)
 -->
(https://bugzilla.netfilter.org/bugzilla/attachment.cgi?id=71&action=view)
Patch to fix lockup 

Here is a patch to fix the problem.  My colleague Peter Zion (who deserves all
the credit for tracking this down and fixing it) sent a message to
netfilter-devel about this, but I can't find it in the archive, so
here's a
copy of it:

Subject: [PATCH] PPTP connection tracking: fixed oops during PPTP connect when
interface under heavy load

Summary:

If PPTP connection tracking is running on a machine and certain PPTP
packets arrive out of order, or preceding packets never made
it to the machine, the PPTP connection tracking code will
dereference NULL pointers.  Reproduction steps are to attempt PPTP connections
to the machine on an interface under heavy load.

Reproduction:

1. Set up the vulnerable machine NATing a shared external connection to the
local network and with a PPTP daemon running that allows connections from
the external network.  It must have PPTP connection tracking enabled.

2. On a machine on the local network for which the vulnerable machine is
acting as a gateway to the external network, run hping2 about 8-15 times
simultaneously, until your ping response is around 500-800ms but with less
than 50% packet loss.  Use the following options: "hping2 -2 --destport 123
--keep -d 100 -i u1 <external address>", where <external
address> is a machine
on the external network that won't mind being flooded for a few minutes.

3. On a machine on the external network, repeatedly make a PPTP
connection to the vulnerable machine.  In our experience the vulnerable
machine will oops about one in three PPTP connection attepts.


-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=40





------- Additional Comments From pmccurdy@net-itech.com  2005-01-06 21:55 MET
-------
Created an attachment (id=72)
 -->
(https://bugzilla.netfilter.org/bugzilla/attachment.cgi?id=72&action=view)
Tools to help reproduce the problem

Here is a tool we developed to help us reproduce the problem.  There's the
source code, as well as some versions compiled for Debian (it runs on my Debian
stable workstation, and it should run on unstable as well).  To either compile
or run, you'll need the WvStreams library; the precompiled versions need
WvStreams 4.0, but it should compile against just about any version of the
library.  This library is probably available through your distribution, or you
can get it from http://open.nit.ca/wiki/index.php?page=WvStreams .  The code is
pretty simple, you could rewrite it pretty quickly if either of those options
isn't going to work for you.

To use these:
You need 3 computers. 
System 1 [eth0]<-LAN->[eth0] Vulnerable Server 2
[eth1]<-Internet->[eth1]
System 3
This should work alright as long as "Vulnerable Server 2" is doing NAT
with the
PPTP conntrack patches. Systems 1 and 3 can probably be anything you want.

Run the server on System 3, poking a hole on TCP/1723 in any firewall(s), if
needed (run as ./pptpdietest_srv)

Run the client on System 1 as: while true; do ./pptpdietest_cli
ip_of_server:1723; done
(Note: the client is really dumb: if you don't specify a port number, it
won't
print an error, but won't connect either)

Within a minute or two, on server 2, you should see a kernel panic (fail),
warning messages about an "invalid csum" (pass), or warnings about a
NULL GRE
conntrack keymap (pass).

-- 
Configure bugmail:
https://bugzilla.netfilter.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.