Closed Bug 1062862 Opened 5 years ago Closed 2 years ago

[dolphin][GCF] STK‘27.22.4.7.1/1’fail,STK After FETCH and before TERMINAL RESPONSE the ME didn't perform SIM initialisation

Categories

(Firefox OS Graveyard :: RIL, defect, major)

ARM
Gonk (Firefox OS)
defect
Not set
major

Tracking

(blocking-b2g:-)

RESOLVED WONTFIX
blocking-b2g -

People

(Reporter: shiwei.zhang, Unassigned)

References

Details

(Whiteboard: sprd347137)

Attachments

(3 files)

Steps to reproduce:
1> STK‘27.22.4.7.1/1’REFRESH, SIM Initialization
2> After FETCH and before TERMINAL RESPONSE the ME didn't perform SIM initialisation
REFRESH: Administrative Information request not performed.
REFRESH: IMSI request not performed.
REFRESH: Access Control request not performed.
REFRESH: HPLMN Search Period request not performed.
REFRESH: PLMN selector request not performed.
REFRESH: Location Information request not performed.
REFRESH: Cipher Key request not performed.
REFRESH: Forbidden PLMN request not performed.
REFRESH: CBMID request not performed.
Attachment is slog and I think we could pay more attention to this part
 
11-15 03:21:56.500   108   525 I Gecko   : RIL Worker: Received 24 bytes.
11-15 03:21:56.500   108   525 I Gecko   : RIL Worker: Already read 0
11-15 03:21:56.500   108   525 I Gecko   : RIL Worker: New incoming parcel of size 20
11-15 03:21:56.500   108   525 I Gecko   : RIL Worker: Parcel (size 20): 1,0,0,0,249,3,0,0,1,0,0,0,0,0,0,0,255,255,255,255
11-15 03:21:56.500   108   525 I Gecko   : RIL Worker: We have at least one complete parcel.
11-15 03:21:56.500   108   525 I Gecko   : RIL Worker: [0] Unsolicited response for request type 1017
11-15 03:21:56.500   108   525 I Gecko   : RIL Worker: Parcel handler didn't consume whole parcel, 12 bytes left over
11-15 03:21:56.500   108   525 I Gecko   : RIL Worker: Next parcel size unknown, going to sleep.
In gecko/dom/system/gonk/ril_worker.js

RilObject.prototype[UNSOLICITED_SIM_REFRESH] = null;

Maybe providing an implementation for UNSOLICITED_SIM_REFRESH can have the problem solved.
blocking-b2g: --- → 1.4?
Summary: [dolphin]STK After FETCH and before TERMINAL RESPONSE the ME didn't perform SIM initialisation → [dolphin][GCF] STK‘27.22.4.7.1/1’fail,STK After FETCH and before TERMINAL RESPONSE the ME didn't perform SIM initialisation
Whiteboard: sprd347137
there is something wrong with response so quickly for Refresh STK command. Should be waiting for the device finished. But for original code, this part function is null.
STK sim refresh did not come up via UNSOLICITED_SIM_REFRESH, but STK command with type - STK_CMD_REFRESH. for init case, it will result in fetchICCRecords();.

The notification way is different to AOSP. please note it.


  /**
   * Construct a param for Refresh.
   *
   * @param cmdDetails
   *        The value object of CommandDetails TLV.
   * @param ctlvs
   *        The all TLVs in this proactive command.
   */
  processRefresh: function(cmdDetails, ctlvs) {
    let refreshType = cmdDetails.commandQualifier;
    switch (refreshType) {
      case STK_REFRESH_FILE_CHANGE:
      case STK_REFRESH_NAA_INIT_AND_FILE_CHANGE:
        let ctlv = this.context.StkProactiveCmdHelper.searchForTag(
          COMPREHENSIONTLV_TAG_FILE_LIST, ctlvs);
        if (ctlv) {
          let list = ctlv.value.fileList;
          if (DEBUG) {
            this.context.debug("Refresh, list = " + list);
          }
          this.context.ICCRecordHelper.fetchICCRecords();
        }
        break;
    }
    return null;
  },
Flags: needinfo?(siiaceon.cao)
thanks shawn, I agree with you .  Fetch means SIM has done the refresh operation, and then need ME fetch the information, then give a response to SIM. It's a correct process. But between the duration which after fetch and before terminal response, the ME hardware or modem or software will also do something refresh related operation, the Terminal Response should wait for the ME finishe, but infact not. So we should focus how to make this Terminal Response after recieve modem(or something) finished message. Agree?
Flags: needinfo?(siiaceon.cao)
Yes, I find processRefresh() is called in a message handling function,see
RilObject.prototype[UNSOLICITED_STK_PROACTIVE_COMMAND] = function UNSOLICITED_STK_PROACTIVE_COMMAND(){... ...}.
in this fuction, sendChromeMessage() will dispatch the chromeMessage to gaia, and according to siiaceon's suggestion, when gaia catch the chromeMessage in STK_CMD_REFRESH(message), Terminal Response will be send, But modem refresh operation probably is not ready at this time.

How to ensure modem refresh is ready? I think UNSOLICITED_SIM_REFRESH is used for this.
Can we deal it like this?
-RilObject.prototype[UNSOLICITED_SIM_REFRESH] = null;
+RilObject.prototype[UNSOLICITED_SIM_REFRESH] = function UNSOLICITED_SIM_REFRESH() {
+  let response = {
+    command: {
+      commandNumber: 0x01,
+      typeOfCommand: STK_CMD_REFRESH,
+    },
+    resultCode: STK_RESULT_OK
+  };
+  this.sendStkTerminalResponse(response);
+};

UNSOLICITED_SIM_REFRESH() will handle modem unsolicited refresh message
I looked at the log and it seems the real problem is, currently ril_worker doesn't handle "STK_REFRESH_NAA_INIT (0x03, commandQualifier = 3)". See [1]. Could you please try to add "STK_REFRESH_NAA_INIT" in the switch-case and see if it helps?

Except above, the general process looks quite good. And for this issue it doesn't seem we need UNSOLICITED_SIM_REFRESH because according to the conformance test spec, "PROACTIVE SIM SESSION
ENDED" will be sent to ME as a signal.

Hope it helps.

== log snippet ===
11-15 03:21:53.420   108   525 I Gecko   : RIL Worker: [0] Handling parcel as UNSOLICITED_STK_PROACTIVE_COMMAND
11-15 03:21:53.430   108   525 I Gecko   : RIL Worker: [0] commandNumber = 1 typeOfCommand = 1 commandQualifier = 3
===

[1] https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/file/a8f4c8ed3a6d/dom/system/gonk/ril_worker.js#l10177
(In reply to Hsin-Yi Tsai (OOO Sep. 8 ~ Sep. 10) [:hsinyi] from comment #8)
Thanks, Hsin-Yi, I have added "STK_REFRESH_NAA_INIT" in the switch-case, but this modification can't help to handle this issue. I can see Terminal Response always send along with processRefresh().

And "request type 1017" is still no handling function and Terminal Responses.
please see this

I/Gecko   (  106): RIL Worker: Parcel (size 20): 1,0,0,0,249,3,0,0,1,0,0,0,0,0,0,0,255,255,255,255
I/Gecko   (  106): RIL Worker: We have at least one complete parcel.
I/Gecko   (  106): RIL Worker: [0] Unsolicited response for request type 1017
I/Gecko   (  106): RIL Worker: Parcel handler didn't consume whole parcel, 12 bytes left over
I/Gecko   (  106): RIL Worker: Next parcel size unknown, going to sleep.
Can you triage this?
Flags: needinfo?(wchang)
(In reply to Shiwei Zhang from comment #9)
> (In reply to Hsin-Yi Tsai (OOO Sep. 8 ~ Sep. 10) [:hsinyi] from comment #8)
> Thanks, Hsin-Yi, I have added "STK_REFRESH_NAA_INIT" in the switch-case, but
> this modification can't help to handle this issue. I can see Terminal
> Response always send along with processRefresh().
> 
> And "request type 1017" is still no handling function and Terminal Responses.
> please see this
> 
> I/Gecko   (  106): RIL Worker: Parcel (size 20):
> 1,0,0,0,249,3,0,0,1,0,0,0,0,0,0,0,255,255,255,255
> I/Gecko   (  106): RIL Worker: We have at least one complete parcel.
> I/Gecko   (  106): RIL Worker: [0] Unsolicited response for request type 1017
> I/Gecko   (  106): RIL Worker: Parcel handler didn't consume whole parcel,
> 12 bytes left over
> I/Gecko   (  106): RIL Worker: Next parcel size unknown, going to sleep.

Hi Shiwei, 

Thanks for giving it a try. And please let me understand more about the real problem we want to resolve.

The original reported problem is comment 0: After FETCH and before TERMINAL RESPONSE the ME didn't perform SIM initialization. And my comment 8 is trying to resolve this. I.e. with comment 8, fetchICCRecords() will be called and it results in SIM initialization surely. So it seems to me we don't really need to handle request type 1017, no?  Am I missing something? Thank you.
IIRC SIM Refresh support is not mandatory for GCF, we don't need to claim support here.

Hsin-yi, can you correct me if I am wrong?
Flags: needinfo?(wchang)
(In reply to Hsin-Yi Tsai (OOO Sep. 8 ~ Sep. 10) [:hsinyi] from comment #11)
> Thanks for giving it a try. And please let me understand more about the real
> problem we want to resolve.
> 
> The original reported problem is comment 0: After FETCH and before TERMINAL
> RESPONSE the ME didn't perform SIM initialization. And my comment 8 is
> trying to resolve this. I.e. with comment 8, fetchICCRecords() will be
> called and it results in SIM initialization surely. So it seems to me we
> don't really need to handle request type 1017, no?  Am I missing something?
> Thank you.

Hi Hsin-Yi,
  I am so sorry for the bewildering description in comment 0. Infact, SIM initialisation work properly,What ril_worker need is send a TERMINAL RESPONSE when receiving initialisation finished message, this Terminal Response like a ending flag for SIM refresh operation, because STK could NOT work properly if receiving an early TERMINAL RESPONSE or no TERMINAL RESPONSE.
(In reply to Wayne Chang [:wchang] from comment #12)
> IIRC SIM Refresh support is not mandatory for GCF, we don't need to claim
> support here.
> 
> Hsin-yi, can you correct me if I am wrong?

According to TS 151.010, Table B.1, some test sequences for REFRESH are mandatory while some are not, dependent of the claim if manufacturer supports FDN, with the assumption REFRESH terminal profile (mandatory) is supported.


(In reply to Shiwei Zhang from comment #13)
> Hi Hsin-Yi,
>   I am so sorry for the bewildering description in comment 0. Infact, SIM
> initialisation work properly,What ril_worker need is send a TERMINAL
> RESPONSE when receiving initialisation finished message, this Terminal
> Response like a ending flag for SIM refresh operation, because STK could NOT
> work properly if receiving an early TERMINAL RESPONSE or no TERMINAL
> RESPONSE.

Thanks for the clarification. I am understand the problem better now. I agree that device should send TERMINAL RESPONSE to SIM only when initialization is completed. 

To achieve this, we need a good mechanism for a chain of callbacks that doesn't seem a simple work to me :(
Hi Shiwei,

We are trying to dig further and we need more assistance from you to help us debug and investigate. Could you also please test on Flame, provide us log, and report us the test result in addition to the gecko/gaia revision? Thank you very much.
Flags: needinfo?(shiwei.zhang)
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #15)
> Hi Shiwei,
> 
> We are trying to dig further and we need more assistance from you to help us
> debug and investigate. Could you also please test on Flame, provide us log,
> and report us the test result in addition to the gecko/gaia revision? Thank
> you very much.

I'm so sorry to tell you I have no equipment to do this test, all test procedures are carried out in lab. What I did is simulating UNSOLICITED AT to check ril_worker.js's responses. But this issue is solved by attached patchs, I hope that's been of some help.
Flags: needinfo?(shiwei.zhang)
together with this.
Hi Shiwei,

I read the spec TS 11.14, TS 102.223 and AOSP again. ril.h says |RIL_UNSOL_SIM_REFRESH Indicates that file(s) on the SIM have been updated, or the SIM has been reinitialized.| And TS 102.223 clause 6.4.7 states |The purpose of this command is to enable the terminal to be notified of the changes to the UICC configuration that *have occurred as the result of* a NAA application activity.| 

Therefore, the inference I drew from the documents and the AOSP is the timing and meaning of RIL_UNSOL_SIM_REFRESH and STK_CMD_REFRESH are the same. They both are the flag indicating refresh operation has been done. But it looks the timing on sprd device is different. The duration b/w STK_CMD_REFRESH and RIL_UNSOL_SIM_REFRESH is up to 3 seconds. Did I get something wrong? Could you help clarify it?

Also, the refresh mode in the log is NAA Initialization (0x03). Based on TS 102.223, this mode tells the terminal to carry out NAA initialization as it is defined by the NAA, starting after the PIN verification procedure. However, I am not sure how gecko framework is able to handle NAA initialization. I suspect this NAA initialization has to be done on baseband/modem. If that's the case, then baseband/modem should also be the one in charge of sending TERMINAL response. How do you think?  Thank you!
blocking-b2g: 1.4? → -
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #18)
Dear Hsin,
  STK_CMD_REFRESH is reported by UNSOLICITED_STK_PROACTIVE_COMMAND, isn't it? I find these words in TS 11.14, 

4.2 Proactive SIM
Proactive SIM gives a mechanism whereby the SIM can initiate actions to be taken by the ME. These actions
include:
... ...
SIM initialization request and notification of changes to EF(s);
... ...

6.1 Introduction
... ...
REFRESH, which requests the ME to carry out a SIM initialization according to GSM 11.11 subclause 11.2.1,
and/or advises the ME that the contents or structure of EFs on the SIM have been changed. 
... ...

I'm not sure if STK_CMD_REFRESH indicating refresh operation has been done, but ME needn't send TERMINAL RESPONSE (OK) in this case, but we did.
(In reply to Shiwei Zhang from comment #19)
> I'm not sure if STK_CMD_REFRESH indicating refresh operation has been done,
> but ME needn't send TERMINAL RESPONSE (OK) in this case, but we did.

Sorry, I have a little bit confuse here.
Do you mean modem will take care of sending TR for STK_CMD_REFRESH after modem finishes refresh operation? And gecko/gaia doesn't need to send TR?
And according to comment #6, UNSOLICITED_SIM_REFRESH is used for notifying the refresh operation in modem is finished. Gecko should do fetching EF things after receiving this unsolicited event.

So the flow should be like:
1. modem receives STK_CMD_REFRESH proactive command.
2. modem performs refresh operation.
3. modem finishes refresh operation.
4. modem sends TR.
5. modem notifies gecko the refresh operation is finished by sending UNSOLICITED_SIM_REFRESH.
6. Gecko fetches EF.

Am I right? 
Please let me know if I misunderstand anything.

Thank you.
Flags: needinfo?(shiwei.zhang)
(In reply to Edgar Chen [:edgar][:echen] from comment #20)
Hi, Edgar
As far as I know, 

> Do you mean modem will take care of sending TR for STK_CMD_REFRESH after
> modem finishes refresh operation? And gecko/gaia doesn't need to send TR?

Sprd's modem don't care the reception of STK_CMD_REFRESH TR, but UNSOLICITED_SIM_REFRESH TR is its concern.

> So the flow should be like:
> 1. modem receives STK_CMD_REFRESH proactive command.

I think we should say ME(or gecko ril_worker,but not modem)receives STK_CMD_REFRESH proactive command. 

> 4. modem sends TR.
And this TR is send from ME, isn't it?

I'm not sure the procedure of sprd's modem quite meet protocols, but we can make comparisons with other AOSP devices.
Flags: needinfo?(shiwei.zhang)
Hmm, I will check AOSP code again and update later.
In the mean time, could you help to provide the log of flame and AOSP to us for comparisons.
Thank you.
See Also: → 996369
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.