[System] When the device is woken from sleep, wifi does not automatically connect to the network

RESOLVED FIXED

Status

Firefox OS
General
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: nhirata, Assigned: vchang)

Tracking

({otoro, regression, unagi})

unspecified
ARM
Gonk (Firefox OS)
otoro, regression, unagi

Firefox Tracking Flags

(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)

Details

Attachments

(2 attachments, 1 obsolete attachment)

## Environment :
Unagi phone, build 20121114
  
## Repro :
1. connect device to network through settings
2. let the device sleep
3. wake the device

## Expected :
1. network connection is established

## Actual :
1. you have to go to the settings, where wifi will then automatically turn back on and then select a network

## Note :
1. regression?
Keywords: regression
This is a unagi specific issue, I don't see it on Otoro.
(Assignee)

Comment 2

5 years ago
Finally I can see this bug from Tim's unagi phone. It's weird that others unagi phone don't have this bug. 

Can I have your device's wifi configuration file located in /data/misc/wifi/wpa_supplicant.conf ? In that file, you can find that parameter "disabled" is set to 1. It means the network is disabled and wpa_supplicant will not try to connect to the network automatically.  
network={
	ssid="Mozilla Guest"
	key_mgmt=NONE
	priority=9
	disabled=1
}
However, if I delete the wpa_supplicant.conf by hand, and try to reproduce the bug again. I can't reproduce the problem anymore. The "disabled" parameter is disappeared.   
network={
	ssid="Mozilla Guest"
	key_mgmt=NONE
}

Will try to check what's going on there.
I see it on Otoro.
(Assignee)

Comment 4

5 years ago
Hi mrbkap,
(Assignee)

Comment 5

5 years ago
Hi mrbkap, 

I am wondering if there is a case that we disable certain network using DISABLE_NETWORK command and save that config to wpa_supplicant.conf using "SAVE_CONFIG" command. In that case, we could have "disabled=1" in wpa_supplicant.conf.
(Assignee)

Comment 6

5 years ago
(In reply to Dietrich Ayala (:dietrich) from comment #3)
> I see it on Otoro.

Can you provide wpa_supplicant.conf in your otoro phone ?
(Assignee)

Comment 7

5 years ago
I find this bug after doing the FOTA. I don't observe the same bug if I update firmware from nightly build manually. Not sure what's the difference between these two methods.
(Assignee)

Updated

5 years ago
Component: Gaia::System → General
Vincent, I need my dogfood phone back :)
Assignee: nobody → vchang
(In reply to Vincent Chang[:vchang] from comment #7)
> I find this bug after doing the FOTA. I don't observe the same bug if I
> update firmware from nightly build manually. Not sure what's the difference
> between these two methods.

To clarify, we've only supplied OTA (i.e gecko only) updates to dogfooders so far. The first FOTA update will be coming shortly.

The dogfood / stable URL is only updated once a week right now -- so this could also be a difference in bugs fixed on nightly vs stable.
Created attachment 682531 [details]
otoro wpa_supplicant.conf
(Assignee)

Comment 11

5 years ago
(In reply to Dietrich Ayala (:dietrich) from comment #10)
> Created attachment 682531 [details]
> otoro wpa_supplicant.conf
The file itself looks no problem. After associating with an AP(Mozilla Guest), the wpa_supplicant.conf will be updated as below. 
============================================================
ctrl_interface=DIR=/data/system/wpa_supplicant GROUP=wifi
update_config=1
wfd_session_mgmt_ctrl_port=554
wfd_device_max_throughput=10

network={
	ssid="Mozilla Guest"
	key_mgmt=NONE
}
============================================================
(Assignee)

Comment 12

5 years ago
(In reply to Marshall Culpepper [:marshall_law] from comment #9)
> (In reply to Vincent Chang[:vchang] from comment #7)
> > I find this bug after doing the FOTA. I don't observe the same bug if I
> > update firmware from nightly build manually. Not sure what's the difference
> > between these two methods.
> 
> To clarify, we've only supplied OTA (i.e gecko only) updates to dogfooders
> so far. The first FOTA update will be coming shortly.
> 
> The dogfood / stable URL is only updated once a week right now -- so this
> could also be a difference in bugs fixed on nightly vs stable.

I also tried to reproduce the bug with my unagi, but it's weird, I can't reproduce the bug. May need to borrow Tim's dogfooding phone and try again. 

Does it only update /system/b2g ? The update process seems to get two files, one is b2g_stable_update_2012-11-15_102959.mar the other one is update.zip. Not sure the difference between these two files.
(In reply to Vincent Chang[:vchang] from comment #12)
> Does it only update /system/b2g ? The update process seems to get two files,
> one is b2g_stable_update_2012-11-15_102959.mar the other one is update.zip.
> Not sure the difference between these two files.

Sounds like you do have the FOTA update :) MAR is a custom archive format used for gecko updates, and update.zip is the archive that google's FOTA client uses. In summary:

- FOTA (full / system) updates wrap an update.zip inside the MAR so we can reuse the existing Gecko delivery code. These updates can write to any partition on the device

- OTA (gecko + gaia) updates are MARs with files that map to /system/b2g. An OTA update can't touch anything outside of /system/b2g,

Updated

5 years ago
blocking-basecamp: ? → +
(In reply to Vincent Chang[:vchang] from comment #5)
> I am wondering if there is a case that we disable certain network using
> DISABLE_NETWORK command and save that config to wpa_supplicant.conf using
> "SAVE_CONFIG" command. In that case, we could have "disabled=1" in
> wpa_supplicant.conf.

I've been worrying about that. It might make sense to make sure that we only ever write out disabled=0 (enabled) networks and maybe also ensuring that all networks that we read in are enabled. Mind writing that patch?

Comment 15

5 years ago
I was able to easily reproduce this on the 11/16 nightly build, but then I updated my phone today and now it crashes randomly.  I'll see if I can get my phone in a state to debug.
(Assignee)

Comment 16

5 years ago
Created attachment 683912 [details] [diff] [review]
Patch v1.0

This patch forces to enable the network when we connect to wpa_supplicant. Also, enable the network when _needToEnableNetworks is true.
Attachment #683912 - Flags: review?(mrbkap)
Comment on attachment 683912 [details] [diff] [review]
Patch v1.0

Review of attachment 683912 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/wifi/WifiWorker.js
@@ +1779,2 @@
>      var currentNetwork = self.currentNetwork;
> +    if (currentNetwork && currentNetwork.netId) {

The second check should check that currentNetwork.netId is a number. 0 is a valid netId.

@@ +1779,4 @@
>      var currentNetwork = self.currentNetwork;
> +    if (currentNetwork && currentNetwork.netId) {
> +      // Remove the network when the user entered an incorrect password.
> +      WifiManager.removeNetwork(currentNetwork.netId, function(ok) {

I don't understand why we're removing the network now instead of disabling it. Can you explain?

@@ +1788,5 @@
> +        });
> +      });
> +    } else {
> +      // TODO Bug-813880, we can't get netId when connecting to wep network. 
> +      WifiManager.disconnect(function(ok) {dump("disconnected current network")});

Nits: "Bug 813880" and trailing whitespace.

Non-nits: Please use debug() instead of dump(). Also, if you call disconnect, you should call reassociate afterwards, since disconnect tells wpa_supplicant to wait until we do so before it tries to connect to any more networks.
Attachment #683912 - Flags: review?(mrbkap)
(Assignee)

Comment 18

5 years ago
Created attachment 684301 [details] [diff] [review]
Patch v1.1

Updated the patch to address the review comments
Attachment #683912 - Attachment is obsolete: true
Attachment #684301 - Flags: review?(mrbkap)
Comment on attachment 684301 [details] [diff] [review]
Patch v1.1

Review of attachment 684301 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. One small comment, but let's get this in.

::: dom/wifi/WifiWorker.js
@@ +1779,2 @@
>      var currentNetwork = self.currentNetwork;
> +    if (currentNetwork && !isNaN(currentNetwork.netId)) {

Instead of using isNaN, why not use |typeof currentNetwork.netId === "number"| since we don't actually use NaN anywhere else in the file?
Attachment #684301 - Flags: review?(mrbkap) → review+
(Assignee)

Updated

5 years ago
Keywords: checkin-needed
(Assignee)

Comment 20

5 years ago
(In reply to Blake Kaplan (:mrbkap) from comment #19)
> Comment on attachment 684301 [details] [diff] [review]
> Patch v1.1
> 
> Review of attachment 684301 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks good. One small comment, but let's get this in.
> 
> ::: dom/wifi/WifiWorker.js
> @@ +1779,2 @@
> >      var currentNetwork = self.currentNetwork;
> > +    if (currentNetwork && !isNaN(currentNetwork.netId)) {
> 
> Instead of using isNaN, why not use |typeof currentNetwork.netId ===
> "number"| since we don't actually use NaN anywhere else in the file?

Thanks for your suggestion, let me do it in Bug 813880.
https://hg.mozilla.org/integration/mozilla-inbound/rev/85c1a0de5374
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/85c1a0de5374
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
https://hg.mozilla.org/releases/mozilla-aurora/rev/06329b918184
https://hg.mozilla.org/releases/mozilla-beta/rev/dde5165cc0df
status-firefox18: --- → fixed
status-firefox19: --- → fixed
status-firefox20: --- → fixed
I'm still seeing this on unagi with the 11-27 stable build.  I sent a wifi log to mrbkap.
I think that we determined with cjones that this was somehow related to his wpa_supplicant.conf and once he blew the existing one away and re-configured his network, it started to work.
Duplicate of this bug: 806668
I'm reopening this bug due to a behavior I see on a Peak device (1.3 pre-release build).  Wifi does not reconnect to known networks previously connected to.

STR:
1. connect to a wifi.
2. move out of range (outside the building etc).
3. return to wifi location.

## Expected:
device should reconnect to the previously known wifi it was connected to.

## Actual:
device does not connect.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This is an old bug - I'm going to open a new bug for this issue you are seeing.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago4 years ago
Resolution: --- → FIXED
(In reply to Jason Smith [:jsmith] from comment #28)
> This is an old bug - I'm going to open a new bug for this issue you are
> seeing.

I opened bug 979655 for the issue seen in comment 27.
You need to log in before you can comment on or make changes to this bug.