1030554 - [OPEN C_1.3]RIL:MatchMvno not sent to b2g_telephony

Status: RESOLVED FIXED

(Firefox OS Graveyard :: RIL, defect)

Description

[Guo Hailin]

Attachment: logslaposte.7z

User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; Zune 4.7; TCO_20140626094420; BOIE9;ZHCN; SE 2.X MetaSr 1.0)

Steps to reproduce:

1. Insert a simcard from operator lapostewith imsi 208107588064498, this sim card with EF_SPN " La Poste Mobile ", which we use to find the appropricate APN settings for it.
2. Restart the DUT, in b2g_telephony, QCContentHelper.js, we do not receive the message RIL:MatchMvno'.



Actual results:

We do not receive RIL:MatchMvno, and a wrong apn "SFR webphone" is selected. 


Expected results:

We have receive RIL:MatchMvno and choose the right apn with spn, and apn "WEB La Poste Mobile" is selected in apn settings UI.

Comment 1

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Ken -

Could you find someone to take a look at this one?

Thanks

Comment 2

[Guo Hailin]

Attachment: apn.json

apn settings in the build, pay attention to mccmn = 20810, which we test it

Comment 3

[Ken Chang[:kenkai]]

Vance, because this bug happens on commercial RIL, I wonder if you could ask partner to check it first.

Comment 4

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Anshul, per Comment#3, could you help to check this one first?

Comment 5

[Anshul]

Please file an SR.

Comment 6

[Guo Hailin]

(In reply to Anshul from comment #5)
> Please file an SR.

It seems that this call initiated from  Operator_variant.js (gaia\apps\system\js\operator_variant).   
filterApnsByMvnoRules 
var request = iccCard.matchMvno(listMvnoType, listMvnoMatchData);

Please have a check.
Also I will file an SR to Qualcomm, thanks.

Comment 7

[Guo Hailin]

And this issue happens occationally, not always, it can happen easilly when card switch from one sim card to another who have the same MCC MNC.

Comment 8

[pgravel]

As noted by the reporter, the issue seems to be that RIL:MatchMVNO is simply not called.

I'm not overly familiar with this piece of code, but it seems like this the intended behavior is to have RIL:MatchMVNO only when there is no persistent data available. see: https://github.com/mozilla-b2g/gaia/blob/v1.3/apps/system/js/operator_variant/operator_variant.js#L112
filterApnsByMvnoRules() is not called on subsequent boots since there is persistent data found. operator_variant.js simply uses the existing apn list rather than matching apn by mvno, so RIL:MatchMVNO never gets called, and the proper apn is not automatically selected.

Ken - could you verify my initial analysis? This seems to be more of an behavior issue in gaia's operator_variant.js than in telephony code.

Comment 9

[Ken Chang[:kenkai]]

Arthur is a expert for this part. ni?arthur.

Jessica, I wonder if bug 1013153 is also relevant to this bug.

Comment 10

[Jessica Jong [:jessica] (inactive)]

(In reply to Ken Chang[:ken] from comment #9)
> Arthur is a expert for this part. ni?arthur.
> 
> Jessica, I wonder if bug 1013153 is also relevant to this bug.

Checking on apn.json, 'WEB La Poste Mobile' uses mvno_type 'gid' [1] to find the matching apn. Bug 1013153 is adding support for mvno_type 'spn', so I think it doesn't help much in this case. I am not sure if qcril handles this correctly.

Nevertheless, we still need gaia's help to check why RIL:MatchMVNO was not called.


[1] https://github.com/mozilla-b2g/gaia/blob/v1.3/shared/resources/apn.json#L103

Comment 11

[Arthur Chen [:arthurcc][inactive after 6/30]]

Note that in the end of "applyOperatorVariantSettings" we call to "filterApnsByMvnoRules" [1], which means that no matter the persistent data is available or not, we always filter apns by mvno rules.

If the newly inserted sim card has the same mcc/mnc as the previous card, we won't apply new apn settings as it seems unnecessary. Not sure if there are exceptions for mvno things.

Jose, any ideas on this bug?

[1]: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/operator_variant/operator_variant.js#L364

Comment 12

[Guo Hailin]

I think you should use imsi instead of mcc+mnc. Because of MVNOs, there are many cases that different operator has sim cards with same mcc+mnc.

(In reply to Arthur Chen [:arthurcc] from comment #11)
> Note that in the end of "applyOperatorVariantSettings" we call to
> "filterApnsByMvnoRules" [1], which means that no matter the persistent data
> is available or not, we always filter apns by mvno rules.
> 
> If the newly inserted sim card has the same mcc/mnc as the previous card, we
> won't apply new apn settings as it seems unnecessary. Not sure if there are
> exceptions for mvno things.
> 
> Jose, any ideas on this bug?
> 
> [1]:
> https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/
> operator_variant/operator_variant.js#L364

Comment 13

[José Antonio Olivera Ortega [:jaoo]]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #10)
> (In reply to Ken Chang[:ken] from comment #9)
> > Arthur is a expert for this part. ni?arthur.
> > 
> > Jessica, I wonder if bug 1013153 is also relevant to this bug.
> 
> Checking on apn.json, 'WEB La Poste Mobile' uses mvno_type 'gid' [1] to find
> the matching apn. Bug 1013153 is adding support for mvno_type 'spn', so I
> think it doesn't help much in this case. I am not sure if qcril handles this
> correctly.

IIRC RIL:MatchMVNO was added to both MOZ and QC RIL in v1.3 release and It was working correctly. Note the RIL:MatchMVNO v1.3 version filtered APNs relaying on the IMSI code in the ICC card.  

As none of the APNs for the MCC MNC codes 20810 (see [1]) have the 'mvno_type' property equal to
'imsi' the filterApnsByMvnoRules() function will return the whole list of APNs for the MCC MNC codes
in the ICC card.

> Nevertheless, we still need gaia's help to check why RIL:MatchMVNO was not
> called.

Moreover the filterApnsByMvnoRules() function is always called when a new ICC card is seen. We call a
'new ICC card' to an ICC card whose MCC MNC codes change so If you insert a ICC card with the same
values for the MCC MNC codes the whole Operator Variant logic won't run again and filterApnsByMvnoRules() function won't be called.

> [1]
> https://github.com/mozilla-b2g/gaia/blob/v1.3/shared/resources/apn.json#L103

(In reply to Arthur Chen [:arthurcc] from comment #11)
> Note that in the end of "applyOperatorVariantSettings" we call to
> "filterApnsByMvnoRules" [1], which means that no matter the persistent data
> is available or not, we always filter apns by mvno rules.
> 
> If the newly inserted sim card has the same mcc/mnc as the previous card, we
> won't apply new apn settings as it seems unnecessary.

That's what we do right now.

> Not sure if there are
> exceptions for mvno things.

Well It seems that we should run the APNs selection again when a new ICC card is seen. For now on we should call 'a new ICC card' if the MCC MNC codes and the ICCID values change.

Comment 14

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

> 
> Well It seems that we should run the APNs selection again when a new ICC
> card is seen. For now on we should call 'a new ICC card' if the MCC MNC
> codes and the ICCID values change.

Hi Arthur, 

Is it possible you can help to make a patch based on Jose's suggestion such that partner can help to verify?

Thanks

Vance

Comment 15

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: PR against v1.3

As the bug was reported on the v1.3 branch so I created a PR against it. Once the patch was verified on the device, I'll create a PR against master.

Jose, would you mind take a look at this patch? Thanks!

Comment 16

[José Antonio Olivera Ortega [:jaoo]]

Comment on attachment 8451495 [details]
PR against v1.3

Thanks for the patch. Tested on master and it works fine. We will need to touch a bit the unit tests though.

Comment 17

[Jessica Jong [:jessica] (inactive)]

Just letting you know that we are working on mvno type gid in matchMvno() in Bug 1033142.

Comment 18

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: PR against master

Jose, I've added unit test for this case. Would you mind review the patch again? Thanks.

Comment 19

[Beatriz Rodríguez [:brg]]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #17)
> Just letting you know that we are working on mvno type gid in matchMvno() in
> Bug 1033142.

Jessica, is there any similar bug for adding "mvno_type":"spn"? Thanks in advance.

Comment 20

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Beatriz Rodríguez [:brg] from comment #19)
> (In reply to Jessica Jong [:jjong] [:jessica] from comment #17)
> > Just letting you know that we are working on mvno type gid in matchMvno() in
> > Bug 1033142.
> 
> Jessica, is there any similar bug for adding "mvno_type":"spn"? Thanks in
> advance.

I could answer: bug 1013153

Comment 21

[José Antonio Olivera Ortega [:jaoo]]

Comment on attachment 8456711 [details]
PR against master

LGTM. r=me

I have tested this with different ICC card with same MCC MNC values but different ICC ID values. It works correctly and it seem nothing gets broken. Thank you very much Arthur for taking care of it.

If this is going to land on v1.3 branch eventually please attach a PR against that branch. If travis goes green land at will. Thanks!

Comment 22

[Arthur Chen [:arthurcc][inactive after 6/30]]

Hailin, please request for approval if you think the patch should land on v1.3, thanks.

Comment 23

[Arthur Chen [:arthurcc][inactive after 6/30]]

Thanks for reviewing, Jose.

master: 6c85ca2112b45b27b3c4a167de19b0d1d96857ec