962455 - [Open C][flatfish][Settings][Wifi] AP name is different on tablet

Status: RESOLVED DUPLICATE of bug 1065208

(Firefox OS Graveyard :: Vendcom, defect)

Description

[EJ Chen [:eragonj][:小龍哥][Contributor mode on](inactive)]

Attachment: IMG_2480.jpg

When we change AP name from English to Traditional Chinese, it shows differently on tablet compared with mobile. 

* Build number

Gaia      7443da6780336eac68d4228834372e16393d10d8
Gecko     87d8977bd08d0afbb5b54cdf5269b6bd90f7400e
BuildID   20140109064521
Version   29.0a1

* Prerequisite

Turn on an AP and name it in Traditional Chinese. (測試 means test in Traditional Chinese for example.)

* Steps to reproduce

1. open settings app
2. click on Wi-Fi to open its panel
3. check the AP name

* Expected Result

AP name should be in Traditional Chinese

* Actual Result

AP name is not in Traditional Chinese

* Occurrence rate
100%

Comment 1

[Evelyn Hung]

I got the same problem on OPEN C_1.3

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to Evelyn Hung [:evelyn] from comment #1)
> I got the same problem on OPEN C_1.3

1.3?

Looks like a PVOB issue since this only show up on some devices. Ken, could you confirm?

Comment 3

[Ken Chang[:kenkai]]

It is because of different string set. But we need to discuss with partner to figure out the better solution.

Comment 4

[Preeti Raghunath(:Preeti)]

Axel,

Please help figure out if this is an l10n issue or a vendor string issue

Comment 5

[Axel Hecht [:Pike]]

That's not an l10n issue. It could either be a misinterpretation of charsets on the fx os side, or the router actually exposing its name differently on 2.4 vs 5 ghz.

Comment 6

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

We're not releasing for Taiwan, so we're pushing to 1.4?  We are still concerned that this may affect the languages we are distributing to.  

By the description of things this looks like a font issue where the font doesn't include traditional Chinese.

Comment 7

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

Can you browse web pages with Traditional Chinese correctly?
If you can, I think font is not the problem.

I suspect that wpa_supplicant of flatfish might transform non-ascii chars into hex string automatically, Please provide the scan result of wpa_supplicant by following steps:
1. adb shell wpa_cli scan
2. adb shell wpa_cli scan_result

Comment 8

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

I have tested flatfish, and confirmed that the AP name is transformed from raw byte into hex string by wpa_supplicant.

For example, an AP with SSID "澈世" (UTF8 encoded as [0xe6 0xbe 0x88 0xe4 0xb8 0x96]).
On Unagi, wpa_supplicant reports SSID as byte array [0xe6 0xbe 0x88 0xe4 0xb8 0x96] so it can be decoded into unicode code point [0x6F88 0x4E16], then transform into string "澈世".
On flatfish, wpa_supplicant reports SSID as string "\xe6\xbe\x88\xe4\xb8\x96", it can't be decoded anymore.

We can't apply utf8 decoding on hex string like "\xNN" or "0xNN" or something like that. Not mentioning we have to add code for handling these non-standard condition. Also if someone really use SSID in such form, the check/decode process will cause connection error.

I think this bug should to be fix by partner by removing the byte-to-hex-string-transform.

Comment 10

[Jason Smith [:jsmith]]

Which partner would need to address this? Would I need to outreach to QC about this or should I reach out to each device partner (e.g. TCL, ZTE)?

In other words, who controls the wpa_supplicant? QC or the device partner?

Comment 11

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

It could be controlled by vendor or device partner, I think we can reach device partner first.

Comment 12

[Jason Smith [:jsmith]]

(In reply to Chuck Lee [:chucklee] from comment #11)
> It could be controlled by vendor or device partner, I think we can reach
> device partner first.

Okay - a followup question. Why would this be a vendor problem if this works fine on 1.1? The issue also appears to device independent, which is leading me to question if this is a vendor bug.

Comment 13

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #12)
> (In reply to Chuck Lee [:chucklee] from comment #11)
> > It could be controlled by vendor or device partner, I think we can reach
> > device partner first.
> 
> Okay - a followup question. Why would this be a vendor problem if this works
> fine on 1.1? The issue also appears to device independent, which is leading
> me to question if this is a vendor bug.

Saw the answer in the other bug.

Comment 14

[Jason Smith [:jsmith]]

Vance - Can you notify all the TAMs to talk to each device partner about this problem? Apparently, we're currently seeing this problem on Sora, Open C, an Flatfish.

Comment 15

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

ni Wayne and Steven, hi guys, could you inform your account about this problem? thanks! Vance

Comment 16

[Keying Fang]

We had the same issue. Can you tell us the solution about the issue.

scan_result
bssid / frequency / signal level / flags / ssid
8c:21:0a:a6:85:96       2432    -50     [WPS][WEP][ESS] TP-LINK_A68596
00:d0:d0:73:c6:2a       2437    -54     [WPA2-PSK-CCMP][WPS][ESS]       \xe4\xb8\xad\xe5\x9b\xbd\xe7\xa7\xbb\xe5\x8a\xa8

the list table is display \xe4\xb8\xad...

Where could we transform hex-string-transform to unicode.

Comment 17

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

I think you shouldn't transform unicode to hex string in wpa_supplicant at first place, see cooment 8 and bug 973485 comment 15.