Linux Netfilter discussions
 help / color / mirror / Atom feed
From: "U.Mutlu" <for-gmane@mutluit.com>
To: netfilter@vger.kernel.org
Cc: Eric Leblond <eric@regit.org>
Subject: Re: [nfqueue] verdict NF_ACCEPT doesn't continue
Date: Wed, 30 Nov 2011 19:34:31 +0100	[thread overview]
Message-ID: <4ED67737.6030803@mutluit.com> (raw)
In-Reply-To: <8509432a-b261-412c-8688-705014007520@email.android.com>

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


  parent reply	other threads:[~2011-11-30 18:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2011-12-04 21:02         ` Jan Engelhardt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED67737.6030803@mutluit.com \
    --to=for-gmane@mutluit.com \
    --cc=eric@regit.org \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox