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 _______________________________________________ NetworkManager-list mailing list NetworkManager-list@gnome.org http://mail.gnome.org/mailman/listinfo/networkmanager-list