Last Comment Bug 727690 - Wifi doesn't reconnect after restarting the b2g process
: Wifi doesn't reconnect after restarting the b2g process
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: DOM: Device Interfaces (show other bugs)
: Trunk
: ARM Gonk (Firefox OS)
: -- normal (vote)
: ---
Assigned To: Blake Kaplan (:mrbkap) (please use needinfo!)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-15 18:47 PST by Chris Jones [:cjones] inactive; ni?/f?/r? if you need me
Modified: 2012-03-20 12:15 PDT (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Proposed fix (3.04 KB, patch)
2012-02-20 04:04 PST, Blake Kaplan (:mrbkap) (please use needinfo!)
mrbkap: review+
Details | Diff | Review

Description Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-02-15 18:47:50 PST
STR
 (1) Load b2g.  Wait for wifi to connect.
 (2) Open browser app, ensure wifi is connected.
 (3) make kill-b2g
 (4) Repeat steps (1) and (2)

I expect wifi to reconnect.  It doesn't.  |adb reboot| connects back successfully.

From logcat, it appears that we're connecting to the AP but dhcp is failing:

[snip]
I/Gecko   ( 2914): -*- nsWifiWorker component: Event coming in: Associated with 00:14:bf:9c:90:9c
I/Gecko   ( 2914): -*- nsWifiWorker component: Got weird event, possibly not doing anything.
I/Gecko   ( 2914): -*- nsWifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=0 state=7 BSSID=00:00:00:00:00:00
I/Gecko   ( 2914): -*- nsWifiWorker component: State change: ASSOCIATED -> COMPLETED
I/Gecko   ( 2914): -*- nsWifiWorker component: Event coming in: CTRL-EVENT-CONNECTED - Connection to 00:14:bf:9c:90:9c completed (reauth) [id=0 id_str=]
I/Gecko   ( 2914): -*- nsWifiWorker component: State change: COMPLETED -> CONNECTED
E/libnetutils( 2914): dhcp start cmd interface : [dhcpcd:-ABK eth0] 
D/libnetutils( 2914): Wait for the dhcpcd to return a result
E/lights  ( 2914): write_int: path /sys/class/backlight/pwm-backlight/brightness, value 0
E/lights  ( 2914): write_int: path /sys/class/backlight/pwm-backlight/brightness, value 0
E/lights  ( 2914): write_int: path /sys/class/backlight/pwm-backlight/brightness, value 255
E/lights  ( 2914): write_int: path /sys/class/backlight/pwm-backlight/brightness, value 0
I/Gecko   ( 2914): -*- nsWifiWorker component: DHCP failed to run
Comment 1 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2012-02-15 18:48:08 PST
mrbkap, mwu have you guys seen this?
Comment 2 Philipp von Weitershausen [:philikon] 2012-02-15 19:00:18 PST
I have seen this.
Comment 3 Blake Kaplan (:mrbkap) (please use needinfo!) 2012-02-16 11:13:37 PST
I thought this would be an easy bug to fix, but Samsung has changed something in libhardware_legacy.so which makes it not able to reconnect to an already-running wpa_supplicant. So the patches I tried today didn't work. I'll try to write a patch tomorrow that follows a different path to glory and doesn't require us to reconnect to wpa_supplicant.
Comment 4 Blake Kaplan (:mrbkap) (please use needinfo!) 2012-02-20 04:04:55 PST
Created attachment 598823 [details] [diff] [review]
Proposed fix

In order to redo DHCP, we have to kill the server and start it again later. Because we don't have any UI right now, the only way for a DHCP request to be active is if we were killed and are now reconnecting. This also kills the wpa_supplicant (if necessary) on startup since it seems to be unhappy if it does as the result of the interface dying on it.
Comment 5 Blake Kaplan (:mrbkap) (please use needinfo!) 2012-02-20 04:09:00 PST
Comment on attachment 598823 [details] [diff] [review]
Proposed fix

r=gal over my shoulder.
Comment 6 Blake Kaplan (:mrbkap) (please use needinfo!) 2012-03-20 12:15:21 PDT
http://hg.mozilla.org/mozilla-central/rev/64d8bba7047f (a while ago)

Note You need to log in before you can comment on or make changes to this bug.