Anton VG wrote:
> Pablo,
> A little update, just tried non-patched variant with blocking, the
> only difference is - it generated ERROR only once and hanged (waiting
> for data)
> Any update from you?

Yes, I got a trace of the problem (with blocking behaviour):

userspace                       kernelspace
create queue (seq=x) --->
add iptables rule    --->
                     <--- (seq=0) packet sent
verdict (seq=x+1)    --->
                     <--- (seq=0) packet sent
verdict (seq=x+2)    --->
                     <--- (seq=x) ACK message

Then, it hits EILSEQ. The patch attached applies to libnfnetlink, it
sets the sequence number for messages if we expect to receive an answer
from kernelspace. With it, I can hit ENOBUFS (that's normal), but not
EILSEQ anymore.

With non-blocking behaviour, you may still hit EILSEQ (even with the
patch applied) since the current API does not allow non-blocking queue
creation.

BTW, why don't open one socket handler per queue? That will reduce the
chances to hit ENOBUFS. Now the problem for you would be that you'll
have a lot of descriptors in userspace to handle (probably select() is
not the best choice anymore) but more netlink bandwidth in return.

-- 
"Los honestos son inadaptados sociales" -- Les Luthiers