Sugar Ad-hoc network: reconnect after suspend

[erikos]

After suspend we should probably reconnect to the Ad-hoc network we were connected to before.

[erikos]

Sugar Ad-hoc network: reconnect after suspend

[erikos]

When we came out from suspend the method autoconnect was called [1]. Which is invoked when the wireless device is being announced by NM. However, our state was still set to NM_DEVICE_STATE_UNMANAGED [2]. Hence we returned from the autoconnect method without doing anything [3]. The state does change a few seconds after this, either to NM_DEVICE_STATE_DISCONNECTED when there is no predefined connection or when connecting was successful to NM_DEVICE_STATE_ACTIVATED.

So my first fix included to have a timer that waits a few seconds, then checks if the state is disconnected and if not connects to an Ad-hoc network. Dealing with the moment the device is announced and when it gets out of the unmanaged state was rather complicated so I decided to just go for the timer.

So the timer would handle the cases where the device is still unmanaged or when we have an connection we were previously connected to. Left is the case where we want to directly connect. This has the issue that we might not wait for other Sugar Ad-hoc networks that are in the area (here is our logic [4]). If there is another learner around that uses channel 11 we want to connect to channel eleven too. So in this case we want to wait a moment to check whether we have other Sugar Ad-hoc networks around.

Result: the patch above. That always waits for 30 seconds, then checks if we are in the state disconnected and if yes applies the autoconnect logic. Simple, but handle all the cases :)

[1]  http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/adhoc.py#line141
[2]  http://projects.gnome.org/NetworkManager/developers/spec-07.html#type-NM_DEVICE_STATE
[3]  http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/adhoc.py#line142
[4]  http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/adhoc.py#line165

[sascha_silbe]

Replying to erikos:

When we came out from suspend the method autoconnect was called [1]. [...]

I wonder why that happens in the first place. Shouldn't NetworkManager just keep connected to the Ad-Hoc network (if the WiFi chip remains powered) resp. reconnect to the Ad-Hoc network after resume?

Result: the patch above. That always waits for 30 seconds, then checks if we are in the state disconnected and if yes applies the autoconnect logic. Simple, but handle all the cases :)

This is getting rather ugly, both from a code POV and from a usability one (imagine an XO auto-suspending after 5 seconds idle-time and taking 30 seconds to reconnect to the network).
Can't we push the Ad-Hoc network handling to NetworkManager? Not only would it make our life much easier in Sugar, I'm also worried that with  upstream removing user settings our code might not be able to work this way in the future.

[1]  http://git.sugarlabs.org/projects/sugar/repos/mainline/blobs/master/src/jarabe/model/adhoc.py#line141

[...]

BTW, you can use Trac wiki syntax in tickets.

[erikos]

Replying to sascha_silbe:

Replying to erikos:

When we came out from suspend the method autoconnect was called [1]. [...]

I wonder why that happens in the first place. Shouldn't NetworkManager just keep connected to the Ad-Hoc network (if the WiFi chip remains powered) resp. reconnect to the Ad-Hoc network after resume?

I think we are talking about two different cases. I meant lid-close - the wireless device is turned off, too.

[sascha_silbe]

Replying to erikos:

Replying to sascha_silbe:

I wonder why that happens in the first place. Shouldn't NetworkManager just keep connected to the Ad-Hoc network (if the WiFi chip remains powered) resp. reconnect to the Ad-Hoc network after resume?

I think we are talking about two different cases. I meant lid-close - the wireless device is turned off, too.

I meant to include "(if the WiFi chip gets turned off)" right before the question mark, but forgot. So my question still applies: Why doesn't NetworkManager bring up the same connection after resume that it took down during suspend?

[erikos]

Replying to sascha_silbe:

Replying to erikos:

Replying to sascha_silbe:

I wonder why that happens in the first place. Shouldn't NetworkManager just keep connected to the Ad-Hoc network (if the WiFi chip remains powered) resp. reconnect to the Ad-Hoc network after resume?

I think we are talking about two different cases. I meant lid-close - the wireless device is turned off, too.

I meant to include "(if the WiFi chip gets turned off)" right before the question mark, but forgot. So my question still applies: Why doesn't NetworkManager bring up the same connection after resume that it took down during suspend?

Hmm, I tested with nm-applet to see if NM does bring up Ad-hoc networks after suspend. It works for networks that have the IPv4 method 'shared' but not 'link-local' ones. Will check if that is by design.

[erikos]

Pushed fix as: 582f9df1acbff8c71d897f37a4a4e98d4830fd3f

Setting the 'autoconnect' property for the connection will let NM do the reconnection when the device is up. If the Sugar Ad-hoc network is around it will automatically connect to it. The connection is not stored after logging out of Sugar.

The autoconnect functionality inside Sugar is still needed for the cases when we log into Sugar, after a timeout we will connect to an exisiting Ad-hoc network or will default to the Sugar Ad-hoc network on channel 1. I increased the timeout to 60 seconds because during testing I found to get more reliable results like that.