notifications of interfaces going down/up/being created/destroyed?

notifications of interfaces going down/up/being created/destroyed?

[Dave Taht]

is there an asynchronous way to register for a notification of an
interface going down/up?

---------- Forwarded message ----------
From: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Date: Sat, Mar 28, 2015 at 9:30 AM
Subject: Re: [Babel-users] Looping in EAGAIN
To: Dave Taht <dave.taht@gmail.com>
Cc: Simon Kelley <simon@thekelleys.org.uk>,
"babel-users@lists.alioth.debian.org"
<babel-users@lists.alioth.debian.org>


> Say wlan0 vanishes. All the routes going out that interface are no
> longer valid, but from what I understood of this patch, it will loop for
> a while, then give up.

If wlan0 vanishes, this will be recognised the next time check_interfaces
is run, and all neighbours visible through wlan0 will be flushed.

The issue we're having is a race condition -- if wlan0 goes down and then
back up before we run check_interfaces, and the IP addresses don't change,
then check_interfaces will not notice the transition, and Babel will think
that its routes through wlan0 are still up -- end you end up with a FIB
that is not a subset of the RIB.  Ouch.

So it might be a good idea to run check_interfaces early when we get
EAGAIN, but I'm not sure what consequences it might have -- EAGAIN can
also happen when we're under load, and we'd rather not be repeatedly
scanning our interfaces in that case.

It would be better to get async notifications from the kernel about
interfaces going down.

> Not clear to me if this would happen for 4 hello intervals before the
> interface is recognised as gone?

No, the hellos are used to notice vanishing neighbours, not vanishing
interfaces.  That's a completely different mechanism.

-- Juliusz


-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb

Re: notifications of interfaces going down/up/being created/destroyed?

[Benjamin Poirier]

On 2015/03/28 09:37, Dave Taht wrote:
> is there an asynchronous way to register for a notification of an
> interface going down/up?

Look at what `ip monitor` is doing.

> 
> ---------- Forwarded message ----------
> From: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
> Date: Sat, Mar 28, 2015 at 9:30 AM
> Subject: Re: [Babel-users] Looping in EAGAIN
> To: Dave Taht <dave.taht@gmail.com>
> Cc: Simon Kelley <simon@thekelleys.org.uk>,
> "babel-users@lists.alioth.debian.org"
> <babel-users@lists.alioth.debian.org>
> 
> 
> > Say wlan0 vanishes. All the routes going out that interface are no
> > longer valid, but from what I understood of this patch, it will loop for
> > a while, then give up.
> 
> If wlan0 vanishes, this will be recognised the next time check_interfaces
> is run, and all neighbours visible through wlan0 will be flushed.
> 
> The issue we're having is a race condition -- if wlan0 goes down and then
> back up before we run check_interfaces, and the IP addresses don't change,
> then check_interfaces will not notice the transition, and Babel will think
> that its routes through wlan0 are still up -- end you end up with a FIB
> that is not a subset of the RIB.  Ouch.
> 
> So it might be a good idea to run check_interfaces early when we get
> EAGAIN, but I'm not sure what consequences it might have -- EAGAIN can
> also happen when we're under load, and we'd rather not be repeatedly
> scanning our interfaces in that case.
> 
> It would be better to get async notifications from the kernel about
> interfaces going down.
> 
> > Not clear to me if this would happen for 4 hello intervals before the
> > interface is recognised as gone?
> 
> No, the hellos are used to notice vanishing neighbours, not vanishing
> interfaces.  That's a completely different mechanism.
> 
> -- Juliusz
> 
> 
> -- 
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
> 
> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html