Closed Bug 1046649 Opened 8 years ago Closed 7 years ago

B2G RIL: need to handle wild char for EF_OPL

Categories

(Firefox OS Graveyard :: RIL, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0M+, firefox32 wontfix, firefox33 wontfix, firefox34 fixed, b2g-v1.4 fixed, b2g-v2.0 wontfix, b2g-v2.0M fixed, b2g-v2.1 verified)

RESOLVED FIXED
2.1 S2 (15aug)
blocking-b2g 2.0M+
Tracking Status
firefox32 --- wontfix
firefox33 --- wontfix
firefox34 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- wontfix
b2g-v2.0M --- fixed
b2g-v2.1 --- verified

People

(Reporter: xianmao.meng, Assigned: sku)

References

()

Details

(Whiteboard: sprd Bug 338295)

Attachments

(7 files, 8 obsolete files)

8.77 KB, patch
sku
: review+
Details | Diff | Splinter Review
5.54 KB, patch
sku
: review+
Details | Diff | Splinter Review
14.01 KB, patch
sku
: review+
Details | Diff | Splinter Review
6.43 KB, patch
Details | Diff | Splinter Review
13.93 KB, patch
Details | Diff | Splinter Review
1.19 MB, text/plain
Details
1.73 MB, video/mp4
Details
For some USIM card,for example,china unicom,we can not get the operator name from usim card,and show the operator name from the network.
Flags: needinfo?(sku)
Whiteboard: sprd Bug 338295
Please ask customer to provide us log first, I can not do anything before having log.
Flags: needinfo?(sku)
Attached patch EONS.patch (obsolete) — Splinter Review
[Blocking Requested - why for this release]:
blocking-b2g: --- → 1.4?
Attachment #8470581 - Flags: review?(echen)
Assignee: nobody → sku
Attachment #8470716 - Flags: review?(echen)
Attachment #8470717 - Flags: review?(echen)
Comment on attachment 8470716 [details] [diff] [review]
[1.4] Bug 1046649 Part 1: RIL patch - [taroko][dolphin] fail to reed the operator name for some USIM card.

Review of attachment 8470716 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for your work.

Give r- because the matching logic seems wrong. :(

::: dom/system/gonk/ril_worker.js
@@ +13256,5 @@
>    /**
> +   * Check if operator name needs to be overriden after reading OPL and PNN.
> +   * See 3GPP TS 31.102 clause 4.2.58 and EFPNN 4.2.59 EFOPL for detail.
> +   */
> +  getICCNetworkName: function() {

The below codes is just copied from |_processOperator|, so please help to refactor |_processOperator| a bit to reuse this function.

@@ +13702,5 @@
>          let opl = iccInfoPriv.OPL[i];
> +        // Try to match the MCC/MNC. Besides, A BCD value of 'D' in any of the
> +        // MCC and/or MNC digits shall be used to indicate a "wild" value for
> +        // that corresponding MCC/MNC digit.
> +        if (opl.mcc.indexOf(GsmPDUHelper.bcdChars.charAt(0x0d)) !== -1) {

Cache the wild digit,

let wildDigits = GsmPDUHelper.bcdChars.charAt(0x0d);

And use |wildDigits| here and below.

@@ +13706,5 @@
> +        if (opl.mcc.indexOf(GsmPDUHelper.bcdChars.charAt(0x0d)) !== -1) {
> +          for (i = 0; i < opl.mcc.length; i++) {
> +            if (opl.mcc[i] !== GsmPDUHelper.bcdChars.charAt(0x0d) &&
> +                opl.mcc[i] !== mcc[i]) {
> +              continue;

The logic here seems wrong. You just iterate over mcc array.

@@ +13723,5 @@
> +        if (opl.mnc.indexOf(GsmPDUHelper.bcdChars.charAt(0x0d)) !== -1) {
> +          for (i = 0; i < opl.mnc.length; i++) {
> +            if (opl.mnc[i] !== GsmPDUHelper.bcdChars.charAt(0x0d) &&
> +                opl.mnc[i] !== mnc[i]) {
> +              continue;

Ditto
Attachment #8470716 - Flags: review?(echen) → review-
(In reply to Edgar Chen [:edgar][:echen] from comment #7)
> Comment on attachment 8470716 [details] [diff] [review]
> [1.4] Bug 1046649 Part 1: RIL patch - [taroko][dolphin] fail to reed the
> operator name for some USIM card.
> 
> Review of attachment 8470716 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Thanks for your work.
> 
> Give r- because the matching logic seems wrong. :(
> 
> ::: dom/system/gonk/ril_worker.js
> @@ +13256,5 @@
> >    /**
> > +   * Check if operator name needs to be overriden after reading OPL and PNN.
> > +   * See 3GPP TS 31.102 clause 4.2.58 and EFPNN 4.2.59 EFOPL for detail.
> > +   */
> > +  getICCNetworkName: function() {
> 
> The below codes is just copied from |_processOperator|, so please help to
> refactor |_processOperator| a bit to reuse this function.
> 
> @@ +13702,5 @@
> >          let opl = iccInfoPriv.OPL[i];
> > +        // Try to match the MCC/MNC. Besides, A BCD value of 'D' in any of the
> > +        // MCC and/or MNC digits shall be used to indicate a "wild" value for
> > +        // that corresponding MCC/MNC digit.
> > +        if (opl.mcc.indexOf(GsmPDUHelper.bcdChars.charAt(0x0d)) !== -1) {
> 
> Cache the wild digit,
> 
> let wildDigits = GsmPDUHelper.bcdChars.charAt(0x0d);
> 
> And use |wildDigits| here and below.
> 
> @@ +13706,5 @@
> > +        if (opl.mcc.indexOf(GsmPDUHelper.bcdChars.charAt(0x0d)) !== -1) {
> > +          for (i = 0; i < opl.mcc.length; i++) {
> > +            if (opl.mcc[i] !== GsmPDUHelper.bcdChars.charAt(0x0d) &&
> > +                opl.mcc[i] !== mcc[i]) {
> > +              continue;
> 
> The logic here seems wrong. You just iterate over mcc array.
> 
> @@ +13723,5 @@
> > +        if (opl.mnc.indexOf(GsmPDUHelper.bcdChars.charAt(0x0d)) !== -1) {
> > +          for (i = 0; i < opl.mnc.length; i++) {
> > +            if (opl.mnc[i] !== GsmPDUHelper.bcdChars.charAt(0x0d) &&
> > +                opl.mnc[i] !== mnc[i]) {
> > +              continue;
> 
> Ditto

Thanks Edgar, will address the defect in next patch.
Comment on attachment 8470717 [details] [diff] [review]
[1.4] Bug 1046649 Part 2: test patch - [taroko][dolphin] fail to reed the operator name for some USIM card.

Review of attachment 8470717 [details] [diff] [review]:
-----------------------------------------------------------------

Please help to add some tests for wild matching, thank you.
Attachment #8470717 - Flags: review?(echen)
Blocks: 1051664
Please see bug #1051664 comment #2.
Summary: [taroko][dolphin] fail to reed the operator name for some USIM card. → B2G RIL: need to handle wild char for EF_OPL
Attachment #8470716 - Attachment is obsolete: true
Attachment #8470717 - Attachment is obsolete: true
Attachment #8471347 - Flags: review?(echen)
Attachment #8471348 - Flags: review?(echen)
blocking-b2g: 1.4? → 1.4+
Comment on attachment 8471348 [details] [diff] [review]
Bug 1046649 Part 2: test patch - B2G RIL: need to handle wild char for EF_OPL.

Review of attachment 8471348 [details] [diff] [review]:
-----------------------------------------------------------------

Nice, thank you.
Attachment #8471348 - Flags: review?(echen) → review+
Comment on attachment 8471347 [details] [diff] [review]
Bug 1046649 Part 1: RIL patch - B2G RIL: need to handle wild char for EF_OPL. v2.

Review of attachment 8471347 [details] [diff] [review]:
-----------------------------------------------------------------

Please see my comments below, thank you.

::: dom/system/gonk/ril_worker.js
@@ +13690,5 @@
>        }
> +
> +      let networkName = this.getICCNetworkName();
> +      if (networkName) {
> +        RIL.operator.longName = networkName.fullName;

operator could be null.

@@ +13692,5 @@
> +      let networkName = this.getICCNetworkName();
> +      if (networkName) {
> +        RIL.operator.longName = networkName.fullName;
> +        RIL.operator.shortName = networkName.shortName;
> +        RIL._sendNetworkInfoMessage(NETWORK_INFO_OPERATOR, RIL.operator);

A function with '_' prefix is usually private.
I prefer don't call it from outside of 'RIL'.

@@ +13765,5 @@
>        }
> +
> +      let networkName = this.getICCNetworkName();
> +      if (networkName) {
> +        RIL.operator.longName = networkName.fullName;

ditto

@@ +13767,5 @@
> +      let networkName = this.getICCNetworkName();
> +      if (networkName) {
> +        RIL.operator.longName = networkName.fullName;
> +        RIL.operator.shortName = networkName.shortName;
> +        RIL._sendNetworkInfoMessage(NETWORK_INFO_OPERATOR, RIL.operator);

ditto

@@ +13784,5 @@
> +   * @return An object contains the overridden network name or null if not meet
> +   *         the criteria after matching current network status with EF_PNN
> +   *         and EF_OPL.
> +   */
> +  getICCNetworkName: function() {

Please move this helper function to 'RIL'.
((The helper function in 'SimRecordHelper' should do nothing more than read/write EF.))
Attachment #8471347 - Flags: review?(echen)
Attachment #8472046 - Flags: review?(echen)
Comment on attachment 8472046 [details] [diff] [review]
Bug 1046649 Part 1: RIL patch - B2G RIL: need to handle wild char for EF_OPL. v3.

Review of attachment 8472046 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good, thank you.

::: dom/system/gonk/ril_worker.js
@@ +1131,5 @@
> +    let ICCUtilsHelper = this.context.ICCUtilsHelper;
> +    // We won't get network name using PNN and OPL if voice registration isn't
> +    // ready.
> +    if (this.voiceRegistrationState.cell &&
> +        this.voiceRegistrationState.cell.gsmLocationAreaCode != -1) {

nit: bail out early.

if (!this.voiceRegistrationState.cell ||
    this.voiceRegistrationState.cell.gsmLocationAreaCode == -1) {
  return false;
}

@@ +1137,5 @@
> +        this.operator.mcc,
> +        this.operator.mnc,
> +        this.voiceRegistrationState.cell.gsmLocationAreaCode);
> +
> +      if (networkName) {

nit: bail out early.

if (!networkName) {
  return false;
}
Attachment #8472046 - Flags: review?(echen) → review+
Try server is closed, wait for try green first.
try on 1.4 also shows green - https://tbpl.mozilla.org/?tree=Try&rev=ac9925c243e7
Not enough information with current STR to write test case to address bug.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(rmitchell)
https://hg.mozilla.org/mozilla-central/rev/bab1850daf34
https://hg.mozilla.org/mozilla-central/rev/909bb2d4da56
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S2 (15aug)
https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/facfdefbbea1

I'm assuming that this is wontfix for v2.0. Please set the status back to affected and nominate whatever needs uplift for b2g32 approval if that's incorrect.
Test case added to moztrap:

https://moztrap.mozilla.org/manage/case/14379/
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(rmitchell)
Flags: in-moztrap+
Blocks: 1056449
Hi shawn,

Please help land it to 1.3T.

Thanks!
Flags: needinfo?(sku)
I can prepare 1.3t patch, but there is no 1.3t? any more. Might need parter to pick/apply the patch then.

Keep ni? flag until 1.3t patch is ready.
(In reply to shawn ku [:sku] from comment #29)
> I can prepare 1.3t patch, but there is no 1.3t? any more. Might need parter
> to pick/apply the patch then.
> 
> Keep ni? flag until 1.3t patch is ready.

Hi shawn,

I can not understand why "there is no 1.3t?",FFOS 1.3t is the tarako for sprd maintained by mozilla.
If I am wrong somewhere,please told me.

Thank you very much!
Project Flags: blocking-b2g

I mean above flag on Bugzilla.
We have to nominate 1.3t? first, and go triage procedure.
However, I cannot see 1.3t? anymore. That's why there is no way for me to request code check-in into 1.3t.
Flags: needinfo?(sku)
Dear wayne,

Please help add the flag 1.3t for landing the change to FFOS 1.3t.

Thanks!
Flags: needinfo?(wchang)
We're no longer taking fixes on 1.3t unless bugs are critical or need security fixes.

(In reply to 孟宪茂 from comment #32)
> Dear wayne,
> 
> Please help add the flag 1.3t for landing the change to FFOS 1.3t.
> 
> Thanks!
Flags: needinfo?(wchang)
(In reply to shawn ku [:sku] from comment #29)
> I can prepare 1.3t patch, but there is no 1.3t? any more. Might need parter
> to pick/apply the patch then.
> 
> Keep ni? flag until 1.3t patch is ready.

Dear shawn,

Please help prepare patch for 1.3t.

Thank you very much!
Flags: needinfo?(sku)
Attachment #8483242 - Flags: review+
Flags: needinfo?(sku)
Attachment #8483242 - Attachment is obsolete: true
1.3t patch is ready, see Comment 36. Please let me know if any problem/concern you have.
Flags: needinfo?(xianmao.meng)
(In reply to shawn ku [:sku] from comment #37)
> 1.3t patch is ready, see Comment 36. Please let me know if any
> problem/concern you have.

Hi shawn,

Thank you for your help.I will apply the patch and test the case.I will tell you the results later.
Thanks!
Hi shawn,

I used the Usim card test wild char in OPL,the written information is:

lacTacStart: 0, lacTacEnd: 0xFFFE
pnnRecordId :1
mcc: 209, mnc: DDD
fullName":"WILD","shortName":"wild"

The test PLMN network is 209 11,it still show operator name 20911.

From the log the info is write.
09-13 03:21:44.590    97   212 D AT      : Channel2: AT< +CRSM: 144,0,02D9DD0000FFFE01

But the mnc:DDD is decoded as ";;;":
08-19 03:21:45.200    85   320 I Gecko   : RIL Worker: [0] OPL: [1]: {"mcc":"209","mnc":";;;","lacTacStart":0,"lacTacEnd":65534,"pnnRecordId":1}
08-19 03:21:46.910    85    85 I Gecko   : -*- RILContentHelper: Received message 'RIL:IccInfoChanged': {"clientId":0,"data":{"iccType":"usim","iccid":"897010210051900001","rilMessageType":"iccinfochange","rilMessageClientId":0,"mcc":"209","mnc":"11"}}
08-19 03:28:40.460    85   320 I Gecko   : RIL Worker: [0] Queuing operator network info message: {"rilMessageType":"operatorchange","longName":"20911","shortName":"20911","mcc":"209","mnc":"11"}

Please help check.
Thank you very much.
Flags: needinfo?(xianmao.meng) → needinfo?(sku)
If EF_AD do not specific the length of MNC, and we do not have exception case for MNC length 3. Gecko will treat the length of 209 is 2.

That's why your result is failure.

Please make sure you did the test for real MCC/MNC case.
Flags: needinfo?(sku)
2.0m needs this patch too, will provide rebased patch soon.
blocking-b2g: 1.4+ → 2.0M?
blocking-b2g: 2.0M? → 2.0M+
Duplicate of this bug: 1087914
Blocks: Woodduck
This issue has been verified failed on Woodduck 2.0; but it is verified passed on Flame2.1.
Note:Verify it with Comment 27.
Reproducing rate: 5/5
Found time:15:38 around
See attachment: Verify_Woodduck_Operatorname.mp4,logcat_1538.txt
STRs:
1. Insert CMCC and CU SIM card.
2. Power on device and check the operator name in SIM manager/Call settings/Cellular&Data.

Actul Result:
The operator name is displayed as 46000/46001.
Expected Result:
The operator name should be displayed as "CMCC or UMICOM".

Woodduck build version:
Gaia-Rev        d742e375aca6dc1bf3a36638000ad7f5338ef457
Gecko-Rev       d049d4ef127844121c9cf14d2e8ca91fd9045fcb
Build-ID        20141127050313
Version         32.0

Flame2.1 build version:
Gaia-Rev        f9d6e3d83c3922e9399a6c27f5ce4cdd27bdfd05
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/45112935086f
Build-ID        20141126000203
Version         32.0
Flags: needinfo?(hlu)
Attached file logcat_1538.txt
Hi Shawn,
partner uploaded new log. 
https://bugzilla.mozilla.org/attachment.cgi?id=8529998
Could you check again? Thanks!
Flags: needinfo?(hlu) → needinfo?(sku)
(In reply to Josh Cheng [:josh] from comment #49)
> Hi Shawn,
> partner uploaded new log. 
> https://bugzilla.mozilla.org/attachment.cgi?id=8529998
> Could you check again? Thanks!

Josh, please let me know which log I need to check referring to "https://bugzilla.mozilla.org/attachment.cgi?id=8529998".
Flags: needinfo?(sku) → needinfo?(jocheng)
Hi Shawn,
It's bug 1087914. Thanks!
Flags: needinfo?(jocheng) → needinfo?(sku)
Hi Josh:
 For Bug 1087914, it was claimed as fixed per comment comment 4.

For the new log attached in this bug comment 49, the log shows everthing is normal.
There is no EFSPN (file ID not found), and show PLMN due to current status is as expectation.

Please ask partner to provide a new bug with more detail information if they think issue is still there.


11-27 00:05:39.116   538   547 D use-Rlog/RLOG-AT: AT> AT+CRSM=192,28486,0,0,15,,"7f20"
11-27 00:05:39.116   538   547 D use-Rlog/RLOG-AT: AT+CRSM=192,28486,0,0,15,,"7f20"
11-27 00:05:39.267   538   562 D use-Rlog/RLOG-AT: +CRSM: 148, 4
11-27 00:05:39.267   538   562 D use-Rlog/RLOG-AT: AT< +CRSM: 148, 4
11-27 00:05:39.267   538   547 D use-Rlog/RLOG-RIL: [simio]Null response
...
11-27 00:06:49.918   163   607 I Gecko   : RIL Worker: [0] isDisplayNetworkNameRequired = true
11-27 00:06:49.919   163   607 I Gecko   : RIL Worker: [0] isDisplaySpnRequired = false
11-27 00:06:50.000   163   163 E GeckoConsole: Content JS LOG at app://system.gaiamobile.org/js/operator_name.js:101 in sb_updateLabel: lxp:: operatorInfos.operator = PG.Pacific
11-27 00:06:50.839   885   885 I Gecko   : -*- RILContentHelper: Received message 'RIL:VoiceInfoChanged': {"clientId":0,"data":{"connected":true,"emergencyCallsOnly":false,"roaming":true,"network":{"longName":"31001","shortName":"31001","mcc":"310","mnc":"01"},"cell":{"gsmLocationAreaCode":1,"gsmCellId":1},"type":"gprs","signalStrength":-57,"relSignalStrength":100,"state":"registered"}}
11-27 00:06:50.857   163   163 E GeckoConsole: Content JS LOG at app://system.gaiamobile.org/js/operator_name.js:101 in sb_updateLabel: lxp:: operatorInfos.operator = PG.Pacific
Flags: needinfo?(sku) → needinfo?(jocheng)
Hi Shawn,
Will inform partner. Thanks!
Flags: needinfo?(jocheng)
You need to log in before you can comment on or make changes to this bug.