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>