All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.