ip_queue problem (and ip_conntrack DoS)

James Morris jmorris@intercode.com.au
Mon, 10 Jul 2000 13:50:22 +1000 (EST)


On Mon, 10 Jul 2000, Alexander Demenshin wrote:

> 	But, problem can be reproduced easily - as shown above - just make _a lot_ of connections
> 	in short time (at rate > 100/sec).
> 	
> 	I think that problem is related to ip_queue module, because I can reproduce it
> 	_only_ when I use QUEUE target (and when packets are processed and accepted in userspace).
> 	In fact it may be somewhere else - may be ip_conntrack*? (Problem does not exist in
> 	case if I have other targets - except QUEUE).

It seems to work ok here.  Do you still get a lockup if ip_conntrack is
not loaded (and do you have nat loaded?).

> 	
> 	BTW, what may happen if set_verdict is not accepted by kernel and is never retried
> 	in userspace (as in my case - sometimes it return error like "Not enough buffer space")?

If ipq_read() gets an error, as in this case, the packet will be
dropped.  The module knows that the underlying recvfrom() syscall had an
error.  If it's something caused by a userspace coding error (e.g.
invalid verdict), you'll get an error message back from the module and the
packet will remain in the queue.

- James
--
James Morris
<jmorris@intercode.com.au>