Closed Bug 944263 Opened 11 years ago Closed 7 years ago

[Fugu][B2G] REQUEST_QUERY_FACILITY_LOCK returns 'GenericFailure' when cardState is 'pinRequired'

Categories

(Firefox OS Graveyard :: Vendcom, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: edgar, Assigned: styang)

References

Details

(Whiteboard: POVB, dsdsrun1.3-2)

Attachments

(4 files)

* Reproduce Steps: 1. Insert a sim card in fugu with pin lock enabled. 2. Do not unlock pin. 3. Use RIL request, REQUEST_QUERY_FACILITY_LOCK, to get pin lock status. * Expected Result: Can get pin lock status. * Actual Result: Get 'GenericFailure' error. * Occurrence rate 100%
Attached file fugu_logcat.txt (deleted) —
Fugu log: // Card is in 'pinRequired' state 11-28 00:33:23.540 121 121 I Gecko : -*- RadioInterface[1]: Received message from worker: {"rilMessageType":"cardstatechange","cardState":"pinRequired"} // Try to get pin status but get 'GenericFailure' error 11-28 00:40:49.180 114 148 I RILC : [w] enter processCommandsCallback 11-28 00:40:49.180 114 154 D RILC : [w] PCB request code 42 token 43 11-28 00:40:49.180 114 154 D RILC : [w] [0043]> QUERY_FACILITY_LOCK (SC,,7,(null)) 11-28 00:40:49.180 114 154 D RIL : [w] onRequest: QUERY_FACILITY_LOCK sState=3 11-28 00:40:49.180 114 154 D RIL : [w] channel1 state: '0' 11-28 00:40:49.180 114 154 D RIL : [w] get Channel ID '1' 11-28 00:40:49.180 114 154 D RIL : [w] requestFacilityLock: AT+CLCK="SC",2,"",7 11-28 00:40:49.180 114 154 D AT : [w] Channel1: AT> AT+CLCK="SC",2,"",7 11-28 00:40:49.180 115 149 I RILC : [w] enter processCommandsCallback 11-28 00:40:49.180 115 152 D RILC : [w] PCB request code 42 token 35 11-28 00:40:49.180 115 152 D RILC : [w] [0035]> QUERY_FACILITY_LOCK (SC,,7,(null)) 11-28 00:40:49.180 115 152 D RIL : [w] onRequest: QUERY_FACILITY_LOCK sState=3 11-28 00:40:49.180 115 152 D RIL : [w] channel4 state: '0' 11-28 00:40:49.180 115 152 D RIL : [w] get Channel ID '4' 11-28 00:40:49.180 115 152 D RIL : [w] requestFacilityLock: AT+CLCK="SC",2,"",7 11-28 00:40:49.180 115 152 D AT : [w] Channel4: AT> AT+CLCK="SC",2,"",7 11-28 00:40:49.200 114 291 D AT : [w] Channel1: AT< +CME ERROR: 3 11-28 00:40:49.200 114 154 D RILC : [w] [0043]< QUERY_FACILITY_LOCK fails by E_GENERIC_FAILURE 11-28 00:40:49.200 114 154 D RIL : [w] put Channel ID '1' 11-28 00:40:49.200 114 154 I RILC : [w] -->SmsDispatch [154] free one command 11-28 00:40:49.210 115 292 D AT : [w] Channel4: AT< +CME ERROR: 3 11-28 00:40:49.210 115 152 D RILC : [w] [0035]< QUERY_FACILITY_LOCK fails by E_GENERIC_FAILURE 11-28 00:40:49.210 115 152 D RIL : [w] put Channel ID '4' 11-28 00:40:49.210 115 152 I RILC : [w] -->SmsDispatch [152] free one command 11-28 00:40:49.210 121 121 I Gecko : -*- RadioInterface[1]: Received message from worker: {"lockType":"pin","requestId":"id{2f725854-5949-4b55-807e-a0c1e843eb7c}","rilMessageToken":7,"rilMessageType":"iccGetCardLockState","facility":"SC","password":"","serviceClass":7,"rilRequestType":42,"rilRequestError":2,"success":false,"errorMsg":"GenericFailure"} 11-28 00:40:49.220 121 250 I Gecko : RIL Worker[0]: Already read 0
Need Bruce support.
Attached file unagi_logcat.txt (deleted) —
Compare to unagi, we can get pin status when cardState is 'pinRequired'. // Card is in 'pinRequired' state 11-28 14:22:37.303 108 108 I Gecko : -*- RadioInterface[0]: Received message from worker: {"rilMessageType":"cardstatechange","cardState":"pinRequired"} // Can get pin lock status without error. 11-28 14:25:01.974 112 181 D RILC : UI --- RIL_REQUEST_QUERY_FACILITY_LOCK (42) ---> RIL [RID 0, token id 55, data len 16] 11-28 14:25:01.974 112 181 D RILC : RID 0 voice srv: modem id=0, ma=Multimode(0), net_pref=GSM WCDMA preferred(0) 11-28 14:25:01.974 112 181 D RILC : voip_supported = 0 11-28 14:25:01.974 108 244 I Gecko : RIL Worker[0]: Outgoing parcel: 0,0,0,112,42,0,0,0,55,0,0,0,4,0,0,0,2,0,0,0,83,0,67,0,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0,55,0,0,0,32,0,0,0,97,0,48,0,48,0,48,0,48,0,48,0,48,0,48,0,56,0,55,0,49,0,48,0,48,0,50,0,102,0,102,0,102,0,102,0,102,0,102,0,102,0,102,0,56,0,57,0,48,0,54,0,49,0,57,0,48,0,48,0,48,0,48,0,0,0,0,0 11-28 14:25:01.984 112 181 D RILC : RIL_REQUEST_QUERY_FACILITY_LOCK Facility SC, pw , service_class 7 11-28 14:25:01.984 112 181 D RILC : RID 0 corresponds to as_id 0 11-28 14:25:01.984 112 181 D RILC : RIL --- INTERNAL_MMGSDI_GET_PIN1_STATUS(200710), RID 0, MID 0 ---> RIL 11-28 14:25:01.984 112 181 D RILC : [RID 0] ReqList entries : 11-28 14:25:01.984 112 181 D RILC : INTERNAL_MMGSDI_GET_PIN1_STATUS (200710), token id 55 11-28 14:25:01.984 112 181 D RILC : [RID 0] ReqList entries : Empty 11-28 14:25:01.984 112 181 D RILC : UI <--- INTERNAL_MMGSDI_GET_PIN1_STATUS (200710) Complete --- RIL [RID 0, Token 55, Success, Len 4 ] 11-28 14:25:01.984 108 108 I Gecko : -*- RadioInterface[0]: Received message from worker: {"lockType":"pin","requestId":"id{396276f9-ce02-456a-b5b0-0b490f452ad2}","rilMessageToken":10,"rilMessageType":"iccGetCardLockState","facility":"SC","password":"","serviceClass":7,"rilRequestType":42,"rilRequestError":0,"success":true,"enabled":true}
Our modem don't support QUERY_FACILITY_LOCK when PIN code needed. we have patched this issue in the gaia to avoid this operation in UI
(In reply to sam.hua from comment #4) > Our modem don't support QUERY_FACILITY_LOCK when PIN code needed. > > we have patched this issue in the gaia to avoid this operation in UI Hi Sam, Will you provide a patch?
Flags: needinfo?(timdream)
Flags: needinfo?(sam.hua)
I don't understand what this has to do with UI, from comment 0 and comment 4. I would imagine such error/unavailable information is properly exposed with API so that UI could handle it accordingly.
Flags: needinfo?(timdream)
James, could you handle on your side?
Flags: needinfo?(james.zhang)
We discuss with our modem team, it's very difficult to handle this issue on sprd modem side quickly, maybe we can improve in next chipset platform. Can you help to handle on gaia side, don't query status when pin lock?
Flags: needinfo?(james.zhang)
(In reply to James Zhang from comment #8) > We discuss with our modem team, it's very difficult to handle this issue on > sprd modem side quickly, maybe we can improve in next chipset platform. > Can you help to handle on gaia side, don't query status when pin lock? This kind of UX flow will be very different form other devices. We need not only to discuss with UX team to design a new UX for this but also to convinced Gaia team to maintain 2 different Gaia codes. I wonder if there is the alternative solution for this. Steven, need your help to host a meeting for this change.
Flags: needinfo?(sam.hua) → needinfo?(styang)
blocking-b2g: --- → fugu?
Flags: needinfo?(styang)
blocking-b2g: fugu? → -
Flags: needinfo?(sam.hua)
blocking-b2g: - → ---
Hi Edgar, could u use getSIMStatus instead of QueryFacilityLock ?
Flags: needinfo?(sam.hua)
blocking-b2g: --- → 1.3?
UX, Please provide help in understanding next steps.
blocking-b2g: 1.3? → ---
Flags: needinfo?(firefoxos-ux-bugzilla)
I don't understand the nature of the UX request here. This bug thread, generally speaking, has evolved from a hardware issue (i.e. the modem can't do this) to Gaia potentially changing as a result/in lieu of the modem, but then that means two different Gaia codes. We would need to have agreement about maintaining two different Gaia codes before we'd do any UX for Gaia. What exactly is the feature here, whose backlog would this be in, and will it be in that backlog for 1.4? Flagging Kevin to see if he can help direct this. Sorry, Kevin!
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(khu)
It's about the DSDS feature in the Fugu device. This issue is only existed in the Fugu device. We are unable to get the pin lock status. Because it looks like it can't be fixed in partner side, we are exploring the opportunity to see if we can provide a better UX for this situation. Maybe Edgar or Hsinyi can provide more detailed information(from users' perspective) for this issue?
Flags: needinfo?(khu) → needinfo?(htsai)
Let me try to explain the whole story :) So... EJ, Arthur and I brainstormed a bit but failed to come out a good solution without modem fix. Due to the gaia implementation issue, redesign of UX flow cannot really help. I am going to clear ni due to the reason. However, I will still write down what EJ, Arthur and I have discussed for tracking. ====== Previous discussion and we realized the gaia fix seems not likely ====== Current B2G UI design: Assume user has SIM PIN funciton enabled but have not unlocked the PIN code yet. 1) Go to settings APP --> SIM security, user should see "SIM 1 PIN" enabled 2) User taps on "SIM 1 PIN" to disable the function. 3) App pops out a screen to ask user to "enter SIM PIN." And only when user unlocks the PIN code, she is able to disable the SIM PIN function. The problem we encounter on fugu is: If user haven't unlocked/entered the PIN code, APP is unable to show the correct the state of whether "SIM PIN" function is enabled or not. Step 1) fails. And that's what this bug's tile says, REQUEST_QUERY_FACILITY_LOCK returns 'GenericFailure' when cardState is 'pinRequired.' So, how about we change the flow as follows? While user enters "SIM security menu" we check the 'cardState.' If the cardState is pinRequired, a "Enter SIM PIN" window pops out. Only when the cardState is ready could user see "SIM 1PIN" and "Change PIN" icons. Unfortunately, gaia folks told me it's not possible. It's only possible that a "Enter SIM PIN" window is popping out, when user enters the "settings app" but not "SIM security menu." In summary, we do need modem support! ;)
Flags: needinfo?(htsai)
(In reply to sam.hua from comment #10) > Hi Edgar, > > could u use getSIMStatus instead of QueryFacilityLock ? Hi Sam, |getSIMStatus| helps us to know "if "SIM PIN" is locked/unlocked." However, what our gaia needs to know is if "SIM PIN function" has been enabled, not if "SIM PIN" is locked/unlocked. That said, we can conjecture that "SIM PIN function" is enabled while "SIM PIN" is locked for sure. However, without QueryFacilityLock, we don't have a way to tell if "SIM PIN function" is still enabled when cardState is ready because "cardState being ready" implies either "SIM PIN has been entered/unlocked" or "SIM PIN function is disabled." So, the answer is unfortunately no :(
Flags: needinfo?(sam.hua)
Flags: needinfo?(bruce.jiang)
If ril_worker.js get gerenal failure of REQUEST_QUERY_FACILITY_LOCK,could it send a GET_SIM_STATUS to RILC?
Flags: needinfo?(sam.hua)
need spreadtrum major bug to track
Flags: needinfo?(sam.hua)
(In reply to sam.hua from comment #16) > If ril_worker.js get gerenal failure of REQUEST_QUERY_FACILITY_LOCK,could it > send a GET_SIM_STATUS to RILC? The problem remains. What if we somehow get general failure of REQUEST_QUERY_FACILITY_LOCK but get "ready" cardState? Then we still have no way to tell the accurate status. Our gaia and gecko developers brainstormed a little bit to try to come out workarounds. However, we found these potential workarounds are error-prone. :( We do need modem's support.
Hi Hsin, if we fix the "REQUEST_QUERY_FACILITY_LOCK",we will have other problems: "REQUEST_SET_FACILITY_LOCK" and "REQUEST_GET_UNLOCK_RETRY_COUNT" also can't work correctly when pin code is required. our modem doesn't support operations about SIM card when pin code is required, but "Settings" app think it will.
Flags: needinfo?(sam.hua)
Flags: needinfo?(htsai)
Hi Steven, I assign this bug to you. We need your help to talk with partner to fix this bug in modem. If partner would like to change UI for fixing this bug, you need to talk with UX and Gaia team for this change.
Assignee: nobody → styang
Flags: needinfo?(htsai)
Whiteboard: POVB, dsdsrun1.3-2
Component: RIL → Vendcom
it also happen in Tarako,so we add a patch for it. could it be merged into 1.3t?
Flags: needinfo?(bruce.jiang) → needinfo?(styang)
Attached patch 235801_to_v1.3_for_265203.patch (deleted) — Splinter Review
it also happen in Tarako,so we add a patch for it. could it be merged into 1.3t?
Attachment #8402464 - Flags: review?(htsai)
Flags: needinfo?(styang)
Comment on attachment 8402464 [details] [diff] [review] 235801_to_v1.3_for_265203.patch Review of attachment 8402464 [details] [diff] [review]: ----------------------------------------------------------------- This touches gaia settings APP. Arthur should be the proper reviewer!
Attachment #8402464 - Flags: review?(htsai) → review?(arthur.chen)
Comment on attachment 8402464 [details] [diff] [review] 235801_to_v1.3_for_265203.patch Review of attachment 8402464 [details] [diff] [review]: ----------------------------------------------------------------- ::: apps/settings/js/simcard_lock.js @@ +83,5 @@ > // in this way, we have to use isAirplaneMode to check this situation > + // when fugu 'sim is lock by pin/puk the CLCK cmd won't be responed > + // so in the case of locked , disable he checkbok > + if (!isSimAvailable || this.isAirplaneMode || > + icc.cardState == 'pinRequired' || I would suggest to add the checks in the evaluation of "isSimAvailable".
Attachment #8402464 - Flags: review?(arthur.chen)
Attached patch 944263_April_10.patch (deleted) — Splinter Review
Okay. Please check the new patch
Flags: needinfo?(arthur.chen)
Looks good to me. Could you create a pull request so that we can have travis run the tests, thanks.
Flags: needinfo?(arthur.chen)
Flags: needinfo?(arthur.chen)
Please check my github comments.
Flags: needinfo?(arthur.chen)
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: