Closed Bug 970174 Opened 6 years ago Closed 6 years ago

[Fugu] After PUK is locked, RIL_REQUEST_GET_SIM_STATUS seems doesn't response correct result.

Categories

(Firefox OS Graveyard :: Vendcom, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(tracking-b2g:backlog)

RESOLVED FIXED
tracking-b2g backlog

People

(Reporter: edgar, Assigned: sam.hua)

References

Details

(Whiteboard: [POVB][dolphin_test_wanted])

Attachments

(7 files, 1 obsolete file)

+++ This bug was initially created as a clone of Bug #962927 +++

After entering 10th incorrect PUK code, fugu's rilc reports |app_state| as "6", but it seems there is no such define in ril.h [1]. So gecko treats it as 'unknown' state. (RIL_REQUEST_GET_SIM_STATUS [2])

--
02-10 11:32:10.250   106   223 I Gecko   : RIL Worker[0]: iccStatus: {"cardState":1,"universalPINState":0,"gsmUmtsSubscriptionAppIndex":0,"cdmaSubscriptionAppIndex":8,"imsSubscriptionAppIndex":8,"apps":[{"app_type":2,"app_state":6,"perso_substate":0,"aid":null,"app_label":null,"pin1_replaced":0,"pin1":0,"pin2":0}]}
--

Check the design of AOSP [3], |app_state| will stay in 'RIL_APPSTATE_PUK' and |pin1_state| will be 'RIL_PINSTATE_ENABLED_PERM_BLOCKED' [4] in such case.

Hi Sam, could you help to check about this? Thank you.

[1] https://github.com/mozilla-b2g/platform_hardware_ril/blob/master/include/telephony/ril.h#L471-L479
[2] https://github.com/mozilla-b2g/platform_hardware_ril/blob/master/include/telephony/ril.h#L812-L824
[3] http://androidxref.com/source/xref/frameworks/opt/telephony/src/java/com/android/internal/telephony/IccCardProxy.java#347
[4] https://github.com/mozilla-b2g/platform_hardware_ril/blob/master/include/telephony/ril.h#L487
Flags: needinfo?(sam.hua)
ok.
could u give me log about -b radio?
I don't know the right PUK2 code about my test SIM card, so i can't reproduce it.
Flags: needinfo?(sam.hua)
And in sprd_ril.h

typedef enum {
    RIL_APPSTATE_ILLEGAL               = -1,
    RIL_APPSTATE_UNKNOWN               = 0,
    RIL_APPSTATE_DETECTED              = 1,
    RIL_APPSTATE_PIN                   = 2, /* If PIN1 or UPin is required */
    RIL_APPSTATE_PUK                   = 3, /* If PUK1 or Puk for UPin is required */
    RIL_APPSTATE_SUBSCRIPTION_PERSO    = 4, /* perso_substate should be look at
                                               when app_state is assigned to this value */
    RIL_APPSTATE_READY                 = 5,
    RIL_APPSTATE_BLOCKED               = 6
} RIL_AppState;

I think u have this file.
Attached file fugu_puk_locked.txt
(In reply to sam.hua from comment #1)
> ok.
> could u give me log about -b radio?
> I don't know the right PUK2 code about my test SIM card, so i can't
> reproduce it.

Here you are, putting a puk locked sim card into slot 0.

02-10 13:27:54.400   106   225 I Gecko   : RIL Worker[0]: iccStatus: {"cardState":1,"universalPINState":0,"gsmUmtsSubscriptionAppIndex":0,"cdmaSubscriptionAppIndex":8,"imsSubscriptionAppIndex":8,"apps":[{"app_type":2,"app_state":6,"perso_substate":0,"aid":null,"app_label":null,"pin1_replaced":0,"pin1":0,"pin2":0}]}
(In reply to sam.hua from comment #2)
> And in sprd_ril.h
> 
> typedef enum {
>     RIL_APPSTATE_ILLEGAL               = -1,
>     RIL_APPSTATE_UNKNOWN               = 0,
>     RIL_APPSTATE_DETECTED              = 1,
>     RIL_APPSTATE_PIN                   = 2, /* If PIN1 or UPin is required */
>     RIL_APPSTATE_PUK                   = 3, /* If PUK1 or Puk for UPin is
> required */
>     RIL_APPSTATE_SUBSCRIPTION_PERSO    = 4, /* perso_substate should be look
> at
>                                                when app_state is assigned to
> this value */
>     RIL_APPSTATE_READY                 = 5,
>     RIL_APPSTATE_BLOCKED               = 6
> } RIL_AppState;
> 
> I think u have this file.

But AOSP has already provided a way to handle this, could we follow the same way instead of using a sprd specific define? Thank you.
I am afraid that our modem won't change their response. I will change it in RILC.

the original response to RIL_WORKER:
        /* SIM_BLOCK = 6 */
        { RIL_APPTYPE_SIM, RIL_APPSTATE_BLOCKED, RIL_PERSOSUBSTATE_UNKNOWN,
            NULL, NULL, 0, RIL_PINSTATE_UNKNOWN, RIL_PINSTATE_UNKNOWN },
I will change them to 
        /* SIM_BLOCK = 6 */
        { RIL_APPTYPE_SIM, RIL_APPSTATE_BLOCKED, RIL_PERSOSUBSTATE_UNKNOWN,
            NULL, NULL, 0, RIL_PINSTATE_ENABLED_PERM_BLOCKED, RIL_PINSTATE_UNKNOWN },

but which app state should be return? RIL_APPSTATE_PIN or RIL_APPSTATE_PUK
Flags: needinfo?(echen)
(In reply to sam.hua from comment #5)
> I am afraid that our modem won't change their response. I will change it in
> RILC.
> 
> the original response to RIL_WORKER:
>         /* SIM_BLOCK = 6 */
>         { RIL_APPTYPE_SIM, RIL_APPSTATE_BLOCKED, RIL_PERSOSUBSTATE_UNKNOWN,
>             NULL, NULL, 0, RIL_PINSTATE_UNKNOWN, RIL_PINSTATE_UNKNOWN },
> I will change them to 
>         /* SIM_BLOCK = 6 */
>         { RIL_APPTYPE_SIM, RIL_APPSTATE_BLOCKED, RIL_PERSOSUBSTATE_UNKNOWN,
>             NULL, NULL, 0, RIL_PINSTATE_ENABLED_PERM_BLOCKED,
> RIL_PINSTATE_UNKNOWN },
> 
> but which app state should be return? RIL_APPSTATE_PIN or RIL_APPSTATE_PUK

Sam,
RIL_APPSTATE_PUK please, (see Bug 930394).

Shawn
OK
I will upload the .so later,please test it and i will commit it if it is ok.
(In reply to sam.hua from comment #7)
> OK
> I will upload the .so later,please test it and i will commit it if it is ok.

Thank you, Sam and Shawn.
Flags: needinfo?(echen)
Attached file libreference-ril_sp.so (obsolete) —
new rilc lib
Hi edgar,
The bug is fixed or not with new lib?
Flags: needinfo?(echen)
(In reply to sam.hua from comment #10)
> Hi edgar,
> The bug is fixed or not with new lib?

Hi Sam, after apply new lib, the response of RIL_REQUEST_GET_SIM_STATUS for a blocked sim is what we expect now.

--
02-12 16:39:07.250   106   225 I Gecko   : RIL Worker[0]: iccStatus: {"cardState":1,"universalPINState":0,"gsmUmtsSubscriptionAppIndex":0,"cdmaSubscriptionAppIndex":8,"imsSubscriptionAppIndex":8,"apps":[{"app_type":2,"app_state":3,"perso_substate":0,"aid":null,"app_label":null,"pin1_replaced":0,"pin1":5,"pin2":0}]}
--

But I found another issue about UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED, after entering wrong puk 10 times into a pukRequired sim, gecko did not receive UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED to indicate the sim status is changed. So gecko doesn't update the cardState in this case. Could you help to check on this as well? Thank you.
Flags: needinfo?(sam.hua)
Flags: needinfo?(echen)
(In reply to Edgar Chen [:edgar][:echen] from comment #11)
> But I found another issue about UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED,
> after entering wrong puk 10 times into a pukRequired sim, gecko did not
> receive UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED to indicate the sim status
> is changed. So gecko doesn't update the cardState in this case. Could you
> help to check on this as well? Thank you.

Yeah Sam,

Gaia needs this event to pup up puk locked dialog ! Thanks :)
Hi echen,
OK,i will add it. and please test it after i attach the new lib.
Flags: needinfo?(sam.hua)
Attached file libreference-ril_sp.so
pls check if it is ok.
Flags: needinfo?(echen)
Comment on attachment 8373166 [details]
libreference-ril_sp.so

Obsolete old one.
Attachment #8373166 - Attachment is obsolete: true
(In reply to sam.hua from comment #14)
> Created attachment 8375391 [details]
> libreference-ril_sp.so
> 
> pls check if it is ok.

Gecko still doesn't receive UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED. :(
Flags: needinfo?(echen) → needinfo?(sam.hua)
please use it to test RIL will send SIM_STATUS_CHANGED to RIL_WORKER when PUK is locked
Flags: needinfo?(sam.hua)
(In reply to sam.hua from comment #17)
> Created attachment 8380447 [details]
> libreference-ril_sp_feb24.so
> 
> please use it to test RIL will send SIM_STATUS_CHANGED to RIL_WORKER when
> PUK is locked

Thank you, Sam. I will test it and get back to you later.

ni? me for tracking.
Flags: needinfo?(echen)
Gecko still doesn't receive UNSOLICITED_RESPONSE_SIM_STATUS_CHANGED. :(
Flags: needinfo?(echen) → needinfo?(sam.hua)
lib updated.

AT+SIND:0 is the indication from modem.
Flags: needinfo?(sam.hua)
Flags: needinfo?(echen)
I don't have enough sim card to verify it. (All of my sim card became to "permanentBlocked" now :()
I will try to find one to test it. And if you can help to test it in your side, that will be great. ;)
Flags: needinfo?(echen)
Flags: needinfo?(echen)
(In reply to Edgar Chen [:edgar][:echen] from comment #21)
> I don't have enough sim card to verify it. (All of my sim card became to
> "permanentBlocked" now :()
> I will try to find one to test it. And if you can help to test it in your
> side, that will be great. ;)

Hi Sam,

Due to I don't have enough sim card now, is it possible to help to test it on you side?

Thank you.
Flags: needinfo?(sam.hua)
okay.
Flags: needinfo?(sam.hua)
blocking-b2g: --- → 1.4?
Joe, not sure wht this was nominated for 1.4? Looks like a POVB issue so clearing the nomination for now till we have a better understanding here.
blocking-b2g: 1.4? → -
(In reply to bhavana bajaj [:bajaj] from comment #24)
> Joe, not sure wht this was nominated for 1.4? Looks like a POVB issue so
> clearing the nomination for now till we have a better understanding here.

This bug blocks bug 962927, which is a 1.4+ bug.
blocking-b2g: - → 1.4?
Whiteboard: [POVB]
Sam

Would it be ok if this bug is assigned to you, given your active participation?

Please advice.
Flags: needinfo?(sam.hua)
triage: 1.4+ to unblock another 1.4+ bug
Steven, do you mind checking with partner? Thanks
blocking-b2g: 1.4? → 1.4+
Flags: needinfo?(styang)
Flags: needinfo?(echen)
I will test it in latest build of Tarako.
Sam seems to be the assignee of this bug.
Assignee: nobody → sam.hua
Flags: needinfo?(sam.hua)
Hi Sam, please update the result of Tarako once done. thanks!
Flags: needinfo?(styang) → needinfo?(sam.hua)
it is fixed now
Flags: needinfo?(sam.hua)
Fixed in Tarako,not fugu
Fixed in Tarako,not fugu
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #25)
> (In reply to bhavana bajaj [:bajaj] from comment #24)
> > Joe, not sure wht this was nominated for 1.4? Looks like a POVB issue so
> > clearing the nomination for now till we have a better understanding here.
> 
> This bug blocks bug 962927, which is a 1.4+ bug.

Now, bug 962927 was resolved. The original reason for this bug to be 1.4+ is not existed anymore. Suggest to remove 1.4+.
blocking-b2g: 1.4+ → 1.4?
(In reply to Kevin Hu [:khu] from comment #34)
> Now, bug 962927 was resolved. The original reason for this bug to be 1.4+ is
> not existed anymore. Suggest to remove 1.4+.

Hi Kevin, 

Eric needs this bug fixed to verify bug 962927. You can check comments there !
Do we have an ETA for this bug? Thanks!
Flags: needinfo?(sam.hua)
Discussed in triage - we can unblock this since the blocking bug landed. We just got Flame builds available for trunk, so QA is unblocked here for testing.
blocking-b2g: 1.4? → backlog
it is fixed  now
Flags: needinfo?(sam.hua)
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(In reply to sam.hua from comment #38)
> it is fixed  now
Hi, Sam, Thanks, so it is fixed for Fugu, could you send the firmware to me, thank you.
We don't maintain fugu now. 

Could u use dolphin or tarako?
Our dolphin is not ready yet, and tarako is a v1.3 phone. 
(In reply to sam.hua from comment #40)
> We don't maintain fugu now. 
> 
> Could u use dolphin or tarako?
Whiteboard: [POVB] → [POVB][dolphin_test_wanted]
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.