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