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)
Tracking
(blocking-basecamp:+, firefox18 fixed, firefox19 fixed, firefox20 fixed)
RESOLVED
FIXED
blocking-basecamp | + |
People
(Reporter: nhirata, Assigned: vchang)
References
Details
(Keywords: otoro, regression, unagi)
Attachments
(2 files, 1 obsolete file)
32.23 KB,
text/plain
|
Details | |
2.46 KB,
patch
|
mrbkap
:
review+
|
Details | Diff | Splinter Review |
## 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?
Updated•13 years ago
|
Keywords: regression
Comment 1•13 years ago
|
||
This is a unagi specific issue, I don't see it on Otoro.
Assignee | ||
Comment 2•13 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.
Comment 3•13 years ago
|
||
I see it on Otoro.
Assignee | ||
Comment 4•13 years ago
|
||
Hi mrbkap,
Assignee | ||
Comment 5•13 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•13 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•13 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•13 years ago
|
Component: Gaia::System → General
Comment 9•13 years ago
|
||
(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.
Comment 10•13 years ago
|
||
Assignee | ||
Comment 11•13 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•13 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.
Comment 13•13 years ago
|
||
(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•13 years ago
|
blocking-basecamp: ? → +
Comment 14•13 years ago
|
||
(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•13 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•13 years ago
|
||
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 17•13 years ago
|
||
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•13 years ago
|
||
Updated the patch to address the review comments
Attachment #683912 -
Attachment is obsolete: true
Attachment #684301 -
Flags: review?(mrbkap)
Comment 19•13 years ago
|
||
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•13 years ago
|
Keywords: checkin-needed
Assignee | ||
Comment 20•13 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.
Comment 21•13 years ago
|
||
Keywords: checkin-needed
Comment 22•13 years ago
|
||
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 23•13 years ago
|
||
I'm still seeing this on unagi with the 11-27 stable build. I sent a wifi log to mrbkap.
Comment 25•13 years ago
|
||
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.
Comment 27•11 years ago
|
||
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 → ---
Comment 28•11 years ago
|
||
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 ago → 11 years ago
Resolution: --- → FIXED
Comment 29•11 years ago
|
||
(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.
Description
•