Closed Bug 811833 Opened 13 years ago Closed 11 years ago

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

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

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

RESOLVED FIXED
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed

People

(Reporter: nhirata, Assigned: vchang)

References

Details

(Keywords: otoro, regression, unagi)

Attachments

(2 files, 1 obsolete file)

## 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?
This is a unagi specific issue, I don't see it on Otoro.
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.
Hi mrbkap,
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.
(In reply to Dietrich Ayala (:dietrich) from comment #3) > I see it on Otoro. Can you provide wpa_supplicant.conf in your otoro phone ?
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.
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.
(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 } ============================================================
(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,
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?
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.
Attached patch Patch v1.0 (obsolete) — Splinter Review
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)
Attached patch Patch v1.1Splinter Review
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+
Keywords: checkin-needed
(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.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → 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.
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
Closed: 13 years ago11 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.

Attachment

General

Created:
Updated:
Size: