Closed Bug 972628 Opened 6 years ago Closed 6 years ago

[Buri] Wifi does not reconnect to a previously known AP upon reboot

Categories

(Firefox OS Graveyard :: Wifi, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:1.4+, firefox28 wontfix, firefox29 wontfix, firefox30 fixed, b2g-v1.4 fixed)

RESOLVED FIXED
1.4 S3 (14mar)
blocking-b2g 1.4+
Tracking Status
firefox28 --- wontfix
firefox29 --- wontfix
firefox30 --- fixed
b2g-v1.4 --- fixed

People

(Reporter: onecyrenus, Assigned: chucklee)

Details

(Keywords: regression, Whiteboard: [FT:RIL])

Attachments

(3 files, 1 obsolete file)

1) Boot device, go to settings and associate with an Access Point
2) reboot device
3) device will try to reconnect to the previously associated network and fail
4) if you go back into settings the device will reconnect

Have tried this across multiple builds on my hamachi device. 


Gaia      c52162095093657e6b2eea9c916221f4a708bed2
Gecko     d2ef16927622a687998c32093cc80d5357620a14
BuildID   20140210153504
Version   30.0a1
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013

-- reset version / reflashed

onecyrenus@ubuntu:~/B2G-flash-tool$ ./check_versions.sh 
Gaia      c52162095093657e6b2eea9c916221f4a708bed2
Gecko     1320a8bf897277ed7392d78229a58511c16487cf
BuildID   20131219142759
Version   26.0
ro.build.version.incremental=324
ro.build.date=Thu Dec 19 14:04:55 CST 2013
OS: Mac OS X → Gonk (Firefox OS)
Hardware: x86 → ARM
 LionelM, SergeyA in irc also have noticed this issue.
I think this might be a regression. Can someone check the behavior on 1.3 & 1.1?
Keywords: qawanted
This doesn't happen on my inari device on 1.3. 
The problem seems to be with the interface to the wifi. When purely using the wifi api the device fails.
What I believe to be the problem is that there is an expectation for you to scan all networks before you join a network. Which is how the wifi gets initialized in the settings, and why it works through that interface.
blocking-b2g: --- → 1.3?
blocking-b2g: 1.3? → 1.4?
I spoke with a few testers who have run across this issue on 1.4, they said that the repro rate is low about 3 out of 20 attempts. Also, they cannot repro on 1.3 using a Buri device. That being said I am going to remove the regressionwindow-wanted keyword.
Sarah, Can you never connect to the Access Point ever ? Or can you by manually trying to configure again ?
 
Ken, seeems like a couple of people hit the issue and users may hit this regression, any ideas here ? Would any logs from QA help here ?
Flags: needinfo?(kchang)
(In reply to bhavana bajaj [:bajaj] from comment #5)
> Sarah, Can you never connect to the Access Point ever ? Or can you by
> manually trying to configure again ?

Manual reconfiguration would be required.
(In reply to bhavana bajaj [:bajaj] from comment #5)
> Sarah, Can you never connect to the Access Point ever ? Or can you by
> manually trying to configure again ?
>  
> Ken, seeems like a couple of people hit the issue and users may hit this
> regression, any ideas here ? Would any logs from QA help here ?

I suspect maybe the configure doesn't write to wifi config file.

I need Log with wifi debug enabled while it happened.
Also wifi config file on device: /data/misc/wifi/wpa_supplicant.conf. It will contain AP passwords, make sure you remove them before attach the file.
(In reply to Chuck Lee [:chucklee] from comment #7)
> (In reply to bhavana bajaj [:bajaj] from comment #5)
> > Sarah, Can you never connect to the Access Point ever ? Or can you by
> > manually trying to configure again ?
> >  
> > Ken, seeems like a couple of people hit the issue and users may hit this
> > regression, any ideas here ? Would any logs from QA help here ?
> 
> I suspect maybe the configure doesn't write to wifi config file.
> 
> I need Log with wifi debug enabled while it happened.
> Also wifi config file on device: /data/misc/wifi/wpa_supplicant.conf. It
> will contain AP passwords, make sure you remove them before attach the file.

Okay - QA Wanted to do the following when the bug is reproduced:

* Get a logcat with wifi output in adb enabled & console enabled set
* Email Chuck and cc me privately with the file /data/misc/wpa_supplicant.conf
Flags: needinfo?(kchang)
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #8)
> * Email Chuck and cc me privately with the file
> /data/misc/wpa_supplicant.conf

typo here, the file path is /data/misc/wifi/wpa_supplicant.conf
Attached file wifi_log.txt (obsolete) —
Attached is a wifi log that I had from a reboot. 

I also had attached to the navigator.mozWifiManager.onstatusChange and I dumped the status changes as they arrived on the device. 

Let me know if this provides any assistance.
(In reply to dclarke@mozilla.com  [:onecyrenus] from comment #10)
> Created attachment 8384203 [details]
> wifi_log.txt
> 
> Attached is a wifi log that I had from a reboot. 
> 
> I also had attached to the navigator.mozWifiManager.onstatusChange and I
> dumped the status changes as they arrived on the device. 
> 
> Let me know if this provides any assistance.

Hi,
  I also need BSSID of AP, and wpa_supplicant.conf(make sure you remove/replace you password).
(In reply to dclarke@mozilla.com  [:onecyrenus] from comment #10)
> Created attachment 8384203 [details]
> wifi_log.txt
> 
> Attached is a wifi log that I had from a reboot. 
> 
> I also had attached to the navigator.mozWifiManager.onstatusChange and I
> dumped the status changes as they arrived on the device. 
> 
> Let me know if this provides any assistance.

Wifi debug seems not be enabled successfully, or it should show more detail about wifi manger(including state change and error message).
Please make sure you enabled it in Settings/Developer/Wi-Fi output in adb. If you set DEBUG flag in WifiWoker.js directly, it will be overwritten by settings at runtime.
Whiteboard: [FT:RIL]
Faramarz, is that what you also experience on your Peak?
:chucklee, I will do this, the device is no longer in this state however
:fabrice, yes i'm only dogfooding a Peak right now.  this may be specific to a Peak device but worth checking on others as well.
blocking-b2g: 1.4? → 1.4+
Chuck is working on this, but he needs logs.
Assignee: nobody → chulee
Attached file bug972628_log.txt
Attachment #8384203 - Attachment is obsolete: true
Attached file bug972628_wpa.conf
These are my logs for what it is worth. 

I have a code snippet that basically does the following: 

manager.onenabled = function () {
     dump("----------------in on enabled-----------------\n");
     if(wifiSettings) {
         manager.associate(wifiSettings);
     }
   };

Basically whenever we try to associate with a previously known, and possibly already connected network, I believe that there is a failure.
Keywords: qawanted
(In reply to dclarke@mozilla.com  [:onecyrenus] from comment #18)
> Created attachment 8387544 [details]
> bug972628_wpa.conf
> 
> These are my logs for what it is worth. 
> 
> I have a code snippet that basically does the following: 
> 
> manager.onenabled = function () {
>      dump("----------------in on enabled-----------------\n");
>      if(wifiSettings) {
>          manager.associate(wifiSettings);
>      }
>    };
> 
> Basically whenever we try to associate with a previously known, and possibly
> already connected network, I believe that there is a failure.

Thank you for the data. :)

All network settings are marked with "disabled=1", that's why these APs are not reconnected.
Gecko only modifies this value by calling enableNetwork()[1] and disableNetwork()[2]. Also, all networks should be re-enabled while enabling wifi[3].

I think I'll check why the re-enable doesn't work first.
The network list in wpa_supplicant shows:
> > list
network id / ssid / bssid / flags
0	Mozilla Guest	any	[DISABLED]
1	Mozilla Guest	any	[DISABLED]
2	Mozilla Guest	any	[DISABLED]
3	Mozilla Guest	any	[DISABLED]
4	Mozilla Guest	any	[DISABLED]
5	Mozilla Guest	any	[DISABLED]
6	Mozilla Guest	any	[DISABLED]
7	Mozilla Guest	any	[DISABLED]
8	Mozilla Guest	any	[DISABLED]
9	Mozilla Guest	any	[DISABLED]
10	Mozilla Guest	any	[DISABLED]
11	Mozilla Guest	any	[DISABLED]
12	Mozilla Guest	any	[DISABLED]
13	Mozilla Guest	any	[DISABLED]
14	Mozilla Guest	any	[DISABLED]
15	Mozilla Guest	any	[DISABLED]
16	Mozilla Guest	any	[DISABLED]
17	Mozilla Guest	any	[DISABLED]
18	Mozilla Guest	any	[DISABLED]
19	Mozilla Guest	any	[DISABLED]
20	Mozilla Guest	any	[DISABLED]
21	Mozilla Guest	any	[DISABLED]
22	Mozilla Guest	any	[DISABLED]
23	Mozilla Guest	any	[DISABLED]
24	Mozilla Guest	any	[DISABLED]
25	Mozilla Guest	any	[DISABLED]
26	Mozilla Guest	any	[DISABLED]
27	Mozilla Guest	any	[DISABLED]
28	Mozilla Guest	any	[DISABLED]
29	Mozilla Guest	any	[DISABLED]
30	Mozilla Guest	any	[DISABLED]
31	Mozilla Guest	any	[DISABLED]
32	Mozilla Guest	any	
33	Freeeeeee	any	[DISABLED]
34	Freeeeeee	any	[DISABLED]
35	Freeeeeee	any	[DISABLED]
36	Freeeeeee	any	[DISABLED]
37	Freeeeeee	any	[DISABLED]
38	Freeeeeee	any	[DISABLED]
39	Freeeeeee	any	
40	AuCoquelet	any	[DISABLED]
41	AuCoquelet	any	[DISABLED]
42	AuCoquelet	any	[DISABLED]
43	AuCoquelet	any	[DISABLED]
44	AuCoquelet	any	[DISABLED]
45	Aucoquelet	any	[DISABLED]
46	Aucoquelet	any	
47	AuCoquelet	any	
48	Mozilla Guest	any	

And per my test log, only network #39, #46, #47, #48 is enabled by gecko after connect to wpa_supplicant.
It seems that wpa_supplicant treat each network config differently even they are identical, while gecko will only last one of the same network config.

I think we can make gecko delete those redundant network config in wpa_supplicant to resolve the problem.
On the other hand, we also need to find out why there are so many configs saved for same network, might be something wrong in the forget().
(In reply to dclarke@mozilla.com  [:onecyrenus] from comment #18)
> Created attachment 8387544 [details]
> bug972628_wpa.conf

Hi, Can you remember what operations you do to wifi(like enable, disable, connect to certain network, forget certain network, etc) before this bug happens?
Flags: needinfo?(dclarke)
Remove network with empty ssid and redundant network while load network config.
Attachment #8388395 - Flags: review?(vchang)
Chuck, 
  Yes normally

Turn off Wifi
Turn on Wifi
associate


rinse and repeat.
Flags: needinfo?(dclarke)
Comment on attachment 8388395 [details] [diff] [review]
Remove redundant network while loading network config.

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

Looks good, thank you.
Attachment #8388395 - Flags: review?(vchang) → review+
Hi David,
    Though the reproduce rate is not high, can you apply the test with the attached patch?
Flags: needinfo?(dclarke)
PM triage this bug.  It should be 1.4+.
https://hg.mozilla.org/mozilla-central/rev/e574778a8563
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.4 S3 (14mar)
Chuck, 
   This seems to resolve the issue for me.
Flags: needinfo?(dclarke)
You need to log in before you can comment on or make changes to this bug.