Re: Sugar + OLPC mesh network selection logic

[Dan Williams <dcbw redhat com>]

On Wed, 2009-06-10 at 14:39 +0100, Daniel Drake wrote: 
> Hi,
> 
> I'm looking to implement network selection logic in sugar-0.84 using the
> NetworkManager D-Bus API to implement something similar to what was
> present in NetworkManager-0.6 for OLPC's mesh device. (the logic is now
> being moved out of NetworkManager into sugar)
> 
> My work in progress is:
> NM-0.7 with OLPC mesh support
> http://dev.laptop.org/git/users/dsd/NetworkManager/log/?h=olpc
> http://dev.laptop.org/~sjoerd/NM0.7/olpc-mesh.fdi

Though you're really not going to want to use HAL fdi files for this,
since master now uses only udev.  You'll either want to hardcode the
Marvell device IDs into nm-hal-manager (or match on "mshX") or you'll
want to tag it with udev rules and grab the property from NM instead.
Could even do that udev rules tagging now in 0.7.x.

> sugar-0.84.5 patch to add mesh support (connects to link local mesh when
> selected on neighborhood view)
> http://dev.laptop.org/~dsd/20090610/sugar-0.84-olpc-mesh.patch
> 
> 
> I'm looking for some feedback on my plan, particularly for the
> interacting-with-NM side of things.
> 
> This is how sugar works at the moment (I think):
> - Only infrastructure networks are supported.
> - On a new install, it doesn't attempt any connections.
> - When the user clicks on a network to connect, sugar makes an
> NMSettingsConnection object and and uses ActivateConnection() to
> activate it.
> - If the connection succeeds, sugar saves the details internally.
> 
> - When starting up again later, sugar loads all its saved networks,
> creating NMSettingsConnection objects with the autoconnect flag set.
> - It doesn't call ActivateConnection() on anything, but presumably NM
> notices the new connections (with the autoconnect preference) and picks
> one to try.
> 
> 
> And now the logic I want to implement, which is similar to that in
> previous OLPC OS releases:
> - First, attempt to connect to any known access points that are in range
> using saved credentials. Always prefer known APs to mesh.
> - As a fallback if those APs fail, or if no APs are available or if
> we've never connected to any (e.g. on first boot), try the mesh.

Internally, you'll know if an ongoing connection attempt (represented by
the NMActRequest object) is user-requested or not by looking at
nm_act_request_get_user_requested().

The policy will auto-activate devices in certain situations, see
src/NetworkManagerPolicy.c::schedule_activate_check(), which is called
in response to certain events that devices emit, like failure,
connection termination, changed wireless networks, etc.

So I'd imagine that since the mesh device has to know about it's sibling
wifi device, it can figure out that device's state, and attach to
signals on its state too.  If the wifi device fails, start a short timer
that gets clear if the wifi device starts activating again.  If the
timer expires, then you could start doing your mesh activation.

That could be done client-side too (ie not in NM).  If the wifi device
goes into state NM_DEVICE_STATE_FAILED or DISCONNECTED, wait a few
seconds, and then start trying to manually activate mesh connections
based on your logic.

> "try the mesh" means trying each of these configurations in turn,
> stopping on the first one that succeeds:
> 1. Connect to school server on channel 1 (i.e. dhcp with XS anycast
> address)
> 2. Connect to mesh portal on channel 1 (i.e. dhcp with MPP anycast
> address)
> 3. Connect to school server on channel 6
> 4. Connect to mesh portal on channel 6
> 5. Connect to school server on channel 11
> 6. Connect to mesh portal on channel 11
> 7. Connect to link-local simple mesh on channel 1 (cannot fail)
> 
> [the mesh device settings class has properties 'channel' and
> 'dhcp-anycast-address' therefore the way to try each configuration is by
> creating and activating a new NMSettingsConnection object for each one]
> 
> My uncertainty is how to implement the above logic.

Could be done app-side I think using the mechanism I describe above.

> Is it possible to assign a priority or preference to a
> NMSettingsConnection object? If so, I could just create high-priority
> objects for all APs, and decreasing priority objects for the mesh
> configurations, all with the autoconnect flag. The priorities would
> cause Networkmanager to try them in order suggested above.

Priorities aren't implemented because for most situations other than
mesh, they aren't that useful, and they simply aren't context-aware.
They are a huge hammer that contains no intelligence about the actual
network situation and the interaction between devices.

It's actually pretty rare that you'd need priorities for wifi, because
you can scan for "favorite" APs and thus you know if you can connect to
them, and secondly it's quite rare that you'd be denied access to one
SSID conditionally and then get access to a second SSID *at the same
location*.

For wired networks, priority might be useful, but I'd rather implement
some sort of optional network autodetection instead.  802.1x can
apparently automatically identify the connection to use because the
switch sends out eapol frames on the port which we could theoretically
match up with something in the connection itself.

3G doesn't need priority fallback because we can scan to find the
networks you'd want to connect to, and it's exceedingly unlikely that
you'd want to say use a roaming network while your actual network was
available; most providers will either disallow that anyway, or terminate
you for excessive roaming in an area they already serve.

OLPC mesh is a pretty specialized case because the distinction between
School Server, Mesh Portal Point, and standalone (under-a-tree) is
completely artificial.  And you're right, that's better done in the
client, not inside NM.

So I think having the client control at least the mesh parts of the
association process is the best way to go.

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.

Dan

> Alternatively, we could always set autoconnect=False for all networks,
> and have some kind of management layer inside sugar which iterates
> through all the networks, monitoring the device states, calling
> ActivateConnection and moving onto the next one if it failed to connect.
> But immediately it gets tricky.. for infrastructure networks, we have to
> consider which APs are available, and what happens if they appear
> later?, etc.
> 
> Or, other options?
> 
> Thanks,
> Daniel
> 
> 
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org
> http://mail.gnome.org/mailman/listinfo/networkmanager-list