Closed Bug 727690 Opened 9 years ago Closed 9 years ago

Wifi doesn't reconnect after restarting the b2g process

Categories

(Core :: DOM: Device Interfaces, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: cjones, Assigned: mrbkap)

Details

Attachments

(1 file)

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
mrbkap, mwu have you guys seen this?
I have seen this.
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.
Assignee: nobody → mrbkap
Attached patch Proposed fixSplinter Review
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.
Attachment #598823 - Flags: review?(gal)
Comment on attachment 598823 [details] [diff] [review]
Proposed fix

r=gal over my shoulder.
Attachment #598823 - Flags: review?(gal) → review+
http://hg.mozilla.org/mozilla-central/rev/64d8bba7047f (a while ago)
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.