Re: Sugar + OLPC mesh network selection logic

[Dan Williams <dcbw redhat com>]

On Mon, 2009-07-06 at 17:27 +0100, Daniel Drake wrote:
> On Wed, 2009-07-01 at 12:18 -0400, Dan Williams wrote:
> > If other APs appear later, it may well trigger the
> > schedule_activate_check() which might cause NM to try to connect to that
> > new network.  To combat that, I'd suggest that the mesh device block the
> > wifi device from activating if it already failed by putting it into the
> > UNAVAILABLE state or something, but that could be error prone.  What I
> > think we really want here is the 'device idle' concept that asac and I
> > have been talking over for a while.
> 
> The same consideration has to apply for when the mesh device disconnects
> the eth device, because the user requested a mesh connection. Right now,
> NM immediately reactivates eth0 (usually reconnecting to the same
> network as before) and "wins."
> 
> What is the "device idle" concept? What do you think of an approach
> along these lines? This way the mesh device can attach to the
> autoconnect-allowed signal on the main device, and influence when it can
> and cannot be used for automatic connections.

THe "device idle" concept is basically a flag on each device that will
suppress any autoconnect on that interface.  So if the device is "idle",
it wouldn't *automatically* bring up an autoconnect=true connection
until the user (or applet or whatever) explicitly called
ActivateConnection(), at which point the device's idle flag would be
cleared.  So from NM's perspective, 'idle' is manually/programmatically
set, and automatically cleared on the next activation.

This scheme would allow the mesh device to suppress autoconnects on the
wifi device until either the user manually clicked an AP or the UI
client wanted to turn it back on.

At least that's the idea.

Dan