1130546 - [STK] Null iccId value results in no TR being sent

Status: RESOLVED INVALID

(Firefox OS Graveyard :: RIL, defect)

Description

[Carol Yang [:cyang]]

If iccId has not been read and a proactive STK command is received, there will be no terminal response sent from Gaia for that STK command.

I noticed that there is a check at [1] to prevent this from happening. However, the check at [2] would be encountered first, preventing the code path to even go down to [1].

Also, assuming we do get to [1], eventually responseSTKCommand will be called. The check at [3] will also prevent the TR from being sent because _icc would be null.

I was just wondering if there was still a way to to send TR without a valid iccId? Perhaps, can it be based on clientId rather than iccId to determine which SIM the proactive command was for?

[1] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/icc_worker.js#L387
[2] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/icc.js#L160
[3] https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/icc.js#L209

Comment 1

[Carol Yang [:cyang]]

Fernando,

One of the reason the iccId could be null is during bootup, if the iccId has not been read yet but the proactive command was already received, we could run into this issue. Just thought I'd check with you to see your thoughts on this?

Thanks,
Carol

Comment 2

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Hi Carol, this bug looks a race condition. We can add a Promise to recover the IccId and delay STK response until we've a valid iccid.

WDYT?

Comment 3

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

Sorry, re-reading the description I saw the ICCId you mean is the one received into the STK message

If this data is undefined we cann't guess which simcard send it ... so the main question is why this data is empty !

Comment 4

[Carol Yang [:cyang]]

(In reply to Fernando R. Sela (no CC, needinfo please) [:frsela] from comment #3)
> Sorry, re-reading the description I saw the ICCId you mean is the one
> received into the STK message
> 
> If this data is undefined we cann't guess which simcard send it ... so the
> main question is why this data is empty !

In some cases, I've seen that as soon as the radio is turned on, a proactive STK command may be issued. This might be so early that iccId has not been read from the SIM card yet.

The question is, why do we have to depend on iccId to know which card to send to. Can't we rely on the clientId for this?

Comment 5

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

(In reply to Carol Yang [:cyang] from comment #4)
> (In reply to Fernando R. Sela (no CC, needinfo please) [:frsela] from
> comment #3)
> > Sorry, re-reading the description I saw the ICCId you mean is the one
> > received into the STK message
> > 
> > If this data is undefined we cann't guess which simcard send it ... so the
> > main question is why this data is empty !
> 
> In some cases, I've seen that as soon as the radio is turned on, a proactive
> STK command may be issued. This might be so early that iccId has not been
> read from the SIM card yet.
> 

So, this is a Gecko issue ... it should wait for ICCID before progress the message to upper layers

> The question is, why do we have to depend on iccId to know which card to
> send to. Can't we rely on the clientId for this?

This is for DSDS support. In the past we decide to use ICCId, changing this requires gecko changes too.

Comment 6

[Noemí Freire (:noemi)]

Per comment 5 changing the component and asking Hsin-Yi for her input here. Thanks!

Comment 7

[Manuel Casas Barrado [:mancas]]

Clearing my ni

Comment 8

[Bevis Tseng[:bevis][:btseng](Exited)]

I'll take this bug first to follow up.

Per offline discussion, there are 2 solutions available:
1. Enqueue the received proactive commands from rild and send them after iccId is available and iccInfo is notified according to current WebAPI design. (For Gaia, Icc will be detected until IccInfo with valid iccId is detected.) [1].
The only risk is that if the time from proactive command received to the time iccId received takes too long, we don't know if there is any timeout detected internally in the STK app of the inserted UICC.
2. Replace iccId with clientId:
   That means the entire design of Icc between Gaia/Gecko has to be changed.
   - Unlike mobileconnection, there is always fix number of clientIds available, 
     both gaia/gecko relies on iccId to know whether a valid ICC is inserted or not.
   This introduce different design in MozIccManager.webidl.
   That also implies major change in gaia for both stk handling and normal access of other UICC
   features like ADN/FDN, etc.

NI Carol to see if solution 1) is possible to fix this problem instead of adoption clientId in current ICC design.

[1] https://hg.mozilla.org/mozilla-central/file/e0cb32a0b1aa/dom/icc/IccListener.cpp#l113

Comment 9

[Bevis Tseng[:bevis][:btseng](Exited)]

NI for the question in comment 8.

Comment 10

[Bevis Tseng[:bevis][:btseng](Exited)]

Hi Carol,

After further analysis, we realized that, in MOZ-RIL implementation, ril_worker will issue REQUEST_REPORT_STK_SERVICE_IS_RUNNING after iccid is retrieved to prevent the symptom of this bug happened. [1]

Besides, according to the REQUEST_REPORT_STK_SERVICE_IS_RUNNING defined in ril.h, it's obvious that
the RIL_UNSOL_STK_XXX shall be received after this request is sent: [2]
/**
 * RIL_REQUEST_REPORT_STK_SERVICE_IS_RUNNING
 *
 * Indicates that the StkSerivce is running and is
 * ready to receive RIL_UNSOL_STK_XXXXX commands.
 *
 * "data" is NULL
 * "response" is NULL
 *
 * Valid errors:
 *  SUCCESS
 *  RADIO_NOT_AVAILABLE
 *  GENERIC_FAILURE
 *
 */
#define RIL_REQUEST_REPORT_STK_SERVICE_IS_RUNNING 103

Would you please also help to check if your implementation has follow this call flow to prevent proative command to be received before iccid is retrieved?

Thanks!

[1] https://hg.mozilla.org/mozilla-central/file/e0cb32a0b1aa/dom/system/gonk/ril_worker.js#l12837
[2] http://androidxref.com/5.0.0_r2/xref/hardware/ril/include/telephony/ril.h#3590

Comment 11

[Carol Yang [:cyang]]

Hi Bevis,

You're right, the timing of when REQUEST_REPORT_STK_SERVICE_IS_RUNNING is sent is important, i.e. after IccId is read.

On this note, maybe this is not much of an issue now but there could be the case where a SIM contains STK apps on different card types. So for the same IccId, you can have the case where you have more than one STK app. Maybe something to consider is using IccId+ApplicationId as a unique identifier in the future?

For the time being, this bug is no longer an issue.

Thanks!