New 'git fomat-patch'-ed version with a fix for the "Error getting the access point properties: org.freedesktop.DBus.Error.UnknownMethod: Method "GetAll" with signature "s" on interface "org.freedesktop.DBus.Properties" doesn't exist" error and another fix for a typo that caused weired behavior

The patch is against 0.84. Of course we should land it in master, too. It should be applyable with small modifications to master. Once we are happy with the general approach I will do the master branch patch so that we are able to land it there, too.

There is artwork needed for this patch. We have agreed on some new icons to represent the Ad-hoc network icons (the channels are represented using the maya numerals).

Looks great to me, will review in detail when a patch for master is proposed.

Something that has attracted my attention is that the code talks about automatically connecting to an ad-hoc connection in some circumstances, but we only autoconnect to a network that has been named as Sugar does, may be good to make this clearer.

How will this behave in machines which have both mesh support and can do ad-hoc ? (sorry if I've missed any prior discussion on this)

So, on machines like the XO-1.0 we will use the mesh as the hardware allows to. On the XO-1.5 we will present the user with the three adhoc networks, as there is no mesh hardware available. The XO-1.5 and XO-1.0 will see adhoc networks in his neighborhood view, so it the XO-1.0 can connect to an adhoc network that has been created by a learner on the XO-1.5. What we removed is the option in the device palette to create adhoc networks, as we have now standard ways of creating networks without infrastructure.

So, on machines like the XO-1.0 we will use the mesh as the hardware allows to. On the XO-1.5 we will present the user with the three adhoc networks, as there is no mesh hardware available. The XO-1.5 and XO-1.0 will see adhoc networks in his neighborhood view, so it the XO-1.0 can connect to an adhoc network that has been created by a learner on the XO-1.5. What we removed is the option in the device palette to create adhoc networks, as we have now standard ways of creating networks without infrastructure.

Do I understand correctly that in order to let XO-1s collaborate with XO-1.5s now an XO-1.5 user needs to initiate the connection as there's no way for the XO-1 user to create an ad-hoc network? If so, that seems cumbersome and confusing to me.

So, on machines like the XO-1.0 we will use the mesh as the hardware allows to. On the XO-1.5 we will present the user with the three adhoc networks, as there is no mesh hardware available. The XO-1.5 and XO-1.0 will see adhoc networks in his neighborhood view, so it the XO-1.0 can connect to an adhoc network that has been created by a learner on the XO-1.5. What we removed is the option in the device palette to create adhoc networks, as we have now standard ways of creating networks without infrastructure.

Do I understand correctly that in order to let XO-1s collaborate with XO-1.5s now an XO-1.5 user needs to initiate the connection as there's no way for the XO-1 user to create an ad-hoc network? If so, that seems cumbersome and confusing to me.

Yeah true, I have overseen that point. Thanks for the comment. We concluded to remove the option from the palette as it might be confusing to the learner to have so many options. And in my opinion, once you have the three default adhoc networks there is not really a need to be able to create your 'own' new adhoc network (machines without mesh hardware). And we do not want to populate the neighborhood view on the XO-1.0 with three mesh icons and three default adhoc icons. Not sure yet, how/if we can do better here, suggestions welcome.

And we do not want to populate the neighborhood view on the XO-1.0 with three mesh icons and three default adhoc icons. Not sure yet, how/if we can do better here, suggestions welcome.

Then let's add a gconf switch to choose between Mesh/Ad-hoc/Both with the default set to Ad-hoc. AIUI the XO-1 mesh mode is not interoperable with any other device because it's ​based on an obsolete draft of IEEE 802.11s, so let's make it a conscious choice of deployers (or users) to enable mesh support. If IEEE 802.11s ever becomes a standard (it's still in the draft phase) and devices supporting the standard become widespread we can reconsider the default.

I think the first issue you are describing has nothing to do with the patch itself. When you use sugar-emulator and have nm-applet running at the same time they will interfere with each other. For example: You are connected to the wireless network X with nm-applet and try to connect to the wireless network Y in the sugar emulator: nm-applet will disconnect from it's previous connection.

If now (with the patches applied), you have no wireless connection set in sugar (.sugar/X/nm/connections.cfg) after a timeout sugar will try to connect to an adhoc network, hence interrupt the open connection you had with nm-applet. As sugar and nm-applet are not synced for the connections this is what you will see.

About the blocking of the UI: the dbus call you are mentioning that give out the error message is asynchronous actually, there are handlers specified. I will have a look why the error message gets called in the first place, not sure yet.

New 'git fomat-patch'-ed version with a fix for the "Error getting the access point properties: org.freedesktop.DBus.Error.UnknownMethod: Method "GetAll" with signature "s" on interface "org.freedesktop.DBus.Properties" doesn't exist" error and another fix for a typo that caused weired behavior

The patch above does not solve the issue for sugar-emulator users. This is a general issue not introduced by the patch though. I will see if I can find more people to try it out and I will do tests on several machines myself.

And we do not want to populate the neighborhood view on the XO-1.0 with three mesh icons and three default adhoc icons. Not sure yet, how/if we can do better here, suggestions welcome.

Then let's add a gconf switch to choose between Mesh/Ad-hoc/Both with the default set to Ad-hoc. AIUI the XO-1 mesh mode is not interoperable with any other device because it's ​based on an obsolete draft of IEEE 802.11s, so let's make it a conscious choice of deployers (or users) to enable mesh support. If IEEE 802.11s ever becomes a standard (it's still in the draft phase) and devices supporting the standard become widespread we can reconsider the default.

Were any gconf switches added? I have two XO-1s here with OLPC build 850, is there a way for me to use them to test the new adhoc behaviour?

Gary there is no gconf switch, yet. The code does the following, it checks whether a mesh device is available, if not create the Ad-hoc networks. If a XO-1.0 deployment wants to use the Ad-hoc networks they can disable the device (init script) for example.

But yes, maybe a gconf option might be even better. Would make the code simpler as we do not have to deal with timeouts for checking of the existence of the device.

For now for testing, just set line 1142 in meshbox.py to 'False' (with the rpms I posted above) in order to test it on XO-1.0 the Ad-hoc networks (you should see the Ad-hoc and mesh icons then).

If you really want to use an exception here, then create a new one because KeyError can be raised because of several reasons. But probably frequency_to_channel() should just print a warning and return 1 if the frequency is not known.

+ if connection:

is not None

+ connection.set_connected()

connection.connect() may be more in line with the existing code.

+ self._bus = dbus.SystemBus()
+ self._manager = adhoc.get_manager()

No big deal, but if these aren't part of the sate of the class, then it would be better to just get references to them whenever we need it instead of caching the references.

If you really want to use an exception here, then create a new one because KeyError can be raised because of several reasons. But probably frequency_to_channel() should just print a warning and return 1 if the frequency is not known.

Yes. moved the error handling part into the function and log a descriptive warning. Returning 1 might hide the error too much, though. Maybe 0 or -1?

+ if connection:

is not None

Done.

+ connection.set_connected()

connection.connect() may be more in line with the existing code.

set_connected is actually a method of NMSettingsConnection (model/network.py). Do you mean to change that one?

+ self._bus = dbus.SystemBus()
+ self._manager = adhoc.get_manager()

No big deal, but if these aren't part of the sate of the class, then it would be better to just get references to them whenever we need it instead of caching the references.

Done.

+ 'ap-added': (gobject.SIGNAL_RUN_FIRST, gobject.TYPE_NONE,

"ap" may not be obvious to all the future readers of this code.

Changed it to 'access-point-added'. Is quite long, that is why I did not do so in the first place, but yeah more descriptive.