netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brad Fisher <brad@info-link.net>
To: Gregor Maier <gregor@net.in.tum.de>
Cc: Netfilter Development Mailinglist <netfilter-devel@lists.netfilter.org>
Subject: Re: libnetfilter_queue man page
Date: Tue, 21 Feb 2006 12:10:00 -0600	[thread overview]
Message-ID: <43FB5778.2050301@info-link.net> (raw)
In-Reply-To: <43FB47CE.8030003@net.in.tum.de>

Gregor Maier wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>   
>> -----------------
>> nfq_set_verdict()
>> -----------------
>>
>> Prototype:
>> 	int nfq_set_verdict(struct nfq_q_handle *qh, u_int32_t id, u_int32_t verdict, u_int32_t data_len, unsigned char *buf)
>>
>> Parameters:
>> 	qh			Netfilter queue handle obtained by call to nfq_create_queue().
>> 	id			ID assigned to packet by netfilter.  Can be obtained by: 
>> 					int id;
>> 					struct nfqnl_msg_packet_hdr *ph = nfq_get_msg_packet_hdr(tb);
>> 					if (ph) id = ntohl(ph->packet_id);
>> 	verdict		Verdict to return to netfilter
>> 					NF_ACCEPT	- Accept the packet
>> 					NF_DROP		- Drop the packet
>> 					???			- anything else possible? (ie. continue?,
>> 									jump? goto? log?)
>>     
> After digging through kernel source I'm pretty sure, that the only
> possible verdicts are
> NF_DROP, NF_ACCEPT
> NF_REPEAT  (queue the packet to userspace again) --> may lead to loops
> NF_QUEUE   same as NF_REPEAT. There's a differnce between the handling
> of NF_QUEUE and NF_REPEAT, but I don't know what this difference leads to.
>
> Why? When a packet is queued to userspace it "leaves" the current hook
> (e.g. the filter table) for good therefore it's not possible to continue
> with the next rule in the current chain or to jump to another chain.
>
> Maybe you also want to take a look at the Netfilter Hacking Howto, esp.
> section 3 (netfilter architecture)
>
> btw: thank's for the manpage
>
>   
Glad to hear someone has found it useful :)
You are correct, I also came to the conclusion that those are the only 
verdicts available.  The NF_REPEAT verdict seems to send the packet back 
through the entire chain/hook.  It doesn't start it at the next rule 
following the queue rule (which I'd like to have, but perhaps it's not 
possible).

BTW: I have had a chance to actually work with the library a bit, so I 
have updated my notes since I sent the previous message.  I didn't add 
much, just updated some of the questionable info.  If anyone is 
interested, I'll be glad to send them a copy.  So far the biggest issues 
I've run into are that marking doesn't work in 2.6.15 (I think it should 
in 2.6.16), and I can't seem to ever read the timestamp for a packet, no 
matter what hook it comes in on.  I've just been using gettimeofday for 
that for now.

-Brad
> cu
> gregor
> - --
> Gregor Maier                                      Lehrstuhl Informatik 8
> gregor@net.in.tum.de                              Tel: +49 89  289-18010
> http://www.net.in.tum.de                                     TU Muenchen
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFD+0fOdGiwgbikMYMRAqCxAJ4vBk3pXKiIe5p564wYkHgXtXU7yACdHTSt
> 1rg3M/wEsrggvlMrOC+KMTI=
> =GYqs
> -----END PGP SIGNATURE-----
>
>
> !DSPAM:3824,43fb47d3148949031012739!
>
>   

  reply	other threads:[~2006-02-21 18:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1139235549.30902.3.camel@localhost.localdomain>
2006-02-08 14:19 ` libnetfilter_queue man page Harald Welte
2006-02-08 17:12   ` Brad Fisher
2006-02-08 18:18     ` Brad Fisher
2006-02-21 17:03     ` Gregor Maier
2006-02-21 18:10       ` Brad Fisher [this message]
2007-02-27  8:05 Julien DHERSIN
2007-02-28 12:43 ` Pablo Neira Ayuso
2007-03-02 13:15   ` Julien DHERSIN
  -- strict thread matches above, loose matches on Subject: below --
2007-03-01 21:00 Jay Manni

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=43FB5778.2050301@info-link.net \
    --to=brad@info-link.net \
    --cc=gregor@net.in.tum.de \
    --cc=netfilter-devel@lists.netfilter.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;
as well as URLs for NNTP newsgroup(s).