nlif_index2name bug?

nlif_index2name bug?

[Jaco Kroon]

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?  Currently I need to kill and restart my application in order to
make it work again, which is obviously non-ideal.

Jaco

Re: nlif_index2name bug?

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

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.

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

I've just wrote a brief nlif documentation on the following page:
http://software.inl.fr/trac/trac.cgi/wiki/articles/using_nlif

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: nlif_index2name bug?

[Jaco Kroon]

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

Re: nlif_index2name bug?

[Jaco Kroon]

Jaco Kroon wrote:
> Eric Leblond wrote:
>   
>> 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?
>   
Ok, so after testing it turns out poll(2) does work quite nicely,
however, I need to call nlif_catch quite a few times to get things to
work nicely, so now I've basically got this piece of code just before
nlif_index2name():

while (poll(&nlif_poll, 1, 0) > 0) {
    log (LOG_INFO, "Calling nlif_catch due to device changes.");
    nlif_catch(nlif);
}

And it turns out that simply restarting ppp0 causes quite a few events:

[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Calling nlif_catch due to device changes.
[INFO]: Setting device ppp0(9) to cap 2.

Not sure what's causing all those events but it works correctly now, thanks.

Jaco