Closed Bug 968092 Opened 7 years ago Closed 7 years ago

APN Settings: parse apn type 'dun' and 'ims' from apn.json database

Categories

(Firefox OS Graveyard :: Gaia::Settings, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
1.4 S2 (28feb)

People

(Reporter: jessica, Assigned: jaoo)

References

Details

(Whiteboard: [FT:RIL])

Attachments

(3 files, 1 obsolete file)

APNs for dun and ims need to be parsed from the database and passed to gecko through 'ril.data.apnSettings', just like the other apn types.
These apn types are needed for 1.4 features.
See Also: → 969298
Blocks: b2g-LTE-1.4
It is a 1.4+ bug.
blocking-b2g: --- → 1.4+
Assignee: nobody → josea.olivera
Attached patch v1 (obsolete) — Splinter Review
This simple patch allows the operator variant logic to set the APNs for 'tun' and 'ims' types on boot. These APNs will be passed to the RIL plumbing through the 'ril.data.apnSettings'.

Jessica, I guess this patch will be useful for you while testing the logic you are adding to the RIL plumbing for handling these APNs. May I know what operator numeric value (MCC and MNC codes) has the ICC card you will test with?

Note: this patch doesn't provide the bits the setting app needs to show the panels for selecting the APNs of these new types. Bug 969298 will take care of it.
Thank you, José.

I have applied your patch and modified apn.json under shared/resources/ (added apns for type dun/ims) for testing, but after flashing gaia I still don't see the new apns coming in ril.data.apnSettings, am I missing anything? Does it read from apn.json everytime?

The MCC-MNC that I use for testing is 466-92.
(In reply to Jessica Jong [:jjong] [:jessica] from comment #4)

Jessica, I've used this patch for testing. It adds 'ims' and 'dun' APN types for the existing APN for internet. Moreover I've forced the operator variant logic to select the APNs for the ICC card you are using.

I see the 'ril.data.apnSettings' holding the APNs for types 'ims' and 'dun'.

I/Gecko   (  792): -*- RadioInterface[0]: 'ril.data.apnSettings' is now [[{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["default"]},{"carrier":"中華電信(Chunghwa) (MMS)","apn":"emome","mmsc":"http://mms.emome.net:8002","mmsproxy":"10.1.1.1","mmsport":"8080","types":["mms"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["supl"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["dun"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["ims"]}],[]]
I/Gecko   (  792): -*- RadioInterface[0]: setupApnSettings: [{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["default"]},{"carrier":"中華電信(Chunghwa) (MMS)","apn":"emome","mmsc":"http://mms.emome.net:8002","mmsproxy":"10.1.1.1","mmsport":"8080","types":["mms"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["supl"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["dun"]},{"carrier":"中華電信(Chunghwa) (Internet)","apn":"internet","types":["ims"]}]

> I have applied your patch and modified apn.json under shared/resources/
> (added apns for type dun/ims) for testing, but after flashing gaia I still
> don't see the new apns coming in ril.data.apnSettings, am I missing
> anything? 

You just need to apply the patch and reinstall gaia as follow:

|make reset-gaia|

> Does it read from apn.json everytime?

No, it does not. The 'ril.data.apnSettings' get populated every time a new ICC card is inserted.
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #5)
> Created attachment 8373223 [details] [diff] [review]
> Patch for testing
> 
> (In reply to Jessica Jong [:jjong] [:jessica] from comment #4)
> 
> Jessica, I've used this patch for testing. It adds 'ims' and 'dun' APN types
> for the existing APN for internet. Moreover I've forced the operator variant
> logic to select the APNs for the ICC card you are using.
> 
> I see the 'ril.data.apnSettings' holding the APNs for types 'ims' and 'dun'.
> 
> I/Gecko   (  792): -*- RadioInterface[0]: 'ril.data.apnSettings' is now
> [[{"carrier":"中華電信(Chunghwa)
> (Internet)","apn":"internet","types":["default"]},{"carrier":"中華電信(Chunghwa)
> (MMS)","apn":"emome","mmsc":"http://mms.emome.net:8002","mmsproxy":"10.1.1.
> 1","mmsport":"8080","types":["mms"]},{"carrier":"中華電信(Chunghwa)
> (Internet)","apn":"internet","types":["supl"]},{"carrier":"中華電信(Chunghwa)
> (Internet)","apn":"internet","types":["dun"]},{"carrier":"中華電信(Chunghwa)
> (Internet)","apn":"internet","types":["ims"]}],[]]
> I/Gecko   (  792): -*- RadioInterface[0]: setupApnSettings:
> [{"carrier":"中華電信(Chunghwa)
> (Internet)","apn":"internet","types":["default"]},{"carrier":"中華電信(Chunghwa)
> (MMS)","apn":"emome","mmsc":"http://mms.emome.net:8002","mmsproxy":"10.1.1.
> 1","mmsport":"8080","types":["mms"]},{"carrier":"中華電信(Chunghwa)
> (Internet)","apn":"internet","types":["supl"]},{"carrier":"中華電信(Chunghwa)
> (Internet)","apn":"internet","types":["dun"]},{"carrier":"中華電信(Chunghwa)
> (Internet)","apn":"internet","types":["ims"]}]
> 
> > I have applied your patch and modified apn.json under shared/resources/
> > (added apns for type dun/ims) for testing, but after flashing gaia I still
> > don't see the new apns coming in ril.data.apnSettings, am I missing
> > anything? 
> 
> You just need to apply the patch and reinstall gaia as follow:
> 
> |make reset-gaia|
> 
> > Does it read from apn.json everytime?
> 
> No, it does not. The 'ril.data.apnSettings' get populated every time a new
> ICC card is inserted.

Oh, that's why. I am having some problems using 'make reset-gaia', so I just used './flash gaia'.
After switching SIM cards, I can get the 'ims' and 'dun' apns, thank you.
(In reply to Jessica Jong [:jjong] [:jessica] from comment #6)
> Oh, that's why. I am having some problems using 'make reset-gaia', so I just
> used './flash gaia'.
> After switching SIM cards, I can get the 'ims' and 'dun' apns, thank you.

Glad it worked. I'll keep an eye and land this bug once both 960865 and 961571 bugs land.
blocking-b2g: 1.4+ → backlog
Whiteboard: [FT:RIL]
Target Milestone: --- → 1.4 S3 (14mar)
José, do you think we can land this before bug 960865 and 961571? gecko can store the new apns and decide what to do with them later, cause just having the new apn might be enough in some cases. Thanks.
The target milestone is too late. I have changed it to 2/28. It is impossible date. Please let me know.
Target Milestone: 1.4 S3 (14mar) → 1.4 S2 (28feb)
(In reply to Ken Chang[:ken] from comment #9)
> ..... It is impossible date. Please let me know.
Sorry for this wrong sentence. What I mean is "If it is impossible to finish it before 2/28, please let me know.".
Attached patch v2Splinter Review
Fabien, the patch here allows the operation variant logic to store 'dun' and 'ims' APNs into the database. I've added some bits to cover the change/addition with the existing unit tests. Could you please take a look a it please? Thanks!
Attachment #8372226 - Attachment is obsolete: true
Attachment #8377559 - Flags: review?(kaze)
(In reply to Ken Chang[:ken] from comment #10)
> (In reply to Ken Chang[:ken] from comment #9)
> > ..... It is impossible date. Please let me know.
> Sorry for this wrong sentence. What I mean is "If it is impossible to finish
> it before 2/28, please let me know.".

Nope, I guess it possible to finish it. Actually I was waiting bugs 960865 and 961571 to land before landing this bug.
Comment on attachment 8377559 [details] [diff] [review]
v2

LGTM
Attachment #8377559 - Flags: review?(kaze) → review+
The patch in this bug is ready to land, however it's not 1.4+ yet. As bug 952026 is part of the list in [1] I'm wondering if this bug could be 1.4+ and landed in master.

[1] https://wiki.mozilla.org/B2G/Roadmap#Key_Focus_1.4_Features
Flags: needinfo?(whuang)
Flags: needinfo?(kchang)
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #14)
> The patch in this bug is ready to land, however it's not 1.4+ yet. As bug
> 952026 is part of the list in [1] I'm wondering if this bug could be 1.4+
> and landed in master.
> 
> [1] https://wiki.mozilla.org/B2G/Roadmap#Key_Focus_1.4_Features

It is. It blocks bug 952026 which is one of the Key_Focus_1.4_Features.
Flags: needinfo?(kchang)
(In reply to Ken Chang[:ken] from comment #15)

> It is. It blocks bug 952026 which is one of the Key_Focus_1.4_Features.

Thanks, should I wait to land it until it becomes 1.4+ or could I land it directly?
Flags: needinfo?(kchang)
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #16)
> (In reply to Ken Chang[:ken] from comment #15)
> 
> > It is. It blocks bug 952026 which is one of the Key_Focus_1.4_Features.
> 
> Thanks, should I wait to land it until it becomes 1.4+ or could I land it
> directly?

Partner asks to have some bugs landed before 2/28. Bug 952026 is one of these bugs. So yes, it would be great if you can land it directly. Moreover, as I know "now"(I am not sure if it would change afterwords.), we don't use 1.4+ for features, even it is a key feature.
blocking-b2g: backlog → 1.4+
Flags: needinfo?(kchang)
blocking-b2g: 1.4+ → ---
Flags: needinfo?(whuang)
Test passes, everything seems to work correctly and travis went green. Landing then on Gaia master branch at https://github.com/mozilla-b2g/gaia/commit/16767eb7ed284bc89604aa00be145ef67343f0bc
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.