If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

B2G RIL: Number of PLMN entries to read

RESOLVED FIXED

Status

Firefox OS
General
RESOLVED FIXED
5 years ago
4 years ago

People

(Reporter: gerard, Assigned: kk1fff)

Tracking

unspecified
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-basecamp:+, firefox19 fixed, firefox20 fixed, b2g18 fixed)

Details

Attachments

(1 attachment, 3 obsolete attachments)

(Reporter)

Description

5 years ago
Bug 793111 introduced PLMN entries reading, taking as argument the number of entries to read. According to the current codebase, I can see the argument is tlvLen/6. As far as I remember, I had the same tlvLen value, but did divide it by 3. I see no justification but the /6, and running tests on my system (Free Mobile SIM card, Nexus S), I get:

with /6:
$ adb logcat | egrep -i "readPLMN"
I/Gecko   (   77): RIL Worker: readPLMNEntries: PLMN entries length = 1
I/Gecko   (   77): RIL Worker: readPLMNEntries: Reading PLMN entry: [0]: '2,248,16'
I/Gecko   (   77): RIL Worker: readPLMNEntries: PLMN = 208, 1

with /3:
$ adb logcat | egrep -i "readPLMN"
I/Gecko   (   77): RIL Worker: readPLMNEntries: PLMN entries length = 2
I/Gecko   (   77): RIL Worker: readPLMNEntries: Reading PLMN entry: [0]: '2,248,16'
I/Gecko   (   77): RIL Worker: readPLMNEntries: PLMN = 208, 1
I/Gecko   (   77): RIL Worker: readPLMNEntries: Reading PLMN entry: [1]: '2,248,32'
I/Gecko   (   77): RIL Worker: readPLMNEntries: PLMN = 208, 2

with /2:

$ adb logcat | egrep -i "readPLMN"
I/Gecko   (   77): RIL Worker: readPLMNEntries: PLMN entries length = 2
I/Gecko   (   77): RIL Worker: readPLMNEntries: Reading PLMN entry: [0]: '2,248,16'
I/Gecko   (   77): RIL Worker: readPLMNEntries: PLMN = 208, 1
I/Gecko   (   77): RIL Worker: readPLMNEntries: Reading PLMN entry: [1]: '2,248,32'
I/Gecko   (   77): RIL Worker: readPLMNEntries: PLMN = 208, 2
I/Gecko   (   77): RIL Worker: readPLMNEntries: Reading PLMN entry: [2]: '255,255,255'

Do you have spec/link suggesting/confirming the /6 value ? All I can find is ETSI spec, TS 131.102, section 4.2.66 which states:
"Note: the length is 3*n bytes, where n denotes the number of PLMN entries. The length can be coded on one or more bytes."
(Reporter)

Comment 1

5 years ago
And for your information, 20801 and 20802 are other valid assigned PLMN for Orange network in France, which Free is roaming on.
(Reporter)

Comment 2

5 years ago
Created attachment 690208 [details] [diff] [review]
Trivial fix

Works well on Free Mobile USIM card, and should comply to legacy SIM specifications (but no way for me to test).
(Reporter)

Comment 3

5 years ago
20801 is main Orange network identifier, and 20802 is a special one for zones with low coverage and specific multi-operator network to cover at lower cost.
Comment on attachment 690208 [details] [diff] [review]
Trivial fix

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

I think you're right, and we'll still need more test case for this. Please don't check-in now.
Attachment #690208 - Flags: review+
Summary: Number of PLMN entries to read → B2G RIL: Number of PLMN entries to read
Created attachment 691754 [details] [review]
Pull request: change in emulator

Adding EF_SPDI file, which contains an SPDI TLV (tag: A3) and an Service Provider PLMN List TLV that contains 2 entries: 234136 and 46692.
Assignee: nobody → pwang
Attachment #691754 - Flags: review?(vyang)
Created attachment 691759 [details] [diff] [review]
Patch: Add marionette test for EF_SPDI
Attachment #691759 - Flags: review?(vyang)
(Assignee)

Updated

5 years ago
Depends on: 819786, 819784
Comment on attachment 691754 [details] [review]
Pull request: change in emulator

Please changes comments of EF_SPDI as well.
Attachment #691754 - Flags: review?(vyang)
Attachment #691759 - Flags: review?(vyang) → review+
No longer depends on: 819786
Duplicate of this bug: 819786
No longer depends on: 819784
Duplicate of this bug: 819784
Blocks: 816893
Created attachment 692191 [details] [diff] [review]
Patch

Merged fix from bug 819786 and bug 819784.
Attachment #690208 - Attachment is obsolete: true
Attachment #691754 - Attachment is obsolete: true
Attachment #691759 - Attachment is obsolete: true
Attachment #692191 - Flags: review?(vyang)
(Assignee)

Updated

5 years ago
Blocks: 821605
Comment on attachment 692191 [details] [diff] [review]
Patch

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

Great!
Attachment #692191 - Flags: review?(vyang) → review+
BB? for bug 819786 and bug 819784 are both bb+.
blocking-basecamp: --- → ?
https://hg.mozilla.org/integration/mozilla-inbound/rev/d72d915e308b
https://hg.mozilla.org/mozilla-central/rev/d72d915e308b
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(In reply to Vicamo Yang [:vicamo][:vyang] from comment #12)
> BB? for bug 819786 and bug 819784 are both bb+.

Yep, this is a blocker for that reason.
blocking-basecamp: ? → +
https://hg.mozilla.org/releases/mozilla-aurora/rev/a3f1771e71c9
https://hg.mozilla.org/releases/mozilla-b2g18/rev/0d0c852fc724
status-b2g18: --- → fixed
status-firefox19: --- → fixed
status-firefox20: --- → fixed
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.