connect_wireless may try to connect to a non available AP if not connected to wireless already

This would be solved by the dependencies working properly, as the wireless/wireless_connection test would make sure the last used connection was one that is available. I think there will be a way to improve so that at least it chooses the last *available* connection rather than just the last used one, but since this is milestoned for P we can deal with it in due course.

I updated the title as this will also happen if you don't have any connection, even an ethernet one.

It would also be useful to see the out of 'nmcli con list' in the situation where this is failing. It won't solve this bug but I need to check to make sure there aren't any others.

If I run the command it gets:

ara@sushirider:~/curro/checkbox/checkbox/trunk/jobs$ nmcli con list
NAME UUID TYPE TIMESTAMP-REAL
Auto BETAHAUS c9c88902-2f4f-4fb8-a111-fba509ee9523 802-11-wireless Wed 28 Sep 2011 06:24:40 PM CEST
Auto Musireta 60aa39e7-5dc5-429f-b27a-a798607b0ea7 802-11-wireless Thu 29 Sep 2011 03:06:38 PM CEST
Auto BETAHAUS on Speed f22ad50e-4b06-4712-93bb-8b8572d1ab15 802-11-wireless Wed 28 Sep 2011 05:56:22 PM CEST
Wired connection 1 69bcb71d-8de7-46e5-b66e-3d9923c93d46 802-3-ethernet Thu 29 Sep 2011 02:01:56 PM CEST

BETAHAUS is not available, and I am currently connected to Musireta

OK, so in determining the currently-established wi-fi connection, if one was active, it will try to use that one again. Correct me if I'm wrong but this part is pretty robust and works fine.

If none is active (i.e. I'm connected only through ethernet, or even if I have no network connection at all), then conn will be the first connection as returned by nmcli con list, though this returns *configured* connections, not necessarily ones that are available.

So one way to make this more reliable is if, when there's no active connection, I get a list of currently available access points (nmcli dev list wifi) and try to see if I have a configured connection for any of those.

So in Ara's example:

- She's currently not connected via wifi so the script tries to connect to BETAHAUS as it's the first configured connection as per nmcli con list. This fails as BETAHAUS is not available.
- If things are as proposed above, then the script would first scan the available APs, notice that BETAHAUS is not available and so ignore it, and since presumably Ara has a configuration for Musireta, the script would pick that for conn.
- If there are no available *and* configured wifi networks, the script shouldn't try to restore connectivity at all. This is just a failsafe, because the script shouldn't run at all if there's no way to get a wireless connection.

Given that we were moments away from final freeze, I didn't have time to properly implement and test this :-/ But at least finding cases where the current logic fails and coming up with more robust logic will yield a more reliable implementation in the near future.

It would have been nice if nmcli con list returned the connections in order of when they were last used, but it doesn't. As you pointed out 'nmcli dev list wifi' can give the SSIDs of available access points. This can be matched against 'nmcli con list' but not 100% reliably since we can't know if the AP named in dev list wifi is the same one as in the connection name in 'nmcli con list' and it also depends on the user not changing the connection name in such a way that it doesn't include the SSID anymore.

Can we confirm whether this is working now? I know we've done quite a bit of work on the wireless_connection tests, so this may be solved now.

Has been incomplete almost 4 months, I'll mark as Fix Released per Brendan's comments (plus we haven't seen this problem in a while).