1102639 - [Midori 2.0][FF2.0][Wi-Fi]Wifi can not search any AP for long time

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Wifi, defect, P2)

Description

[sync-1]

Mozilla Build ID: 20141019000201
 
 DEFECT DESCRIPTION:
 Connect to a wifi network, idle for long time and find wifi keep searching for long time and can not search successfully
 
  REPRODUCING PROCEDURES:
  1.Connect to a wifi network
  2.Idle for long time
  3.Wifi can not search any AP--KO
 
 问题描述：
 连接上一个无线网络，等待很长一段时间之后发现wifi保持搜索状态很长时间而且无法成功搜索到网络
 
 复制步骤：
  1. 连接上无线网络
  2. 等待很长一段时间
  3. wifi搜索不到无线网络--KO
 
 预期结果：
 Wifi不应该一直处在搜索状态
 
  EXPECTED BEHAVIOUR:
 WiFi should not keep searching for long time
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:

Comment 1

[sync-1]

Attachment: log_1119

Comment 2

[sync-1]

Attachment: log

Comment 3

[Wang Rong]

Attachment: logcat log

in this log, open wifi at about 03:26:42, and ap list is shown about 03:27:20.

I have added some logs in gecko and wifi.c in libhardware_legacy, and found that gecko issued "SCAN-ACTIVE" command through aControlMessage() but it never was transferred to wifi.c. and there was no command transferred to wifi.c from 03:26:43 to 03:27:18, that's why it need more than half minutes to show AP list.

I don't know how aControlMessage() works and why it can't transfer command to wifi.c. Please try to explain it and fix it. Thanks.

Comment 4

[Wang Rong]

[Blocking Requested - why for this release]: sometimes it needs about half one minute to show ap list when opening wifi. it's a long time.

Comment 5

[Shine(Leave from Mozilla)]

Please add “this is reproducible in 1.3 SW or not” information to this issue.

Comment 6

[Wang Rong]

there is no such problem found in 1.3 SW.

Comment 7

[Wesly Huang (EPM)]

1. potential regression per comment#6?

2. qawanted to see if repro. in Flame 2.0/2.1/2.2.

3. a candidate for 2.0 blocker.

@Vincent, this is quite basic function and should work, would you help check? Thank you.

Comment 8

[Vincent Chang[:vchang][changyihsin]]

I saw the scan result is received from wpa_supplicant to gecko around the end of "logcat log". Can you help to check if the scan results are passed to gaia? How long do you need to wait to find this bug after connect to wifi AP?

Comment 9

[Cody Roesch [:croesch]]

I see that this reporters build is from over a month ago. (Mozilla Build ID: 20141019000201)
Does the reporter still see this on a recent build?

----------------------------------------------------------------------------------
----------------------------------------------------------------------------------

Flame Test Results:

This bug does NOT repro on Flame kk build: Flame 2.2 KK, Flame 2.1 KK, Flame 2.0 KK

Actual Result: Wifi networks are found and can be connected to within 5 seconds after entering password and tapping OK. Tested a few different available networks. There are no long wait times when trying to connect or searching for Access Points. Checked in both FTU and Settings.

Repro Rate: 0/9

Environmental Variables:
Device: Flame 2.2 KK
BuildID: 20141125035634
Gaia: 824a61cccec4c69be9a86ad5cb629a1f61fa142f
Gecko: acde07cb4e4d
Version: 36.0a1 (2.2) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.1 KK
BuildID: 20141124205132
Gaia: 1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko: db893274d9a6
Version: 34.0 (2.1) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
-----------------------------------------------------------------
Environmental Variables:
Device: Flame 2.0 KK
BuildID: 20141124161832
Gaia: 99e4594c66aa3738d58b0cb44bd885a87a063b6e
Gecko: f91abc6127d9
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

-----------------------------------------------------------------
-----------------------------------------------------------------

Also checked a Nightly build from 10/20/2014

No problems found when searching or connecting to a few different networks. Both FTU and Settings are working correctly.
 
Environmental Variables:
Device: Flame 2.0 Nightly
BuildID: 20141020000206
Gaia: 9c7dec14e058efef81f2267b724dad0850fc07e4
Gecko: c17df9fe087d
Version: 32.0 (2.0) 
Firmware Version: v188-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 10

[Wang Rong]

(In reply to Vincent Chang[:vchang] from comment #8)
> I saw the scan result is received from wpa_supplicant to gecko around the
> end of "logcat log". Can you help to check if the scan results are passed to
> gaia? How long do you need to wait to find this bug after connect to wifi AP?

Dear vincent,
Can you check the logcat log of comment#3? I think problem is not scan result can't be passed to gaia. The problem is scan command can't be passed to wifi.c in HAL. Please pay attention to time range from 03:26:43 to 03:27:18 in the log.thanks.

Comment 11

[Wang Rong]

(In reply to Wang Rong from comment #10)
> (In reply to Vincent Chang[:vchang] from comment #8)
> > I saw the scan result is received from wpa_supplicant to gecko around the
> > end of "logcat log". Can you help to check if the scan results are passed to
> > gaia? How long do you need to wait to find this bug after connect to wifi AP?
> 
Dear vincent,
Also I want know that how aControlMessage() works and how wifi commands are passed to HAL, Can you tell me about the implementation of this part? many thanks.

Comment 12

[Wang Rong]

(In reply to Cody Roesch [:croesch] from comment #9)
> I see that this reporters build is from over a month ago. (Mozilla Build ID:
> 20141019000201)
> Does the reporter still see this on a recent build?
> 
> -----------------------------------------------------------------------------
> -----
> -----------------------------------------------------------------------------
> -----
> 
> Flame Test Results:
> 
> This bug does NOT repro on Flame kk build: Flame 2.2 KK, Flame 2.1 KK, Flame
> 2.0 KK
> 
> Actual Result: Wifi networks are found and can be connected to within 5
> seconds after entering password and tapping OK. Tested a few different
> available networks. There are no long wait times when trying to connect or
> searching for Access Points. Checked in both FTU and Settings.
> 
> Repro Rate: 0/9
> 
> Environmental Variables:
> Device: Flame 2.2 KK
> BuildID: 20141125035634
> Gaia: 824a61cccec4c69be9a86ad5cb629a1f61fa142f
> Gecko: acde07cb4e4d
> Version: 36.0a1 (2.2) 
> Firmware Version: v188-1
> User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
> -----------------------------------------------------------------
> Environmental Variables:
> Device: Flame 2.1 KK
> BuildID: 20141124205132
> Gaia: 1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
> Gecko: db893274d9a6
> Version: 34.0 (2.1) 
> Firmware Version: v188-1
> User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
> -----------------------------------------------------------------
> Environmental Variables:
> Device: Flame 2.0 KK
> BuildID: 20141124161832
> Gaia: 99e4594c66aa3738d58b0cb44bd885a87a063b6e
> Gecko: f91abc6127d9
> Version: 32.0 (2.0) 
> Firmware Version: v188-1
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
> 
> -----------------------------------------------------------------
> -----------------------------------------------------------------
> 
> Also checked a Nightly build from 10/20/2014
> 
> No problems found when searching or connecting to a few different networks.
> Both FTU and Settings are working correctly.
>  
> Environmental Variables:
> Device: Flame 2.0 Nightly
> BuildID: 20141020000206
> Gaia: 9c7dec14e058efef81f2267b724dad0850fc07e4
> Gecko: c17df9fe087d
> Version: 32.0 (2.0) 
> Firmware Version: v188-1
> User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Dear,

Can you try to reproduce it follow steps like this,
1. connect to an ap,
2. close wifi.
3. open wifi, observe how long ap list will be shown. we find that sometimes it costs half one minutes.

If it still can't be reproduce, please try one ap which dhcp sometimes will fail for one or two times. I just find in logs that dhcp failure could be related to this problem.

Comment 13

[Cody Roesch [:croesch]]

I retested all by builds from yesterday and was not able to reproduce the bug on the Flame device with the steps in comment 12.

As far as "If it still can't be reproduce, please try one ap which dhcp sometimes will fail for one or two times." :

I tested a linksys router and did some router power on/power off tests as well as pulling the internet cable while device wifi was disabled then reenabling wifi always correctly searched the available networks. I tested this is different ways and still no problems.


If anyone else would like to try the dhcp fail case on flame please feel free.

Comment 14

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Seems like this issue might be Midori only. Removing the qawanted for now as the request in comment 7 has been completed.  Please add the tag again if you would like more information or testing.

Comment 15

[Wesly Huang (EPM)]

Hi Vincent:

Would you help on comment#10 and comment#11, also share you view about comment#12? (is it really related to dhcp fail?) Thank you.


Per current status and comment#14 tends to be device-specific so candidate for de-nom.

Comment 16

[Wesly Huang (EPM)]

Hi Kai-Zhen:

As discussed. Pls support to look into this one and put your comment/suggestion today here. Thank you very much!

Comment 17

[Kai-Zhen Li [:seinlin][:kli]]

(In reply to Wang Rong from comment #11)
>
> Also I want know that how aControlMessage() works and how wifi commands are
> passed to HAL, Can you tell me about the implementation of this part? many
> thanks.

In wifiworker,  aControlMessage is implemented as controlMessage.
http://dxr.mozilla.org/mozilla-central/source/dom/wifi/WifiWorker.js#206

controlMessage simply set a callback and send the command to wpa_supplicant.

Once a message is returned from wpa_supplicant related callback will be involved.
http://dxr.mozilla.org/mozilla-central/source/dom/wifi/WifiWorker.js#215

Comment 18

[Vincent Chang[:vchang][changyihsin]]

According to below two lines, 

11-20 03:26:48.435 => request dhcp  
11-20 03:27:18.665 => failed to obtain ip address

I think this problem might related to dhcp request command. The dhcp request is a blocking command running in the control thread(The wifi related commands like scan/associate...). It causes follow-up commands pending until command is complete. This is true in 2.0 and 2.1. But this problem is fixed in Bug 1038531 which handles blocking command in others thread.

Comment 19

[Wesly Huang (EPM)]

[Triage] de-nom, as device-specific per above discussion history.

Comment 20

[BMO Automation]

Firefox OS is not being worked on