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.

Please ask customer to provide us log first, I can not do anything before having log.

[Blocking Requested - why for this release]:

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

(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.

Please see bug #1051664 comment #2.

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.

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.))

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; }

Try server is closed, wait for try green first.

try is green - https://tbpl.mozilla.org/?tree=Try&rev=1d48a84cd3a2

try on 1.4 also shows green - https://tbpl.mozilla.org/?tree=Try&rev=ac9925c243e7

https://hg.mozilla.org/integration/b2g-inbound/rev/bab1850daf34 https://hg.mozilla.org/integration/b2g-inbound/rev/909bb2d4da56

Not enough information with current STR to write test case to address bug.

https://hg.mozilla.org/mozilla-central/rev/bab1850daf34 https://hg.mozilla.org/mozilla-central/rev/909bb2d4da56

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/

Hi shawn, Please help land it to 1.3T. Thanks!

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.

Dear wayne, Please help add the flag 1.3t for landing the change to FFOS 1.3t. Thanks!

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!

(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!

1.3t patch is ready, see Comment 36. Please let me know if any problem/concern you have.

(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.

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.

2.0m needs this patch too, will provide rebased patch soon.

try green for 2.0m - https://tbpl.mozilla.org/?tree=Try&rev=a690e8ccaeb7

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

Hi Shawn, partner uploaded new log. https://bugzilla.mozilla.org/attachment.cgi?id=8529998 Could you check again? Thanks!

(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".

Hi Shawn, It's bug 1087914. Thanks!

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

Hi Shawn, Will inform partner. Thanks!