nfq_set_verdict() or nfq_set_verdict2():
NF_DROP discard the packet
NF_ACCEPT the packet passes, continue iterations
In my callback I pass NF_ACCEPT to let the packet continue its travel
through the subsequent rules (normal iptables rules).
but the packet doesn't reach the subsequent rules.
The "obvious" explanation for that behavour would of course be
when not NF_ACCEPT but NF_DROP had been passed to the verdict routine.
But it's not the case. So, then NF_ACCEPT seems to behave anormal here,
that's mysterious.
Here's my script:
...
iptables -A INPUT -p all -j NFQUEUE --queue-num 4711
iptables -A INPUT -p all -j LOG --log-prefix "DEBUG ALL "
...
# iptables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
...
NFQUEUE all -- 0.0.0.0/0 0.0.0.0/0 NFQUEUE num 4711
LOG all -- 0.0.0.0/0 0.0.0.0/0 LOG flags 0 level 4 prefix "DEBUG ALL "
...
The logging normally functions well, but when NFQUEUE is active
then logging of the received packets mysteriously stops.
# uname -a
Linux s7 3.0.0-1-rt-amd64 #1 SMP PREEMPT RT Sat Aug 27 17:34:31 UTC 2011 x86_64 GNU/Linux
int grcCB = 0;
static int cb(struct nfq_q_handle* qh, struct nfgenmsg* nfmsg, struct nfq_data* nfa, void* pUserData)
{ // this callback func is called from nfq_handle_packet()
bool fDrop = false;
const u_int32_t id = process_pkt(nfa, fDrop);
return grcCB = nfq_set_verdict(qh, id, fDrop ? NF_DROP : NF_ACCEPT, 0, NULL);
}
...
const int rv = recv(fd, buf, sizeof(buf), 0); // is blocking!
if (rv >= 0)
{
if (nfq_handle_packet(h, buf, rv) == 0)
{
//...
}
else
{
printf("ERR: rc of handle_packet is %d\n", grcCB);
}
}
nfq_set_verdict gives 0 and hence the "ERR" line doesn't get executed ever.
Is this a bug of the library or do I need to use something different than NF_ACCEPT?
What about the last 2 params of nfq_set_verdict, could they be the reason?
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
