Closed
Bug 1002314
Opened 11 years ago
Closed 10 years ago
[B2G]To have a webapi providing WIFI capabilities of device
Categories
(Firefox OS Graveyard :: Wifi, defect)
Tracking
(feature-b2g:2.0, tracking-b2g:backlog)
RESOLVED
FIXED
2.0 S2 (23may)
People
(Reporter: kchang, Assigned: chucklee)
References
Details
(Whiteboard: [p=5])
Attachments
(2 files, 4 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
This is a follow up bug for https://bugzilla.mozilla.org/show_bug.cgi?id=966925#c19. We need to add a webapi providing WIFI capabilities of device so that Gaia can show options of WIFI setting accurately.
Reporter | ||
Comment 1•11 years ago
|
||
Vincent, It seems that we need this in 2.0 because the options of wifi setting are different in various devices. If the target milestons does work for you, please change it.
Target Milestone: --- → 2.0 S2 (23may)
Reporter | ||
Comment 2•11 years ago
|
||
Chuck is going to handle this.
Assignee: vchang → chulee
blocking-b2g: --- → backlog
Reporter | ||
Updated•11 years ago
|
Blocks: b2g-WLAN-2.0
Assignee | ||
Comment 3•11 years ago
|
||
Add |DOMRequest WifiManager.getCapabilities()|, and returns an object containing wifi capabilities. The problem now is how much info we should return, Gaia is more likely to have a complete list so settings app can create UI in a general way, especially for WPA-EAP. Maybe like: { security: { OPEN: null, WEP: { password: { ASCII: { length: [ {min: 5, max: 5}, {min: 13, max: 13} ] }, HEX: { length: [ {min: 10, max: 10}, {min: 26, max: 26} ] } } }, WPA-PSK: { password: { ASCII: { length: [ {min: 8, max: 64} ] } } }, WPA-EAP: { SIM: {}, PEAP: { identity: {}, password: {}, phase2: [ "MSCHAPV2" ], certs: [ "SERVER" ] }, TTLS: { identity: {}, password: {}, phase2: [ "MSCHAPV2" ], certs: [ "SERVER" ] }, TLS: { identity: {}, certs: [ "SERVER", "USER", "PRIVATEKEY" ] } } } } But creating object with such detail seems almost like using XUL... Any suggestions?
Flags: needinfo?(vchang)
Flags: needinfo?(mrbkap)
Flags: needinfo?(arthur.chen)
Comment 4•11 years ago
|
||
I would suggest only pass the information that is device or platform dependent. For example, if the password length is fixed, we can simply hard code it in gaia side.
Flags: needinfo?(arthur.chen)
Comment 5•11 years ago
|
||
I agree with Arthur. A lot of the information in your sample object is findable on wikipedia. It should be enough to say that we support WPA-PSK and obviously that has a password. I'd expect this to be more a list of capabilities (with some nesting to break out which sorts of keys we support for WPA-EAP and friends).
Flags: needinfo?(mrbkap)
Comment 6•11 years ago
|
||
How about sometimes like this ? { security: { OPEN, WEP, WPA-PSK, WPA-EAP: { SIM, PEAP, TTLS, TLS } } }
Flags: needinfo?(vchang)
Assignee | ||
Comment 7•11 years ago
|
||
I think Phase 2 can be dynamic, too. { security: { OPEN: {}, WEP: {}, WPA-PSK: {}, WPA-EAP: { SIM: {}, PEAP: { phase2: ["MSCHAPV2"] }, TTLS: { phase2: ["MSCHAPV2"] }, TLS: {} } } }
Assignee | ||
Comment 8•11 years ago
|
||
(In reply to Chuck Lee [:chucklee] from comment #7) > I think Phase 2 can be dynamic, too. > > { > security: { > OPEN: {}, > WEP: {}, > WPA-PSK: {}, > WPA-EAP: { > SIM: {}, > PEAP: { > phase2: ["MSCHAPV2"] > }, > TTLS: { > phase2: ["MSCHAPV2"] > }, > TLS: {} > } > } > } If Gaia have a knowledge about UI should react with respect to the security method selected, maybe it can be simplified to the following structure: Full capabilities: { security: ["OPEN", "WEP", "WPA-PSK", "WPA-EAP"], eapMethods: ["SIM", "PEAP", "TTLS", "TLS"], eapPhase2: ["MSCHAPV2", "GTC"], certificates: ["SERVER", "USER", "PRIVATEKEY"] } And capabilities for Wifi in 2.0 { security: ["OPEN", "WEP", "WPA-PSK", "WPA-EAP"], eapMethods: ["SIM", "PEAP", "TTLS"], eapPhase2: ["MSCHAPV2"], certificates: ["SERVER"] }
Flags: needinfo?(mrbkap)
Flags: needinfo?(arthur.chen)
Assignee | ||
Comment 10•11 years ago
|
||
Attachment #8419969 -
Flags: feedback?(mrbkap)
Attachment #8419969 -
Flags: feedback?(ehsan)
Assignee | ||
Comment 11•11 years ago
|
||
Attachment #8419970 -
Flags: feedback?(vchang)
Attachment #8419970 -
Flags: feedback?(mrbkap)
Updated•11 years ago
|
Attachment #8419969 -
Flags: feedback?(ehsan) → feedback+
Comment 12•11 years ago
|
||
Comment on attachment 8419970 [details] [diff] [review] WIP - 0002. Provide capability info. Review of attachment 8419970 [details] [diff] [review]: ----------------------------------------------------------------- Looks good.
Attachment #8419970 -
Flags: feedback?(vchang) → feedback+
Updated•11 years ago
|
Attachment #8419969 -
Flags: feedback?(mrbkap) → feedback+
Updated•11 years ago
|
Attachment #8419970 -
Flags: feedback?(mrbkap) → feedback+
Assignee | ||
Comment 14•11 years ago
|
||
Attachment #8419969 -
Attachment is obsolete: true
Attachment #8422167 -
Flags: review?(mrbkap)
Attachment #8422167 -
Flags: review?(ehsan)
Assignee | ||
Comment 15•11 years ago
|
||
Attachment #8419970 -
Attachment is obsolete: true
Attachment #8422168 -
Flags: review?(vchang)
Attachment #8422168 -
Flags: review?(mrbkap)
Comment 16•11 years ago
|
||
Comment on attachment 8422167 [details] [diff] [review] 0001. WebIDL Change. Review of attachment 8422167 [details] [diff] [review]: ----------------------------------------------------------------- Thanks, Chuck! Looks good.
Attachment #8422167 -
Flags: review?(ehsan) → review+
Assignee | ||
Updated•11 years ago
|
Whiteboard: [p=5]
Comment 17•11 years ago
|
||
Comment on attachment 8422168 [details] [diff] [review] 0002. Provide capability info. Review of attachment 8422168 [details] [diff] [review]: ----------------------------------------------------------------- Looks good.
Attachment #8422168 -
Flags: review?(vchang) → review+
Updated•11 years ago
|
feature-b2g: --- → 2.0
Updated•11 years ago
|
Attachment #8422167 -
Flags: review?(mrbkap) → review+
Updated•11 years ago
|
Attachment #8422168 -
Flags: review?(mrbkap) → review+
Assignee | ||
Comment 18•10 years ago
|
||
Add reviewers in comment and rebase.
Attachment #8422167 -
Attachment is obsolete: true
Assignee | ||
Comment 19•10 years ago
|
||
Add reviewers in comment and rebase.
Attachment #8422168 -
Attachment is obsolete: true
Comment 22•10 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/a8eb0e4fba47 Should we have tests for this? :) https://hg.mozilla.org/integration/b2g-inbound/rev/04193066a20c
Flags: in-testsuite?
Keywords: checkin-needed
Comment 23•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a8eb0e4fba47 https://hg.mozilla.org/mozilla-central/rev/04193066a20c
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 24•10 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #22) > https://hg.mozilla.org/integration/b2g-inbound/rev/a8eb0e4fba47 > > Should we have tests for this? :) > https://hg.mozilla.org/integration/b2g-inbound/rev/04193066a20c Maybe we can add test in gaia-unit-test along with change in Settings app, I'll discuss with Gaia.
Updated•10 years ago
|
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•