The default bug view has changed. See this FAQ.

Wifi doesn't reconnect after restarting the b2g process

RESOLVED FIXED

Status

()

Core
DOM: Device Interfaces
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: cjones, Assigned: mrbkap)

Tracking

Trunk
ARM
Gonk (Firefox OS)
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
(Assignee)

Comment 3

5 years ago
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)

Updated

5 years ago
Assignee: nobody → mrbkap
(Assignee)

Comment 4

5 years ago
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.
Attachment #598823 - Flags: review?(gal)
(Assignee)

Comment 5

5 years ago
Comment on attachment 598823 [details] [diff] [review]
Proposed fix

r=gal over my shoulder.
Attachment #598823 - Flags: review?(gal) → review+
(Assignee)

Comment 6

5 years ago
http://hg.mozilla.org/mozilla-central/rev/64d8bba7047f (a while ago)
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.