[radvd-devel-l] RFC: interfaces going up/down during radvd lifetime

Pekka Savola pekkas at netcore.fi
Wed Mar 15 11:47:44 EST 2006


I'd really appreciate more feedback on this issue, one way or the 
other.  "Me toos" and/or offlist replies are fine too.

Just trying to get a wider view on what the community wants from this 
piece of software..

On Tue, 7 Mar 2006, Pekka Savola wrote:
> A bug report from Simon Oosthoek triggered this issue, and I'd like to see if 
> other folks have opinions on this.
> Currently if interface doesn't exist when radvd is started, radvd doesn't 
> start unless IgnoreIfMissing is defined.  When the interface comes up, the 
> user or if{up,down} scripts need to send HUP signal to radvd to start using 
> the interface.
> Simon's problem was a dynamic wireless interface that's sometimes disabled 
> and/or removed.  In such case, radvd didn't automatically restart the 
> advertisements when the interface was plugged back in, but still kept 
> running.
> As a quick fix, I made the behavior more deterministic:
> - if IgnoreIfMissing is not defined, exit immediately if an interface
>   becomes inoperational or goes missing.
> - if IgnoreIfMissing is defined, keep radvd alive, waiting for
>   HUP signal to restart.
> Now, one could argue it'd be nice if this "worked by default", so that, for 
> example:
> a) if interface goes missing and comes back, automatically restart
>    advertisements
> b) if interface didn't exist when starting up, but IgnoreIfMissing is
>    defined, automatically start advertising when the interface starts
>    working.
> c) don't print a lot of error messages on missing/non-working
>    interfaces if IgnoreIfMissing is defined
> I'd like to note that doing the processing checks could take a bit of CPU 
> time, especially if you advertise (say) 20 times a second.
> Comments?

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

More information about the radvd-devel-l mailing list