Closed
Bug 766837
Opened 12 years ago
Closed 12 years ago
[Otoro]: Wifi fails after toggling off->on
Categories
(Firefox OS Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
DeveloperPhone
People
(Reporter: vliu, Unassigned)
Details
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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?
Reporter | ||
Updated•12 years ago
|
Target Milestone: --- → DeveloperPhone
Reporter | ||
Updated•12 years ago
|
Summary: Wifi fails to open RFKILL control device in the second run to enable. → [Otoro]: Wifi fails after toggling off->on
Reporter | ||
Comment 1•12 years ago
|
||
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)
Comment 2•12 years ago
|
||
(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.
Comment 3•12 years ago
|
||
(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.
Reporter | ||
Comment 4•12 years ago
|
||
(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.
Comment 5•12 years ago
|
||
Great, marking this as fixed then, as everything has landed.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Attachment #637799 -
Flags: feedback?(mwu)
You need to log in
before you can comment on or make changes to this bug.
Description
•