[phone] Does not auto-switch to available, known WiFi

[Michał Sawicz]

This might not be the place for this bug, please reassign as appropriate.

I was only able to reproduce this on mako/rtm, krillin/vivid seems to behave better (but I do remember the same issue there).

Steps:
* connect to a password-protected WiFi network
* go out of range
* make sure a GSM connection is established
* go back in the WiFi range

Expected:
* phone connects to the known WiFi automatically

Current:
* phone does not connect to WiFi

Please find attached network-test-session logs from when I toggled WiFi and Plane mode to get some data on the issue.

ProblemType: Bug
DistroRelease: Ubuntu RTM 14.09
Package: indicator-network 0.5.1+15.04.20141215~rtm-0ubuntu1
Uname: Linux 3.4.0-5-mako armv7l
ApportVersion: 2.14.7-0ubuntu8
Architecture: armhf
Date: Tue Jan 6 12:01:55 2015
InstallationDate: Installed on 2014-12-18 (18 days ago)
InstallationMedia: Ubuntu Utopic Unicorn (development branch) - armhf (20141218-163635)
SourcePackage: indicator-network
UpgradeStatus: No upgrade log present (probably fresh install)
indicator-network.log:
 Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered
 Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered
upstart.indicator-network.log:
 Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered
 Attempted to unregister path (path[0] = org path[1] = freedesktop) which isn't registered

[Tony Espy (awe)]

@Michael

I just tested this with mako/RTM #17, and this seems to be working fairly well for me.

My test consisted of walking downstairs to the first floor of my building and then walking down a hallway till the phone eventually disconnected from WiFi, I then took the elevator back upstairs and as I entered my loft, the phone re-connected to my home access point.

I've run through this scenario at least twice today, as I tried to reproduce bug #1438402, which describes a problem where WiFi never disconnects from a home AP.

[Cormac (cormac-wilcox)]

I'm not sure if this is a regression but I have this identical problem on a bq Aquaris 14.10 (r21) after the update from r20.

[Michael Zanetti (mzanetti)]

Seems I'm running into the same with devel-proposed and network-manager 0.9.10.0-4ubuntu15.1~awe4

Forensics attached

[march (marc.h)]

Problem still occurs sometimes on my bq Aquaris 14.10 (r22).

[Tony Espy (awe)]

@Michael

Can you please re-test when OTA6 is released ( or flash the latest rc-proposed )?

@march

Please re-test when OTA6 is released ( should be out within the next week or so ). In general this should work much better when recent fixes to NM land with OTA6.

That said, there may still be issues with re-connecting to a roaming style network ( ie. an ESSID configuration where multiple access points exist with the the same SSID ).

[Michał Sawicz (saviq)]

@Tony

I'm on rc-proposed, so I assume I have the fixes there for some time already? The situation's been much better recently, only exception being that I sometimes have to toggle WiFi on/off for it to refresh the list of networks, otherwise it's stale and the phone would stay on GSM data.

I do have a roaming setup, FWIW.

[Elias K Gardner (zorkerz)]

I sporadically experience the same thing here. OTA-6 mako

Going from one building to another at work and driving from work to home the phone often says it is still connected to the old network which is no longer in range. Turning the wifi on and off fixes it. To be clear this is sporadic, sometimes it works fine.

[Michael Terry (mterry)]

I've seen this sometimes in conjunction with bug 1480877, where NetworkManager and dbus-daemon are in a fight to see who can slow the other one down the most. In such cases, it can take NetworkManager a long while to update the indicator.

I'm not saying that all instances of this symptom are due to bug 1480877. But I think at least some instances are.

[Pat McGowan (pat-mcgowan)]

this is still being reported, see also support bug #1466799

[Michał Sawicz (saviq)]

Confirmed, I still sometimes get my krillin rc-proposed to get stuck with a list of WiFis and I've to turn WiFi off/on to get things working again.

[Pat McGowan (pat-mcgowan)]

saw this myself today on a mako with rc-proposed

[Enrique (enrique-garcia)]

I also experienced a similar behavior in my BQ 5 with OTA 8

[Julia Palandri (julia-palandri)]

@awe, I tried this again: arriving at home without cellular data, but with wifi enabled.

I gave it 10/15 minutes of time to try to reconnect on its own.

Then I woke up the phone, the indicator said wifi was offline. I checked on the browser and I couldn't browse (said I was offline).

I pulled down the network indicator and only then the phone started connecting on the known home wifi network. After this I could browse.

[Pat McGowan (pat-mcgowan)]

That description sounds like a normal delay after resuming and is similar to what I experience. That is, I don't believe looking at the network indicator was a factor, it just took the stack time to detect the AP and connect. That delay may be longer than desired due to the dbus traffic issues.

[Pete Woods (pete-woods)]

You are correct, Pat. There is no scanning that is activated when you pull down the networking indicator like in OSX. So this is more likely to be related to waking up. Sounds like the passive network scanning (driver / wpa supplicant?) isn't working when the phone goes into power save mode to me.

[Tony Espy (awe)]

@Julia

Thanks for the testing report!

So when you say, "you gave it 10/15 minutes of time to reconnect on its own". I assume during this time you were assuming that the device would re-connect automatically when the screen was off?

Then you say you woke the phone, and it was offline until you started to interact with the network menu. Can you give us a rough idea of how long it was between when you woke the phone, and it connected? My experience have show that it's usually somewhere between 30s and 2m to connect.

Finally, the original bug describes a situation where after the phone is woken, it will *never* re-connect to an available access point it's previously been connected to.

@ Pete

Regarding passive network scanning... no, none of the sort happens, in fact we have no code at all in our network stack that integrates with our power management framework on touch devices.

At some point, the screen turns off, which given the right conditions causes powerd to notify the kernel that it's allowed to sleep. When this happens ( ie. the kernel decides to suspend given no more wake locks ), there's no notification to wpa_supplicant or NetworkManager, and in some cases we've seen this "pulling of the rug" approach actually prevent some devices from suspending.

Enabling passive scanning during suspend is something that could be accomplished automatically by the driver, or enabled by wpa_supplicant before suspend, however without some knowledge of the system power/suspend mechanism, neither wpa_supplicant or NM can do this today. Making such a thing work, also would require deeper technical cooperation from the ODM and/or IHV.

Note, we also should seriously consider a new system settings for WiFi that allows a user to specify whether or not WiFi is to attempt to keep a connection going when the system goes to suspend. I would argue that our current situation is a bit ambiguous ( ie. WiFi remains on, but at some point when the device suspends, it does disconnect ).

[Tony Espy (awe)]

It should be noted that we just landed a new version of NetworkManager into rc-proposed ( 0.9.10.0-4ubuntu15.1.10 ) which fixed a couple of race conditions that existed in the interactions between NM and wpa_supplicant that could potentially cause the phone to stop scanning on WiFi after a disconnect occurs.

That said, for now I think it best to keep this bug open, until wider testing shows whether or not issues still exist.

Finally, an ongoing effort is happening to re-base Touch on NetworkManager 1.2, which includes a significant re-working of NM's WiFi logic. As this gets closer to reality/landing, I will make sure to comment on this bug.

[Julia Palandri (julia-palandri)]

I'm on rc-proposed with arale, and last Sunday this happened:
- I'm on my cellular network
- In the morning I go to a place that offers free wifi. I connect to it.
- I leave this place, change city, go back home (with its own known wifi network) at night
- I sleep over the night
- The morning after (Monday morning) I want to check a video; before that I want to make sure I'm on wifi. I pulled down the wifi indicator and I see I'm still "connected" to the wifi of the place where I had breakfast the day before
- My home's wifi is in the list (!) so I just choose it and it connects.

I'm not sure if the phone was indeed connected to my ap but displaying something else, or if it wasn't connected at all. The other times I've seen something like this usually the indicator updates (either connecting or showing the right connection, who knows) pretty quickly *after* I pull down.
Is it possible to get any logs that could better show what's going on for real?

[Pat McGowan (pat-mcgowan)]

Enabled wifi and it doesn't scan or connect
MX4 running 371
System had been running with Wifi disabled for over a day

Attached log shows an error
Tried disabling and enabling Wifi and still did not work, same for flight mode
Fixed on reboot

[Tomas Öqvist (tomoqv)]

I experience this issue quite often with my Pro 5 (rc-proposed). It is not unusual that I have to pull down the network indicator and actually tap on my home wifi in order to reconnect. Frequently at other times, when I wake the phone from suspend (i.e. turn it on), I am being prompted for the wifi password. Tapping cancel sends the connection to mobile (if it all works, but that's another story with separate bug reports). After that I have to go through the above procedure tapping on my home wifi to reconnect.

[Michael Mess (michael-michaelmess)]

I have noticed this issue as the backup via backuppc works only when the mobile device is available in the local network.

Then I have to manually reconnect the mobile device before a backup can take place.

This has worked well before.

By the way, I have experienced a similar issue on my Thinkpad that does not always connects to the network when it is available. Restarting network-manager one or more times used to solve the issue or connecting manually to the network.

On other computers the issue seems not to occur.

Could this be a broken-configuration issue?

[Michael Mess (michael-michaelmess)]

Could probably be related to: Bug #1316634

[Michael Mess (michael-michaelmess)]

Seems still be broken in 16.04.1 LTS Desktop.
Note: The network I was experiencing this issue with is a hidden WLAN network. When using a visible WLAN network, the issue might not occur.

Command line Workaround (see Bug #1542733) works for me to reconnect manually (tested only on Desktop)
nmcli c up id <WiFiSSID>

But I would expect that a reconnect always takes place automatically and in a timely manner.
But my experience is: Sometimes it works, but often it does not.

Can someone confirm that it is related to a hidden WLAN network?