* [nfqueue] verdict NF_ACCEPT doesn't continue
@ 2011-11-30 7:58 U.Mutlu
2011-11-30 8:07 ` Eric Leblond
0 siblings, 1 reply; 7+ messages in thread
From: U.Mutlu @ 2011-11-30 7:58 UTC (permalink / raw)
To: netfilter
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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [nfqueue] verdict NF_ACCEPT doesn't continue
2011-11-30 7:58 [nfqueue] verdict NF_ACCEPT doesn't continue U.Mutlu
@ 2011-11-30 8:07 ` Eric Leblond
2011-11-30 8:53 ` U.Mutlu
0 siblings, 1 reply; 7+ messages in thread
From: Eric Leblond @ 2011-11-30 8:07 UTC (permalink / raw)
To: U.Mutlu; +Cc: netfilter
[-- Attachment #1: Type: text/plain, Size: 2646 bytes --]
Hello,
Le mercredi 30 novembre 2011 à 08:58 +0100, U.Mutlu a écrit :
> 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).
When NF_ACCEPT is issued, the packet is accepted for the current table.
It will then only be checked by rules in other tables.
BR,
> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [nfqueue] verdict NF_ACCEPT doesn't continue
2011-11-30 8:07 ` Eric Leblond
@ 2011-11-30 8:53 ` U.Mutlu
2011-11-30 10:09 ` Jan Engelhardt
0 siblings, 1 reply; 7+ messages in thread
From: U.Mutlu @ 2011-11-30 8:53 UTC (permalink / raw)
To: netfilter
Eric Leblond wrote, On 2011-11-30 09:07:
> Hello,
>
> Le mercredi 30 novembre 2011 à 08:58 +0100, U.Mutlu a écrit :
>> 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).
>
> When NF_ACCEPT is issued, the packet is accepted for the current table.
> It will then only be checked by rules in other tables.
I need to just inspect the hdrs and then let it continue its usual way.
What is needed to realize this functionality?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [nfqueue] verdict NF_ACCEPT doesn't continue
2011-11-30 8:53 ` U.Mutlu
@ 2011-11-30 10:09 ` Jan Engelhardt
2011-11-30 15:48 ` U.Mutlu
0 siblings, 1 reply; 7+ messages in thread
From: Jan Engelhardt @ 2011-11-30 10:09 UTC (permalink / raw)
To: U.Mutlu; +Cc: netfilter
On Wednesday 2011-11-30 09:53, U.Mutlu wrote:
> Eric Leblond wrote, On 2011-11-30 09:07:
>> Hello,
>>
>> Le mercredi 30 novembre 2011 à 08:58 +0100, U.Mutlu a écrit :
>>> 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).
>>
>> When NF_ACCEPT is issued, the packet is accepted for the current table.
>> It will then only be checked by rules in other tables.
>
> I need to just inspect the hdrs and then let it continue its usual way.
> What is needed to realize this functionality?
Figuring out a way what to do with the packet if the ruleset changes
while the packet is out in userspace for an indefinite time.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [nfqueue] verdict NF_ACCEPT doesn't continue
2011-11-30 10:09 ` Jan Engelhardt
@ 2011-11-30 15:48 ` U.Mutlu
[not found] ` <8509432a-b261-412c-8688-705014007520@email.android.com>
2011-12-04 21:02 ` Jan Engelhardt
0 siblings, 2 replies; 7+ messages in thread
From: U.Mutlu @ 2011-11-30 15:48 UTC (permalink / raw)
To: netfilter
Jan Engelhardt wrote, On 2011-11-30 11:09:
> On Wednesday 2011-11-30 09:53, U.Mutlu wrote:
>
>> Eric Leblond wrote, On 2011-11-30 09:07:
>>> Hello,
>>>
>>> Le mercredi 30 novembre 2011 à 08:58 +0100, U.Mutlu a écrit :
>>>> 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).
>>>
>>> When NF_ACCEPT is issued, the packet is accepted for the current table.
>>> It will then only be checked by rules in other tables.
>>
>> I need to just inspect the hdrs and then let it continue its usual way.
>> What is needed to realize this functionality?
>
> Figuring out a way what to do with the packet if the ruleset changes
> while the packet is out in userspace for an indefinite time.
Sorry, Jan, I don't get it. Why do you say the ruleset changes, it doesn't IMO.
I must be missing some important API-information I guess, if even such
a simple thing like reading the payload hdrs is not possible
w/o disturbing the normal flow.
I tried also NF_QUEUE, but the net result is the same like NF_ACCEPT, not what I need.
I need a simple "NF_RETURN", but that is undefined...
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [nfqueue] verdict NF_ACCEPT doesn't continue
[not found] ` <8509432a-b261-412c-8688-705014007520@email.android.com>
@ 2011-11-30 18:34 ` U.Mutlu
0 siblings, 0 replies; 7+ messages in thread
From: U.Mutlu @ 2011-11-30 18:34 UTC (permalink / raw)
To: netfilter; +Cc: Eric Leblond
Eric Leblond wrote, On 2011-11-30 17:09:
> Hello
>
>
> "U.Mutlu"<for-gmane@mutluit.com> a écrit :
>
>> Jan Engelhardt wrote, On 2011-11-30 11:09:
>>> On Wednesday 2011-11-30 09:53, U.Mutlu wrote:
>>>
>>>> Eric Leblond wrote, On 2011-11-30 09:07:
>>>>> Hello,
>>>>>
>>>>> Le mercredi 30 novembre 2011 à 08:58 +0100, U.Mutlu a écrit :
>>>>>> 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).
>>>>>
>>>>> When NF_ACCEPT is issued, the packet is accepted for the current
>> table.
>>>>> It will then only be checked by rules in other tables.
>>>>
>>>> I need to just inspect the hdrs and then let it continue its usual
>> way.
>>>> What is needed to realize this functionality?
>>>
>>> Figuring out a way what to do with the packet if the ruleset changes
>>> while the packet is out in userspace for an indefinite time.
>>
>> Sorry, Jan, I don't get it. Why do you say the ruleset changes, it
>> doesn't IMO.
>
> The fact ruleset can change is a generic problem that explain the lack of a real return.
>
>>
>> I must be missing some important API-information I guess, if even such
>> a simple thing like reading the payload hdrs is not possible
>> w/o disturbing the normal flow.
>>
>> I tried also NF_QUEUE, but the net result is the same like NF_ACCEPT,
>> not what I need.
>> I need a simple "NF_RETURN", but that is undefined...
>
>
> Looks like you could use a sniffing library like pcap?
>
> For advanced usage of nfq you can have a look at http://home.regit.org/2011/04/some-new-features-of-ips-mode-in-suricata-1-1beta2/
>
> BR,
I finally managed to get it working by marking the currently processed pkt and
reinjecting it with NF_REPEAT. This seems to do what I wanted/needed; still testing...
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [nfqueue] verdict NF_ACCEPT doesn't continue
2011-11-30 15:48 ` U.Mutlu
[not found] ` <8509432a-b261-412c-8688-705014007520@email.android.com>
@ 2011-12-04 21:02 ` Jan Engelhardt
1 sibling, 0 replies; 7+ messages in thread
From: Jan Engelhardt @ 2011-12-04 21:02 UTC (permalink / raw)
To: U.Mutlu; +Cc: netfilter
On Wednesday 2011-11-30 16:48, U.Mutlu wrote:
> Jan Engelhardt wrote, On 2011-11-30 11:09:
>> On Wednesday 2011-11-30 09:53, U.Mutlu wrote:
>>
>>> Eric Leblond wrote, On 2011-11-30 09:07:
>>>> Hello,
>>>>
>>>> Le mercredi 30 novembre 2011 à 08:58 +0100, U.Mutlu a écrit :
>>>>> 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).
>>>>
>>>> When NF_ACCEPT is issued, the packet is accepted for the current table.
>>>> It will then only be checked by rules in other tables.
>>>
>>> I need to just inspect the hdrs and then let it continue its usual way.
>>> What is needed to realize this functionality?
>>
>> Figuring out a way what to do with the packet if the ruleset changes
>> while the packet is out in userspace for an indefinite time.
>
> Sorry, Jan, I don't get it. Why do you say the ruleset changes, it
>doesn't IMO.
But it _could_ change while the packet is away. And that is the case you
have to protect against, somehow.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-12-04 21:02 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-11-30 7:58 [nfqueue] verdict NF_ACCEPT doesn't continue U.Mutlu
2011-11-30 8:07 ` Eric Leblond
2011-11-30 8:53 ` U.Mutlu
2011-11-30 10:09 ` Jan Engelhardt
2011-11-30 15:48 ` U.Mutlu
[not found] ` <8509432a-b261-412c-8688-705014007520@email.android.com>
2011-11-30 18:34 ` U.Mutlu
2011-12-04 21:02 ` Jan Engelhardt
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.