807148 - B2G Wifi: Make sure we successfully turn on background scanning

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect, P1)

Description

[Blake Kaplan (:mrbkap) (inactive)]

In bug 796640, comment 33, Vincent mentioned that it was possible for background scanning to fail (I assume that there's a race somewhere). We need to make sure that doesn't happen.

This should probably block basecamp as if it fails, the supplicant gets stuck.

Comment 1

[Andrew Overholt [:overholt]]

Blake, can you take this (if we decide to block on it)?

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Proposed patch v1

This patch makes sure that when we turn on background scanning the supplicant is idle, which should ensure that the operation never fails. This patch has the side-effect of fixing bug 807136 at the same time. The approach is explained in the large comment that I add in it: when we enter the scanning state, we wait a "while" and if we don't either change state or get scan results in that time, we tell the supplicant to disconnect, turn on background scanning, and try again.

I want to get this in as soon as possible, so I'm asking double review from both gal and Vincent. All comments on this approach are appreciated!

To be clear, this should also fix bug 796640, comment 33. Vincent, please let me know if you can confirm.

Comment 3

[Andreas Gal :gal]

mwu, can you reach out to the vendor and ask them to fix this in the driver?

Comment 4

[Andreas Gal :gal]

Comment on attachment 678474 [details] [diff] [review]
Proposed patch v1

Review of attachment 678474 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/wifi/WifiWorker.js
@@ +1468,5 @@
> +  // forceably try to unstick the supplican, also turning on background
> +  // scanning to avoid having to constantly poke the supplicant.
> +
> +  // How long we wait is controlled by the SCAN_STUCK_WAIT constant.
> +  const SCAN_STUCK_WAIT = 10000;

Can a scan ever take longer than 10s? Any other way to detect that we are stuck?

Why are we not always using background scanning?

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Patch that doesn't work

This was an attempt to fix this bug more cleanly; however, it doesn't work because we don't actually get an error message when the schedule scan stuff fails (I had forgotten that when I wrote this). I think I convinced gal to stamp the first patch.

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 678586 [details] [diff] [review]
Patch that doesn't work

Oh, and this actually applies on top of attachment 678747 [details] [diff] [review] for those of you playing at home.

Comment 7

[Vincent Chang[:vchang][changyihsin]]

(In reply to Blake Kaplan (:mrbkap) from comment #2)
> Created attachment 678474 [details] [diff] [review]
> Proposed patch v1
> 
> This patch makes sure that when we turn on background scanning the
> supplicant is idle, which should ensure that the operation never fails. This
> patch has the side-effect of fixing bug 807136 at the same time. The
> approach is explained in the large comment that I add in it: when we enter
> the scanning state, we wait a "while" and if we don't either change state or
> get scan results in that time, we tell the supplicant to disconnect, turn on
> background scanning, and try again.
> 
> I want to get this in as soon as possible, so I'm asking double review from
> both gal and Vincent. All comments on this approach are appreciated!
> 
> To be clear, this should also fix bug 796640, comment 33. Vincent, please
> let me know if you can confirm.

I am trying to verify it, will let you know my result in couple of hours. :)

Comment 8

[Vincent Chang[:vchang][changyihsin]]

Attachment: wifi scan fail log

I try to verify this patch, it's almost ok. But I found that it still may fail. In the attached, you can see "nl80211: Scan trigger failed: ret=-16 (Device or resource busy)" from wpa_supplicant and "Failed to initiate AP scan" from WifiWorker. Disable/Enable wifi can't recovery it. I need to restart the device. Looks like the wifi driver is broken. 

STR, 
   1. connect to AP, the security type is set to wpa-psk. 
   2. turn off AP, and wait for about 15 seconds.
   3. turn on AP, unagi should connect to the same AP automatically. 
   4. repeat step 2,3 for several times(not sure how many times, maybe 3 or 4 times is enough)
   5. turn off the screen, unagi is connected to AP before turn off the screen.
   6. wait for 2 minute to let unagi enters sleep mode.(The wifi will be turned off) 
   7. turn on the screen, unagi should try to connect to AP automatically. 

Please don't plug the usb or power adapter to unagi. The wifi will be turned off only when device is not plugged with power source.(gaia/apps/system/js/wifi.js) 

Not sure if you can reproduce it easily, but I have reproduced it several times with above steps.

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

(In reply to Vincent Chang[:vchang] from comment #8)
> Not sure if you can reproduce it easily, but I have reproduced it several
> times with above steps.

I haven't been able to reproduce this at all :( Unfortunately, I don't see anything in the logs that indicates what's going on. I'm going to land the current patch and see how common reports of the problem that you're seeing are (which should be easy to find: it'll be the only problem that isn't fixed by turning on and off wifi).

Comment 10

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 678474 [details] [diff] [review]
Proposed patch v1

Review of attachment 678474 [details] [diff] [review]:
-----------------------------------------------------------------

This patch helps to prevent wpa_supplicant from getting stuck when doing the schedule scan. But it's not easy to recovery the wpa_supplicant in all the cases, especially when the problem is happened in the driver. So let the patch in and we can collect more informations.

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a7e66e18850f

Comment 12

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/a7e66e18850f

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/af2526674ef0