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

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

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

  parent reply	other threads:[~2006-02-21 17:03 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 [this message]
2006-02-21 18:10       ` Brad Fisher
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=43FB47CE.8030003@net.in.tum.de \
    --to=gregor@net.in.tum.de \
    --cc=brad@info-link.net \
    --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).