Closed Bug 996588 Opened 10 years ago Closed 10 years ago

Unable to connect to wifi network with double quotes (") in ssid

Categories

(Firefox OS Graveyard :: Wifi, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:1.4+, firefox30 wontfix, firefox31 wontfix, firefox32 fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S1 (9may)
blocking-b2g 1.4+
Tracking Status
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: vasanth, Assigned: vchang)

Details

(Keywords: regression, Whiteboard: [caf priority: p2][CR 647223])

Attachments

(3 files)

STR
1. Configure SSID in AP with some name which has double quotes (")
e.g. mynetwork"
2. In device, after search this wifi network shows up as mynetwork\" (backward slash is inserted before double quotes)
3. Trying to connect to that network doesn't work and no change in UI

Issue seen only in V1.4 and not in V1.3
Haven't checked with the fix for bug 989135. 
Will that hotspot ssid fix, fixes this wifi network ssid issue as well?
bug 989135 hasn't been uplifted to 1.4 yet, so that's why you are still seeing this bug.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
blocking-b2g: 1.4? → ---
Fix of bug 989135 doesn't fix this issue. Reopening.
Status: RESOLVED → REOPENED
blocking-b2g: --- → 1.4?
Resolution: DUPLICATE → ---
I manually pulled in bug 989135 fix to V1.4 and verified that bug 989135 is fixed but still this bug is reproducible
Can we confirm this isn't reproducing on 1.3?
blocking-b2g: 1.4? → 1.4+
Keywords: qawanted, regression
(In reply to Jason Smith [:jsmith] from comment #4)
> Can we confirm this isn't reproducing on 1.3?

Per the description the issue is not seen in 1.3 and only on 1.4. So this is a regression.

Removing QAwanted on the same.
Keywords: qawanted
Hi Vincent, can you assign this? thanks
Flags: needinfo?(vchang)
Attached image ssidWithQuote.jpg
I can't reproduce the problem using Unagi in 
Gaia v1.4 commit: cf590ecb161e7b9fb4ccc672f950072acad62caa 
Mozilla Central Aurora changeset:  180636:d7c07694f339
Just realize that v1.4 has branched to mozilla-b2g30_v1_4. But I think it should not have much difference because it's just branched.
Flags: needinfo?(vchang)
I just checked on our internal V1.4 tip. Issue is still reproducible.
Internal tip is almost close and I don't see any wifi related changes between internal/mozilla v1.4 tip

Gaia: d23e479e8a4ce0bc620acb2d7e2f82801aa4d0ea
Gecko: 1d45d07b59c6bb9262e8f47db9d491d9a9f8b21b
Gecko/Gaia version seems similar. 

I think the problem may related to how wpa_supplicant handles scan result. Please Refer to bug 962455 comment 8. 

You can help to use below commands to see the scan result from wpa_supplicant. 

1. adb shell wpa_cli scan
2. adb shell wpa_cli scan_result

Below is the scan result from Unagi. 
bssid / frequency / signal level / flags / ssid
98:0c:82:4c:98:ef	2437	-43	[WPA2-PSK-CCMP][ESS]	my`net'work"
Flags: needinfo?(vasanth)
Vincent is working on this.
Assignee: nobody → vchang
(In reply to Vincent Chang[:vchang] from comment #9)
> You can help to use below commands to see the scan result from
> wpa_supplicant. 

Got below output from wpa_cli
bssid / frequency / signal level / flags / ssid
1c:b0:94:d6:21:5f	2462	-56	[ESS]	mynetwork\"

I see command output has "\" inserted so I checked the same commands on equivalent android kk device.
Even there I see same cmd output, But android UI shows network name without "\" and also able to connect to the network.
Flags: needinfo?(vasanth)
After Jelly Bean 4.3, the special characters in SSIDs are converted to printable form, for instance, 

   " => \" 
   \ => \\ 
   0x67 => \x67  

This patch converts these special characters to original bytes.
Attachment #8415042 - Flags: review?(fabrice)
BTW, I have verified the patch in Nexus 5.
This shouldn't be set as a regression. It's different behaviors between wpa_supplicant versions.
Target Milestone: --- → 2.0 S1 (9may)
(In reply to Vincent Chang[:vchang] from comment #14)
> This shouldn't be set as a regression. It's different behaviors between
> wpa_supplicant versions.

Technically it would be a regression if the end user behavior was fine in 1.3, but not working in 1.4.
Keywords: regression
Attachment #8415042 - Flags: review?(fabrice) → review+
Thanks for your stamp, Fabrice. 

Commit to b2g-inbound. 
https://hg.mozilla.org/integration/b2g-inbound/rev/76eede9ccce5
https://hg.mozilla.org/mozilla-central/rev/76eede9ccce5
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Whiteboard: [CR 647223] → [caf priority: p2][CR 647223]
A valid test case to cover this issue is already written: https://moztrap.mozilla.org/manage/case/8752/
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(dharris)
Already covered in moztrap:

https://moztrap.mozilla.org/manage/case/8752/
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(dharris)
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.