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
diff --git a/src/libnfnetlink.c b/src/libnfnetlink.c
index d4212f9..5cfe2f5 100644
--- a/src/libnfnetlink.c
+++ b/src/libnfnetlink.c
@@ -418,7 +418,11 @@ void nfnl_fill_hdr(struct nfnl_subsys_handle *ssh,
nlh->nlmsg_type = (ssh->subsys_id<<8)|msg_type;
nlh->nlmsg_flags = msg_flags;
nlh->nlmsg_pid = 0;
- nlh->nlmsg_seq = ++ssh->nfnlh->seq;
+ /* set sequence number if we expect an answer from kernelspace */
+ if (msg_flags & (NLM_F_ACK | NLM_F_ECHO | NLM_F_DUMP))
+ nlh->nlmsg_seq = ++ssh->nfnlh->seq;
+ else
+ nlh->nlmsg_seq = 0;
/* check for wraparounds: assume that seqnum 0 is only used by events */
if (!ssh->nfnlh->seq)
