If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Wifi: Investigate "W/wpa_supplicant( 1537): wlan0: Failed to initiate AP scan"

REOPENED
Unassigned

Status

Firefox OS
General
REOPENED
5 years ago
3 years ago

People

(Reporter: mrbkap, Unassigned)

Tracking

unspecified
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-basecamp:-)

Details

(Reporter)

Description

5 years ago
gal is seeing this in logcat. Looking at the code, it appears to be non-fatal (and that we should recover eventually). My guess is that we'll see this when we're trying to associate with a network and we try to scan.
(Reporter)

Comment 1

5 years ago
Not sure if this has to block, but we should dig into this at least a little before release. I'd assume that the possible fallout is that the available wifi network list wouldn't show up randomly.
blocking-basecamp: --- → ?

Updated

5 years ago
Assignee: nobody → vchang
Wifi flakiness is not cool, blocking+. Blake, who's the right person to assign this to?
blocking-basecamp: ? → +
Keywords: qawanted

Updated

5 years ago
blocking-basecamp: + → ?

Comment 3

5 years ago
Vincent Chang was assigned to this issue.
I can't reproduce this issue on Otoro device.  
Mozilla Central:
changeset:   101269:89dcadd42ec4
parent:      101214:030feb4315fc
parent:      101268:38b216220e60
date:        Thu Aug 02 22:00:53 2012 -0400

Gaia:
commit cd2d4e0e0287e0e087625fce36c58695d2af89d7
Date:   Thu Aug 2 19:42:10 2012 -0700

However, I found the other issue while doing the testing. 
Bug 780066 - The wifi function doesn't work if the wifi setttings is disabled after rebooting the device.
Closing based on comment #4.  I've basecamp-?'d bug 780066.  Thanks.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
blocking-basecamp: ? → -
When I first flashed, and switch to Pt-BR; I had a moment where it shut off and didn't allow for connecting to any network.  I rebooted the phone and I can connect to a network; however I can still reproduce the message in logcat:

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18/rev/0e43266ca3c6
Gaia   1890022f3ca36108621a832f31ac5df8bf89a22e
BuildID 20130122070203
Version 18.0

I can reproduce on unagi:
1. go to settings
2. go to network
3.  If you are already on a network, switch to a different network
4. hit scan 
5. filter for Failed in logcat.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Keywords: qawanted
This issue can be reproduced with Vendor's wpa_supplicant binary easily.
The STR are
 
1. connect to AP1, 
2. connect to AP2, 
3. turn off AP2, 
4. turn off the screen of unagi , 
5, wait for about 2 minutes. 
6. turn on the screen of unagi  

From the Vendor's information, the issue should be caused by Wifi driver, and is also found in android OS. But it can be recovered by re-opening wifi mannually. 
There is also another mechanism to workaround this issue in Android framework. 
The wpa_supplicant detects the Wifi driver is hung and reports a HUNG UP event. The Android framework detect this and restart the driver by sending "DRIVER STOP" and "DRIVER START" to recover the Wifi.

Maybe we can use the same mechanism to help to recover the wifi when wifi driver gets stuck as well.
Trying to recover the wifi driver using "DRIVER STOP" and "DRIVER START" command. But the wifi driver still get stuck on unagi. Waiting for vendor's feedback to see if this is related wifi firmware.
Assignee: vchang → nobody
You need to log in before you can comment on or make changes to this bug.