From: Eric Leblond <eric@regit.org>
To: credzba@gmail.com
Cc: dorian33@o2.pl, netfilter@vger.kernel.org
Subject: Re: libnetfilter_queue issues
Date: Sat, 12 Jan 2013 20:04:01 +0100 [thread overview]
Message-ID: <1358017441.18655.1.camel@tiger2> (raw)
In-Reply-To: <CAOZ=-EUzjDe8YtZYZA_BjZt_cmP=ivcjUa6R5EecCmNZEEh0Rg@mail.gmail.com>
Hello,
On Sat, 2013-01-12 at 07:23 -0600, Felix wrote:
> excellent question !
> I too am interested in this.
>
> Another similar, related question is do packets that are not filtered
> wait on a verdict for a filtered packet?
> Again, if not, it means we can change packet order?
> If so,it means we can degrade system performance unrelated to our
> filtered packets.
I've just wrote an article describing libnetfilter_queue and NFQUEUE. It
has been written to answer your questions:
https://home.regit.org/netfilter-en/using-nfqueue-and-libnetfilter_queue/
Let me know if it is the case and don't hesitate if you have any
suggestions.
BR,
--
Eric
> Thanks,
> Credzba
>
> On Sat, Jan 12, 2013 at 6:43 AM, dorian <dorian33@o2.pl> wrote:
> > Hi all,
> > Sorry if the queries has been answered yet but I can't find the reliable
> > informations about issues concerned with libnetfilter_queue.
> >
> > I need to run a program which would firstly fork let's say 10 times (or
> > creates 10 threads) and next each child-process (or thread) will include
> >
> > while ((rv = recv(fd, buf, sizeof(buf), 0)) && rv >= 0) {
> > nfq_handle_packet(h, buf, rv);
> > }
> >
> > sequence.
> >
> > The fork/multiple threads reason usage is that for some packets the
> > processing time will be relatively long.
> > So I would like to handle next packets in "the meantime" using another
> > process (or thread)
> >
> > But I have 2 doubts which I would like to clarify.
> >
> > 1. - - - - - -
> > Is it possible to handle concurrently several packets with several
> > processes ?
> > i.e. if the process1 is handling a packet will the process2 receive the
> > next existing packet?
> >
> > The essence of my doubt is:
> > if process1 receives the packet1 but the verdict is not issued will
> > next recv() (in process2) be successful and not hold process2 until
> > verdict for packet1 is made?
> >
> > Please confirm.
> >
> >
> > 2. - - - - - -
> > Let's assume that we have process1 which handles packet 1, process 2
> > which handles packet 2, etc
> > Let's say verdict for packet2 is issued before verdict for packet1
> >
> > Will packet2 leave the queue or has it to "wait" for verdict for packet1 ?
> >
> > The essence of my doubt is:
> > can packet2 leave the queue before packet1 ?
> >
> > In other words can we change the packets order leaving system ?
> >
> > Or, maybe, although verdict for packet2 is done it has to wait for
> > verdict for packet1 and next both leave the queue in original order?
> >
> > I would be obliged if you clarify above two matter
> >
> > Best Regards,
> > Dorian
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netfilter" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Eric Leblond <eric@regit.org>
Blog: https://home.regit.org/
next prev parent reply other threads:[~2013-01-12 19:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-12 12:43 libnetfilter_queue issues dorian
2013-01-12 13:23 ` Felix
2013-01-12 19:04 ` Eric Leblond [this message]
2013-01-12 19:00 ` Felix
2013-01-12 21:16 ` dorian
2013-01-12 22:12 ` Eric Leblond
2013-01-12 22:34 ` dorian
2013-01-13 11:29 ` Pablo Neira Ayuso
2013-01-13 22:46 ` Eric Leblond
2013-01-13 22:49 ` [libnetfilter_queue PATCH 1/2] doxygen: improve fail-open documentation Eric Leblond
2013-01-13 22:49 ` [libnetfilter_queue PATCH 2/2] doxygen: improve documentation Eric Leblond
2013-01-14 14:24 ` libnetfilter_queue issues dorian
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=1358017441.18655.1.camel@tiger2 \
--to=eric@regit.org \
--cc=credzba@gmail.com \
--cc=dorian33@o2.pl \
--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