Sugar + OLPC mesh network selection logic

[Daniel Drake <dsd laptop org>]

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
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.

"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.

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.

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