[nfqueue] verdict NF_ACCEPT doesn't continue

[nfqueue] verdict NF_ACCEPT doesn't continue

[U.Mutlu]

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?

Re: [nfqueue] verdict NF_ACCEPT doesn't continue

[Eric Leblond]

[-- 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 --]

Re: [nfqueue] verdict NF_ACCEPT doesn't continue

[U.Mutlu]

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?

Re: [nfqueue] verdict NF_ACCEPT doesn't continue

[Jan Engelhardt]

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.

Re: [nfqueue] verdict NF_ACCEPT doesn't continue

[U.Mutlu]

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...

Re: [nfqueue] verdict NF_ACCEPT doesn't continue

[U.Mutlu]

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...

Re: [nfqueue] verdict NF_ACCEPT doesn't continue

[Jan Engelhardt]

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.