1065208 - Can't find any available network anymore if it connects to one AP which SSID name includes non-ascii character

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Wifi, defect)

Description

[Hubert Lu[:hlu] <[e-mail]>]

Attachment: logcat

Description:
    Can't find any available network anymore if it connects to one AP which SSID name includes Chinese character

Repro Steps:
    1. Enable WiFi and try to connect one WiFi AP which SSID name only includes English character.
    2. Use another commercial phone, iPhone 5, to setup one WiFi hotspot which SSID name includes one Chinese character. (Ex: Hubert 的 iPhone)
    3. DUT try to connect the SSID configured on step2.

Actual:
    Status of original connected WiFi and trying to connect WiFi become "offline", and it always shows "searching" in available networks of WiFi page after rebooting.

Expected:
    DUT should connect to any WiFi AP properly, and it shows all of available networks.

Environment:
    Device: Woodduck (Flame also has this issue)
    Gaia      59a670d40ad7f5966ec7fafcab0f05009bea97ab
    Gecko     e9c3f1d931e6540d0d9786ab7dee69a7c75de6b4
    BuildID   20140909123833
    Version   32.0
    ro.build.version.incremental=1409557062
    ro.build.date=Mon Sep  1 15:37:57 CST 2014

Comment 1

[Josh Cheng [:josh]]

Triage:
Hi Shawn, please help to check.

Comment 3

[Josh Cheng [:josh]]

qawanted, branch check for 2.1, 2.2. Thanks!

Comment 4

[Pi Wei Cheng [:piwei] (inactive)]

Issue is reproducible on Flame 2.2 and Flame 2.1.

Observed behavior: Inability to connect to a wifi hotspot that contains Chinese characters, and subsequently destroys the device's ability to search for available wifi hotspots/AP's permanently (rebooting the device doesn't solve the issue - DUT will continue to try to connect to the Chinese AP after reboot; the only way to make it stop connecting is to make the Chinese AP offline, then DUT will automatically connect to the previously connected AP, and even so its ability to search for Wifi hotspots is still broken).

Device: Flame (shallow flash)
BuildID: 20141008065408
Gaia: 2665e714beea5dc433862ca6bb8d2b47ffe2f2d1
Gecko: 4bad24a306b2
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Device: Flame (shallow flash)
BuildID: 20141008092809
Gaia: 55ce3612bd8a8665139d6b85114ce59993a3fa0a
Gecko: b0dce6c46c52
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Comment 5

[shawn ku [:sku]]

Hi Seinlin:
 Please help check if this is a gecko issue or supplicant bug?
Thanks!!
Shawn

Comment 6

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

Shawn, from logcat, I think it could be something wrong in b2g. While device wifi setting keep searching and do not update wifi status, I can see there is a STA connected successfully on AP. I will continue to study this issue and update to bug later.

--
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-ADDED 54 3c:94:d5:7b:40:84
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-ADDED 55 3c:94:d5:7b:b8:04
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-ADDED 56 4c:e6:76:a3:07:ea
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-ADDED 57 10:bd:18:f0:22:c0
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-ADDED 58 10:bd:18:f0:22:c1
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-ADDED 59 10:bd:18:f0:22:c2
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-BSS-ADDED 60 00:c0:ca:1e:cc:c6
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-SCAN-RESULTS 
I/Gecko   (  211): -*- WifiWorker component: Notifying of scan results available
I/Gecko   (  211): -*- WifiWorker component: Scan results available, but we don't need them
I/Gecko   (  211): -*- WifiWorker component: Event coming in: WPS-AP-AVAILABLE 
I/Gecko   (  211): -*- WifiWorker component: Event coming in: Trying to associate with SSID 'Test的i5'
I/Gecko   (  211): -*- WifiWorker component: Matched: Test的i5
I/Gecko   (  211): 
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=0 state=5 BSSID=00:00:00:00:00:00 SSID=Test的i5
I/Gecko   (  211): -*- WifiWorker component: State change: SCANNING -> ASSOCIATING
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=0 state=6 BSSID=00:00:00:00:00:00 SSID=Test的i5
I/Gecko   (  211): -*- WifiWorker component: State change: ASSOCIATING -> ASSOCIATED
I/Gecko   (  211): -*- WifiWorker component: Event coming in: Associated with e6:25:e7:d7:b0:3a
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=0 state=7 BSSID=e6:25:e7:d7:b0:3a SSID=Test的i5
I/Gecko   (  211): -*- WifiWorker component: State change: ASSOCIATED -> FOUR_WAY_HANDSHAKE
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=0 state=8 BSSID=e6:25:e7:d7:b0:3a SSID=Test的i5
I/Gecko   (  211): -*- WifiWorker component: State change: FOUR_WAY_HANDSHAKE -> GROUP_HANDSHAKE
I/Gecko   (  211): -*- WifiWorker component: Event coming in: WPA: Key negotiation completed with e6:25:e7:d7:b0:3a [PTK=CCMP GTK=CCMP]
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-CONNECTED - Connection to e6:25:e7:d7:b0:3a completed (auth) [id=0 id_str=]
I/Gecko   (  211): -*- WifiWorker component: Event coming in: CTRL-EVENT-STATE-CHANGE id=0 state=9 BSSID=e6:25:e7:d7:b0:3a SSID=Test的i5
I/Gecko   (  211): -*- WifiWorker component: State change: GROUP_HANDSHAKE -> COMPLETED
E/GeckoConsole(  211): [JavaScript Error: "uncaught exception: Invalid argument, not a quoted string: 54657374e79a846935"]

Comment 7

[Francis Lee [:frlee]]

per triage result, seline, please take this bug. this is generic issue and important enough.

Comment 8

[Wayne Chang [:wchang]]

Not sure if bug 835719 helps, but FYR.

Comment 9

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

(In reply to Francis Lee [:frlee] from comment #7)
> per triage result, seline, please take this bug. this is generic issue and
> important enough.

OK, I'll take it.

-seinlin

Comment 10

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

Attachment: bug-1065208-wip.diff

Vincent, could you have a look to this patch? I try on flame, it can solve the issue. You can also see detail in patch's comment. Thanks!

Comment 11

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 8506733 [details] [diff] [review]
bug-1065208-wip.diff

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

::: dom/wifi/WifiWorker.js
@@ +1168,5 @@
> +          // But if ssid contains hex value, it will be converted into hex string.
> +          // When a un-quoted hex ssid is received from GET_NETWORK,
> +          // it is necessary to encode and quote it.
> +          if ( fieldName == "ssid" && value[0] != '"' ) {
> +            config[fieldName] = quote(decodeURIComponent(value.replace(/[0-9a-f]{2}/g, '%$&')));

Can you explain this line a little bit more in the comment? I think we need this conversion after kitkat. Others android version may not have this problem.

@@ +1170,5 @@
> +          // it is necessary to encode and quote it.
> +          if ( fieldName == "ssid" && value[0] != '"' ) {
> +            config[fieldName] = quote(decodeURIComponent(value.replace(/[0-9a-f]{2}/g, '%$&')));
> +          } else {
> +             config[fieldName] = value;

Nit: two spaces.

Comment 12

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

(In reply to Vincent Chang[:vchang] from comment #11)
> Comment on attachment 8506733 [details] [diff] [review]
> bug-1065208-wip.diff
> 
> Review of attachment 8506733 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/wifi/WifiWorker.js
> @@ +1168,5 @@
> > +          // But if ssid contains hex value, it will be converted into hex string.
> > +          // When a un-quoted hex ssid is received from GET_NETWORK,
> > +          // it is necessary to encode and quote it.
> > +          if ( fieldName == "ssid" && value[0] != '"' ) {
> > +            config[fieldName] = quote(decodeURIComponent(value.replace(/[0-9a-f]{2}/g, '%$&')));
> 
> Can you explain this line a little bit more in the comment? I think we need
> this conversion after kitkat. Others android version may not have this
> problem.
> 

As comment in patch, when a ssid with non-ascii char is set, it will be converted to hex string and updated into wpa_supplicant.conf. When get network, wpa_supplicant will reply hex string as ssid.

For example:
    SET_NETWORK 1 ssid "Test的i5"
    --> wpa_supplicant write ssid=54657374e79a846935 into wpa_supplicant.conf

    GET_NETWORK 1 ssid, 
    --> wpa_supplicant will reply 54657374e79a846935

Comment 13

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

Attachment: bug-1065208-fix.patch

Vincent, Could you review this patch? Thanks!

Comment 14

[Vincent Chang[:vchang][changyihsin]]

Comment on attachment 8510162 [details] [diff] [review]
bug-1065208-fix.patch

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

Thanks for your patch, looks good. 
Can you help to double check if this work for Flame JB version, too?

Comment 15

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

Attachment: bug-1065208-fix_2.0.patch

Comment 16

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

(In reply to Vincent Chang[:vchang] from comment #14)
> Comment on attachment 8510162 [details] [diff] [review]
> bug-1065208-fix.patch
> 
> Review of attachment 8510162 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Thanks for your patch, looks good. 
> Can you help to double check if this work for Flame JB version, too?

I verified on Flame JB and tarako ICS, this patch work properly too.

Comment 17

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

Try result: https://tbpl.mozilla.org/?tree=Try&rev=351bd986d203

Comment 18

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

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

Comment 19

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 20

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

Comment on attachment 8511814 [details] [diff] [review]
bug-1065208-fix_2.0.patch

NOTE: 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 #): JB/KK platform

User impact if declined: WifiWorker get Javascript error if user try to connect an AP with SSID include non-ASCII character. User can't use wifi anymore until reboot.

Testing completed: Verified on devices with ICS/JB/KK platform.

Risk to taking this patch (and alternatives if risky): low, Because it only check/encode the SSID read from HAL to avoid Javascript error.

String or UUID changes made by this patch: none

Comment 21

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

Hi Bhavana, This is 100% reproduced on flame. Could you have a look to the approval request? Thanks!

Comment 22

[bhavana bajaj [:bajaj]]

Comment on attachment 8511814 [details] [diff] [review]
bug-1065208-fix_2.0.patch

Approving on 2.1 but given where we are in 2.0 and I am not sure on exactly what the deal is on shipping in Chinese markets, I'll let wayne help comment here. If there are not launches there, I'd rather not uplift this at this point.

Comment 23

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

Update summary. As this issue is not only reproduced with Chinese character but all non-ascii character.

Comment 24

[Wayne Chang [:wchang]]

Doyun,

Can you assess if this would be needed for your project, which will likely see more CJK characters? There is a 2.0 patch available here if you'd like to take this in your project.

Bhvana,

I don't think we need to land this into 2.0 given the launches known. It will probably impact Doyun's project here but since we have 2.0 patch available, they can pick it over into their project.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/876f916b9168

Comment 26

[bhavana bajaj [:bajaj]]

(In reply to Wayne Chang [:wchang] from comment #24)
> Doyun,
> 
> Can you assess if this would be needed for your project, which will likely
> see more CJK characters? There is a 2.0 patch available here if you'd like
> to take this in your project.
> 
> Bhvana,
> 
> I don't think we need to land this into 2.0 given the launches known. It
> will probably impact Doyun's project here but since we have 2.0 patch
> available, they can pick it over into their project.

Thanks, waiting for Doyun's input here.

Comment 27

[Doyun Kim]

our WPA Supplicant is handling various characters.
So, we will not take this on our project.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

Setting 2.0 to wontfix. Not sure if the blocking flag should be set to 2.0M+ or not.

Comment 29

[bhavana bajaj [:bajaj]]

Kai-zhen, not sure of you need this on 2.0M so switching the blocking flag for you here.

Comment 30

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

Yes, we need this for 2.0m.

Comment 31

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

http://hg.mozilla.org/releases/mozilla-b2g32_v2_0m/rev/93da912120d8

Comment 32

[Coler]

This issue has been verified successfully on Woodduck 2.0;Flame2.1&2.2.
Reproducing rate: 0/5
See attachment: Verify_Woodduck_WIFI.mp4

Woodduck build version:
Gaia-Rev        d742e375aca6dc1bf3a36638000ad7f5338ef457
Gecko-Rev       d049d4ef127844121c9cf14d2e8ca91fd9045fcb
Build-ID        20141126050313
Version         32.0

Flame2.1 build version:
Gaia-Rev        1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6
Build-ID        20141125001201
Version         34.0

Flame2.2 build version:
Gaia-Rev        824a61cccec4c69be9a86ad5cb629a1f61fa142f
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/acde07cb4e4d
Build-ID        20141125040209
Version         36.0a1

Comment 33

[Coler]

Attachment: Verify_Woodduck_WIFI.MP4