Closed Bug 766837 Opened 12 years ago Closed 12 years ago

[Otoro]: Wifi fails after toggling off->on

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
DeveloperPhone

People

(Reporter: vliu, Unassigned)

Details

Attachments

(1 file)

Tips to describe this issue.
1. Wifi can scan the device on the first run.
2. After toggle off -> on, the wifi fails to open RFKILL control device.

I tried to enable DEBUG in /gecko/dom/wifi/WifiWorker.js. I found some logs when I toggle off in step 2.

I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=-1 state=3 BSSID=00:00:00:00:00:00
I/Gecko   (  115): -*- WifiWorker component: State change: INACTIVE -> SCANNING
I/wpa_supplicant(  227): wlan0: CTRL-EVENT-TERMINATING 
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=-1 state=0 BSSID=00:00:00:00:00:00
I/Gecko   (  115): -*- WifiWorker component: State change: SCANNING -> DISCONNECTED
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 0 d8:c7:c8:eb:17:22
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 3 d8:c7:c8:eb:17:20
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 1 d8:c7:c8:eb:18:42
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 2 d8:c7:c8:eb:17:72
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 4 d8:c7:c8:eb:18:40
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 7 d8:c7:c8:eb:17:d2
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 5 d8:c7:c8:eb:16:c2
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 6 d8:c7:c8:eb:17:70
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-REMOVED 8  d8:c7:c8:eb:15:f1
                                  :
I/Gecko   (  115): -*- WifiWorker component: Event coming in: CTRL-EVENT-TERMINATING 
I/Gecko   (  115): -*- WifiWorker component: State change: DISCONNECTED -> DISCONNECTED
I/Gecko   (  115): -*- WifiWorker component: Supplicant died!

Does it any wrong to off the wifi in the first run?
Target Milestone: --- → DeveloperPhone
Summary: Wifi fails to open RFKILL control device in the second run to enable. → [Otoro]: Wifi fails after toggling off->on
I found two issues block wifi turning on.
1. When wifi kernel module prepared to load, DRIVER_PROP_NAME sets to "ok" before it physically load completed. The "ok" leads the wpa_supplicant start running. In this situation, wpa_supplicant can't find wlan0 to link the interface. Adding a delay to wait for driver completely to load. 

2. In wifi_start_supplicant_common() function, the system returns fail because there is no wifi.wpa_supp_ready in property field. 

I modified the code as workaround to fix this issue. May I ask for mwu's suggestion?
Attachment #637799 - Flags: feedback?(mwu)
(In reply to vliu from comment #1)
> Created attachment 637799 [details] [diff] [review]
> Patch file to solve this issue.
> 
> I found two issues block wifi turning on.
> 1. When wifi kernel module prepared to load, DRIVER_PROP_NAME sets to "ok"
> before it physically load completed. The "ok" leads the wpa_supplicant start
> running. In this situation, wpa_supplicant can't find wlan0 to link the
> interface. Adding a delay to wait for driver completely to load. 
> 

Blake, what do you think? 

> 2. In wifi_start_supplicant_common() function, the system returns fail
> because there is no wifi.wpa_supp_ready in property field. 
> 

This is already fixed. Do a repo update and delete your out/target/product/otoro/obj/EXECUTABLES/wpa_* directories.
(In reply to Michael Wu [:mwu] from comment #2)
> Blake, what do you think? 

This is basically what I found in bug 769227. I just pushed that to central. If people feel that it's a lot cleaner to do this in wifi.c, we can use this patch. I have a mild preference for doing it in gecko (if for no other reason than to avoid modifying wifi.c), though.
(In reply to Blake Kaplan (:mrbkap) from comment #3)
> (In reply to Michael Wu [:mwu] from comment #2)
> > Blake, what do you think? 
> 
> This is basically what I found in bug 769227. I just pushed that to central.
> If people feel that it's a lot cleaner to do this in wifi.c, we can use this
> patch. I have a mild preference for doing it in gecko (if for no other
> reason than to avoid modifying wifi.c), though.

I think putting modification in gecko is much better then in libhardwar_legacy because we won't extra fork for wifi.
Great, marking this as fixed then, as everything has landed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Attachment #637799 - Flags: feedback?(mwu)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: