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)
Tracking
(blocking-b2g:1.4+, 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?
Comment 1•10 years ago
|
||
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
Updated•10 years ago
|
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
Comment 4•10 years ago
|
||
Can we confirm this isn't reproducing on 1.3?
blocking-b2g: 1.4? → 1.4+
Keywords: qawanted,
regression
Comment 5•10 years ago
|
||
(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
Updated•10 years ago
|
Keywords: regressionwindow-wanted
Assignee | ||
Comment 7•10 years ago
|
||
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
Assignee | ||
Comment 9•10 years ago
|
||
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"
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(vasanth)
Reporter | ||
Comment 11•10 years ago
|
||
(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)
Assignee | ||
Comment 12•10 years ago
|
||
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)
Assignee | ||
Comment 13•10 years ago
|
||
BTW, I have verified the patch in Nexus 5.
Assignee | ||
Comment 14•10 years ago
|
||
This shouldn't be set as a regression. It's different behaviors between wpa_supplicant versions.
Keywords: regression,
regressionwindow-wanted
Target Milestone: --- → 2.0 S1 (9may)
Comment 15•10 years ago
|
||
(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
Updated•10 years ago
|
Attachment #8415042 -
Flags: review?(fabrice) → review+
Assignee | ||
Comment 16•10 years ago
|
||
Thanks for your stamp, Fabrice. Commit to b2g-inbound. https://hg.mozilla.org/integration/b2g-inbound/rev/76eede9ccce5
Comment 17•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/76eede9ccce5
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Comment 18•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/d82e815de368
status-b2g-v1.4:
--- → fixed
status-b2g-v2.0:
--- → fixed
status-firefox30:
--- → wontfix
status-firefox31:
--- → wontfix
status-firefox32:
--- → fixed
Updated•10 years ago
|
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)
Comment 20•10 years ago
|
||
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.
Description
•