Closed
Bug 727690
Opened 12 years ago
Closed 12 years ago
Wifi doesn't reconnect after restarting the b2g process
Categories
(Core :: DOM: Device Interfaces, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: cjones, Assigned: mrbkap)
Details
Attachments
(1 file)
3.04 KB,
patch
|
mrbkap
:
review+
|
Details | Diff | Splinter Review |
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
Reporter | ||
Comment 1•12 years ago
|
||
mrbkap, mwu have you guys seen this?
Comment 2•12 years ago
|
||
I have seen this.
Assignee | ||
Comment 3•12 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•12 years ago
|
Assignee: nobody → mrbkap
Assignee | ||
Comment 4•12 years ago
|
||
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•12 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•12 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/64d8bba7047f (a while ago)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•