1046116 - Device is not connecting automatically to wifi whenever device coming back to wifi area

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Wifi, defect)

Description

[vasanth]

Attachment: wifi-autoreconnect-fail.png

[Blocking Requested - why for this release]:

Device: Flame

Steps to reproduce:
-------------------
1. Enable Wifi, connect to a wifi network
2. Move out of Wifi area, enable Cellular data. Device is connected to cellular data (HSPA)
3. Bring device back to wifi area.
4. Device should disconnect the cellular data and connect to wifi
5. Device is not connecting to wifi until user explicitly click on the wifi network listed in the "Available networks"

Attached the screen shot when the device is in wifi area and listing all the available wifi networks, but not connecting automatically to "Hydra" for which the device is configured to connect. After clicking on "Hydra", it is connecting to that.

Comment 1

[Jason Smith [:jsmith]]

QA Wanted to see if we can reproduce on Flame.

Comment 2

[Inder]

Vasanth -- does it reproduce on 8x10/8x26 QRDs with KK build? If not then this should not block the CC metabug.

Comment 3

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

I was able to reproduce this issue on the latest 2.0 Flame build.  The device did not reconnect automatically and required selecting the network manually to succeed.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140730080807
Gaia: e8425788e0372fbbcc40387b799f0636c041fc14
Gecko: 20c472fc0ee3
Version: 32.0 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 4

[vasanth]

(In reply to Inder from comment #2)
> Vasanth -- does it reproduce on 8x10/8x26 QRDs with KK build?
Yes. Able to reproduce in 8x10 QRD with FFOS 2.0 + KK build
Device did not reconnect automatically.

Comment 5

[bhavana bajaj [:bajaj]]

Ken,

Can you please help with an assignee here to investigate this urgently ? Thanks!

Comment 6

[Ken Chang[:kenkai]]

Hi Vincent, can you please check this bug?

Comment 7

[Henry Chang [:hchang]]

Attachment: log_flame.txt

Attach the log at the time I reproduced. The network was disabled by gecko for some reason.

.....
I/Gecko   (  291): -------------- WifiCommand: Sending command: DISABLE_NETWORK 0 @ wlan0
D/wpa_supplicant(  974): RX ctrl_iface - hexdump(len=17): 44 49 53 41 42 4c 45 5f 4e 45 54 57 4f 52 4b 20 30
D/wpa_supplicant(  974): wlan0: Control interface command 'DISABLE_NETWORK 0'
D/wpa_supplicant(  974): CTRL_IFACE: DISABLE_NETWORK id=0
.....

Comment 8

[Henry Chang [:hchang]]

The network was disabled from [1], which was first introduced at [2].

[1] http://hg.mozilla.org/mozilla-central/file/104254bd1fc8/dom/wifi/WifiWorker.js#l818
[2] http://hg.mozilla.org/mozilla-central/diff/c25c93664add/dom/wifi/WifiWorker.js#l1.44

Comment 9

[Henry Chang [:hchang]]

Attachment: log_flame.txt (more detailed)

Comment 10

[Vincent Chang[:vchang][changyihsin]]

Henry is working on this.

Comment 11

[Henry Chang [:hchang]]

Current code treats CTRL-EVENT-ASSOC-REJECT as a WEP authentication 
failure as discussed on Bug 786438. It's definitely a false alarm on 
flame (at least).

CTRL-EVENT-ASSOC-REJECT is originated from driver whenever 
(re)association attempt has been rejected by the AP [1].
I think it's a too generic event due to a couple of sources 
of error such as weak signal strength in this issue.

However, I don't see CTRL-EVENT-ASSOC-REJECT event on flame/hamachi
on WEP failure... 


[1] http://androidxref.com/4.3_r2.1/xref/external/wpa_supplicant_8/src/drivers/driver.h#2832

Comment 12

[Henry Chang [:hchang]]

Vasanth: 

Could you attach the log to let me confirm if what we observed
was the same cause? Thanks!

Comment 13

[vasanth]

Attachment: wifi-autoreconnect-fail-QRD8x10.txt

Collected logs for below STR
----------------------------
1. Enabled data connection
2. Connected to open network "vasanth"
3. Moved away, wifi is disconnected and data connection is enabled.
4. Moved back closer, device failed to switch to wifi

Comment 14

[vasanth]

(In reply to Henry Chang [:henry] from comment #11)
> However, I don't see CTRL-EVENT-ASSOC-REJECT event on flame/hamachi
> on WEP failure... 

AFAIK, flame is using jb based gonk with 2.0 whereas our 8x10 QRDs uses kk based gonk with 2.0
That may be the reason you see a difference in behaviour?

Comment 15

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

Maybe the behavior is changed afterward, if we now focus on flame only, that part might can be removed.
But there's another concern on handling this event: force connection-error-network to be disabled and let other networks get the chance to try. For now, I think we don't have other mechanism/state to indicate connection error other than "password error".
If you plan to remove the CTRL-EVENT-ASSOC-REJECT detection, I think we have to make sure it won't get stock on the poor signal network while there's another better known network to connect. Although wpa_supplicant of flame have a "TEMP-DISABLE" state to do the job, I am not sure if other devices have it, and if we have to take of all of them in central code.

Comment 16

[Jason Smith [:jsmith]]

QA Wanted for branch checks

Comment 17

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

This issue does occur on 2.1 Flame, 1.4 Flame, and 2.0 Buri.  Wifi does not reconnect automatically when moving back into range.

Environmental Variables:
Device: Flame Master
BuildID: 20140804131526
Gaia: 19bf9795263e2ccc15d824a52ebf23c2670fa9b9
Gecko: 7f81be7db528
Version: 34.0a1 (Master) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 1.4
BuildID: 20140804095929
Gaia: 9377274b17200a60cebcd2427d489a7756c4cc72
Gecko: 60d3725443a5
Version: 30.0 (1.4) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Environmental Variables:
Device: Buri 2.0
BuildID: 20140804140229
Gaia: ff058316218cb84520b3de71f24403de74f1ba9f
Gecko: 183947e58a9c
Version: 32.0 (2.0) 
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Comment 18

[Henry Chang [:hchang]]

(In reply to Chuck Lee [:chucklee] from comment #15)
> Maybe the behavior is changed afterward, if we now focus on flame only, that
> part might can be removed.
> But there's another concern on handling this event: force
> connection-error-network to be disabled and let other networks get the
> chance to try. For now, I think we don't have other mechanism/state to
> indicate connection error other than "password error".
> If you plan to remove the CTRL-EVENT-ASSOC-REJECT detection, I think we have
> to make sure it won't get stock on the poor signal network while there's
> another better known network to connect. Although wpa_supplicant of flame
> have a "TEMP-DISABLE" state to do the job, I am not sure if other devices
> have it, and if we have to take of all of them in central code.

"Temp disable" was introduced at [1] for authentication failure
but not for general failure. Besides, I am not sure if the device 
would get stuck in a poor signal network. So, I prefer don't disable
a network when receiving 'CTRL-EVENT-ASSOC-REJECT' until we
have a sophisticated method to re-enable it.

[1] http://w1.fi/cgit/hostap/commit/?id=00e5e3d5099eac9e75e23056dbbb9add73f63b0a

Comment 19

[Henry Chang [:hchang]]

Attachment: Bug1046116.patch

Comment 20

[Henry Chang [:hchang]]

Thanks :vchang for review!

Comment 21

[Vincent Chang[:vchang][changyihsin]]

https://hg.mozilla.org/integration/b2g-inbound/rev/9935df97a455

Comment 22

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/9935df97a455

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/a62923d004d8

You'll need to nominate this for b2g30 approval if you want to get it landed on v1.4 as well.

Comment 24

[Henry Chang [:hchang]]

Attachment: Bug1046116.patch for v1.4

Comment 25

[Henry Chang [:hchang]]

Comment on attachment 8468997 [details] [diff] [review]
Bug1046116.patch for v1.4

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Wifi
User impact if declined: User may not be able to automatically connect to the remembered network when he comes back.
Testing completed: Yes.
Risk to taking this patch (and alternatives if risky): No
String or UUID changes made by this patch: No

Comment 26

[Yeojin Chung [:YeojinC]]

New test case needs to be added. There is no existing test case.

Comment 27

[KTucker [:KTucker][Inactive 3/4/2016]]

Test case added in Moztrap:

https://moztrap.mozilla.org/manage/case/14332/

Comment 28

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/6510df0cce6b