Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Jaco Kroon <jaco@uls.co.za>
To: Eric Leblond <eric@inl.fr>
Cc: netfilter@vger.kernel.org
Subject: Re: nlif_index2name bug?
Date: Sun, 18 Nov 2007 21:11:32 +0200	[thread overview]
Message-ID: <47408E64.8060901@uls.co.za> (raw)
In-Reply-To: <1195410901.6881.19.camel@localhost>

Eric Leblond wrote:
> Hi,
>
> Le samedi 17 novembre 2007 à 14:53 +0200, Jaco Kroon a écrit :
>   
>> Hi guys,
>>
>> I've seen an error in nlif_index2name, specifically, if an interface
>> comes up _after_ I've opened the nlif_handle (using nlif_open()) then it
>> won't resolve the index of that device to a name.
>>
>> Is this a known issue, a bug or simply me not understanding how nlif
>> works?
>>     
>
> Yes, you did not understand how nlif is working (but I think this is due
> to the lack of documentation). If fact, you have omit to listen to iface
> events and to call nlif_catch after each event.
>   
Ah thanks.
> For a working code example, you can have a look at NuFW's code. nlif
> related code is always prefixed by:
> #ifdef HAVE_NLIF_CATCH
>
> You can browse code online at:
> http://software.inl.fr/trac/trac.cgi/browser/mirror/edenwall/nufw/trunk/nufw/src/nufw/packetsrv.c
> http://software.inl.fr/trac/trac.cgi/browser/mirror/edenwall/nufw/trunk/nufw/src/nufw/iface.c
>   
This isn't a particularly "short" example and can probably be simplified
a lot, not true?  It's good enough for me though, so thank a million for
pointing me to it.
> I've just wrote a brief nlif documentation on the following page:
> http://software.inl.fr/trac/trac.cgi/wiki/articles/using_nlif
>   
This explains things quite a bit.  Very nicely done.

I'm actually using libnetfilter_queue, and am not doing anything
multi-threaded, would it be sufficient just to call nlif_catch() every
time I run into an interface for which there is no name and to then
retry the call?  Alternatively, you mention select(), I'm guessing the
poll() system call will achieve the same thing?  My reasoning here is
that everytime just before calling nlif_index2name() to first call
poll() with a timeout of zero in order to check whether there are
updates and to then call nlif_catch if there are updates, however, is
this the most efficient way, since poll() and nlif_catch() both probably
results in a system call, wouldn't it simply be more efficient to just
call nlif_catch every time just before calling nlif_index2name?

Also, in the case of poll(), I guess I need to poll for POLLIN?

Thanks for the help and explanation so far,

Jaco

  reply	other threads:[~2007-11-18 19:11 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-17 12:53 nlif_index2name bug? Jaco Kroon
2007-11-18 18:35 ` Eric Leblond
2007-11-18 19:11   ` Jaco Kroon [this message]
2007-11-18 19:55     ` Jaco Kroon

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=47408E64.8060901@uls.co.za \
    --to=jaco@uls.co.za \
    --cc=eric@inl.fr \
    --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