2003-11-30 19:21:44

by James Bourne

[permalink] [raw]
Subject: 2.4.23/others and ip_conntrack causing hangs

Hi all,
I wanted to bring up an issue with ip_conntrack in 2.4.23, 2.4.22, and at
least 2.4.21 (sorry, didn't try 2.4.20).

The issue is that as long as there are connections being tracked, the
ip_conntrack module will not unload. I can understand why this might be,
but the problem is that ip_conntrack will hang rmmod and modprobe -r until
such time as all the connections have been closed.

I think we need something like an ip_conntrack_flush or else completely drop
the connections when the module is unloaded (as previously done) as this
becomes an issue for people who need to drop their ip_tables and reload the
modules (perhaps to correct other issues) especially ip_conntrack...

The only way to reload the modules right now (yes, I know removing modules
from a running kernel is dodgey anyway) is to completely drop the network
interfaces which kills off the connections *anyway*. So, dropping the
connections shouldn't be an issue.

Thanks for the consideration.

Regards
James

--
James Bourne | Email: [email protected]
Unix Systems Administrator | WWW: http://www.hardrock.org
Custom Unix Programming | Linux: The choice of a GNU generation
----------------------------------------------------------------------
"All you need's an occasional kick in the philosophy." Frank Herbert


2003-12-01 01:56:07

by Rusty Russell

[permalink] [raw]
Subject: Re: [netfilter-core] 2.4.23/others and ip_conntrack causing hangs

In message <[email protected]> you writ
e:
> Hi all,
> I wanted to bring up an issue with ip_conntrack in 2.4.23, 2.4.22, and at
> least 2.4.21 (sorry, didn't try 2.4.20).
>
> The issue is that as long as there are connections being tracked, the
> ip_conntrack module will not unload. I can understand why this might be,
> but the problem is that ip_conntrack will hang rmmod and modprobe -r until
> such time as all the connections have been closed.
>
> I think we need something like an ip_conntrack_flush or else completely drop
> the connections when the module is unloaded (as previously done) as this
> becomes an issue for people who need to drop their ip_tables and reload the
> modules (perhaps to correct other issues) especially ip_conntrack...

Um, this is exactly what the code does on unload: an explicit flush.

Unfortunately, some packets are still referencing connections, so the
module *cannot* go away. Figuring out exactly where the packets are
referenced from is the fun part. We explicitly drop the reference in
ip_local_deliver_finish() for exactly this reason. Perhaps there is
somewhere else we should be doing the same thing.

Hope that clarifies,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.