727690 - Wifi doesn't reconnect after restarting the b2g process

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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]

mrbkap, mwu have you guys seen this?

Comment 2

[Philipp von Weitershausen [:philikon]]

I have seen this.

Comment 3

[Blake Kaplan (:mrbkap) (inactive)]

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) (inactive)]

Attachment: 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) (inactive)]

Comment on attachment 598823 [details] [diff] [review]
Proposed fix

r=gal over my shoulder.

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

http://hg.mozilla.org/mozilla-central/rev/64d8bba7047f (a while ago)