From: "U.Mutlu" <for-gmane@mutluit.com>
To: netfilter@vger.kernel.org
Subject: Re: [nfqueue] verdict NF_ACCEPT doesn't continue
Date: Wed, 30 Nov 2011 16:48:02 +0100 [thread overview]
Message-ID: <jb5j7j$7bh$1@dough.gmane.org> (raw)
In-Reply-To: <alpine.LNX.2.01.1111301108410.19102@frira.zrqbmnf.qr>
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...
next prev parent reply other threads:[~2011-11-30 15:48 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 [this message]
[not found] ` <8509432a-b261-412c-8688-705014007520@email.android.com>
2011-11-30 18:34 ` U.Mutlu
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='jb5j7j$7bh$1@dough.gmane.org' \
--to=for-gmane@mutluit.com \
--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