Closed Bug 1003023 Opened 10 years ago Closed 10 years ago

[Sora] OMA CP - Parse provisioning document correctly

Categories

(Firefox OS Graveyard :: Gaia::Wappush, defect, P1)

defect

Tracking

(blocking-b2g:1.3+, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

RESOLVED FIXED
2.0 S1 (9may)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: sync-1, Assigned: jaoo)

References

()

Details

(Whiteboard: [cert])

Attachments

(4 files, 1 obsolete file)

Firefox OS v1.3
 Mozilla build ID:20140422024003
 
 Created an attachment (id=727282)
 Images of OMA CP message presentation on DUT.
 
 DEFECT DESCRIPTION:
 After receiving an OMA CP message, the message cannot be installed. Clicking on the button to accept the OMA CP message does not have any effect. There seems to be no reaction also after minutes of waiting.
 
 
 
  REPRODUCING PROCEDURES:
 The device was tested using a Telekom.de SIM card. OMA CP messages were sent to the device using TMO's VQG test platform:
 Link:	http://tiv-dmz.homeip.net	
 User:	VQGTester	
 Password:	VQG8017
 Only German or UK SIM cards can be used.
 
 1. Send an OMA CP message to the device from VQG test platform. The messages can be found following the path VQG->RDM; Select "0:	RDM.01 - Internet Profile" for instance and select "Send"; Make sure MSISDN and IMSI are set correctly.
 2. Receive the OMA CP message on the DUT. Select the message from the pull down menu.
 3. Select "Accept" on the next page.
 -> there is no reaction, The OMA CP profile is not installed.
 
 Please have a look at the screenshots attached.
 
  EXPECTED BEHAVIOUR:
 OMA CP message are received and can be used successfully.
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 No easy device configuration via OMA CP.
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
blocking-b2g: --- → 1.3?
Is it Wap-Push related?
Component: Gaia::SMS → Gaia::Wappush
(In reply to Julien Wajsberg [:julienw] from comment #2)
> Is it Wap-Push related?

Yep, as the WAP PUSH app handles OMA client provisioning messages.

The comment #0 doesn't give much information to figure out what is going on. What is the security mechanism used to authenticate the server? I guess it is NETWPIN, is that correct? If you click on the accept button and the server cannot be authenticated the app shows a message informing about the error. If no alert messages are shown everything is ok and the user would see the APN name to store.

Please provide the provisioning document (XML) you guys are sending to the device and as many details as possible such as the authentication mechanism in use.
I used OTA PIN Type as "User PIN“, OTA PIN as "1234", but it is still filled to install and prompt a invalid vpn info.
Attached file RDM.zip
Please check the xml file you need.
(In reply to 田旻 from comment #4)
> I used OTA PIN Type as "User PIN“, OTA PIN as "1234", but it is still filled
> to install and prompt a invalid vpn info.

Hmm, If you setup the tool you are using correctly and select USERPIN as authentication mechanism you should be prompted to enter the PIN once the user opens the notification. As I see in the pics you attached you are not prompted to enter the USER PIN so I guess you are not setting up USERPIN as authentication mechanism in the tool correctly.

On the other hand I recommend you to test with an eng build and provide some logs. We dump the message and that will help to to figure out what you are sending to the device.
(In reply to 田旻 from comment #5)
> Created attachment 8414352 [details]
> RDM.zip
> 
> Please check the xml file you need.

Thanks. Sadly it doesn't provide any further help as the three files are equal. As I see you use the same file and just change the authentication mechanism in your tests.
NI, on :mvines to confirm this is not a RIL specific issue ?
Flags: needinfo?(mvines)
Flags: needinfo?(mvines) → needinfo?(anshulj)
Bevis, could you check if this issue is similar to bug 991445?
Flags: needinfo?(anshulj) → needinfo?(btseng)
(In reply to Anshul from comment #9)
> Bevis, could you check if this issue is similar to bug 991445?

No, bug 991445 is about decoding the wbxml inside the wappush in gecko which prevents gaia to display the CP message correctly.
For this issue, we might need gaia's help to clarify why the settings are not able to be applied to see if there is other information missed.
Flags: needinfo?(btseng)
Vance - Is this a cert blocker for TCL?
Flags: needinfo?(vchen)
Yes this one is a cert blocker
Flags: needinfo?(vchen)
Jose - Can you take a look?
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(josea.olivera)
Whiteboard: [cert]
Flags: needinfo?(josea.olivera)
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #6)
> (In reply to 田旻 from comment #4)

> On the other hand I recommend you to test with an eng build and provide some
> logs. We dump the message and that will help to to figure out what you are
> sending to the device.

Could you provide the logs above please? Thanks.
Flags: needinfo?(sync-1)
Luckily I have an O2 Movistar Germany ICC card and I managed to send OMA CP messages. The messages reach the device correctly and there is an issue while parsing the provisioning document. The format of this document is slightly different that the ones seen for other carriers.

I'll take the bug and I'll try to provide a fix ASAP as right now I'm focused on Loop. If anyone else want to take the bug please feel free.
Assignee: nobody → josea.olivera
I'll go ahead and change the bug title to reflect what the issue is. The provisioning document sent by DT is slightly different that the ones seen for other carriers.
Flags: needinfo?(sync-1)
Summary: [Sora]OMA CP messages cannot be installed successfully → [Sora] OMA CP - Parse provisioning document correctly
Attached patch v1 (obsolete) — Splinter Review
Gabriele, this patch fixes the provisioning document parser as It needs a change in order to parse correctly the provisioning document sent by DT. I also added a unit test for it. Would you mind to review this patch please? Thanks.
Attachment #8415875 - Flags: review?(gsvelto)
It would be useful to apply the patch in this bug and try to pass all the OMA CP test. Would that be possible?
Flags: needinfo?(sync-1)
Comment on attachment 8415875 [details] [diff] [review]
v1

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

LGTM, thanks for dealing with this bug, I am swamped with other stuff and couldn't take it myself :(.
Attachment #8415875 - Flags: review?(gsvelto) → review+
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #18)
> Created attachment 8415875 [details] [diff] [review]
> v1
> 
> Gabriele, this patch fixes the provisioning document parser as It needs a
> change in order to parse correctly the provisioning document sent by DT. I
> also added a unit test for it. Would you mind to review this patch please?
> Thanks.

I use your patch in the code, but it dosen't work. I only set GPRS APN and Settings Name, use a  User Pin as "123456". When I received and input the right pin, it still tells me "The configuration message you received dose not have valid APNs" just as before.

This is xml file I used, very simply, just for a test. Please refer:

<wap-provisioningdoc><characteristic type="BOOTSTRAP"><parm name="NAME" value="China Unicom"/></characteristic><characteristic type="NAPDEF"><parm name="NAME" value="China Unicom"/><parm name="NAPID" value="China_Unicom_NAPID"/><parm name="BEARER" value="GSM-GPRS"/><parm name="NAP-ADDRESS" value="3gwap"/><parm name="NAP-ADDRTYPE" value="APN"/><parm name="INTERNET"/></characteristic></wap-provisioningdoc>
(In reply to 田旻 from comment #21)
> (In reply to José Antonio Olivera Ortega [:jaoo] from comment #18)
> > Created attachment 8415875 [details] [diff] [review]
> > v1
> > 
> > Gabriele, this patch fixes the provisioning document parser as It needs a
> > change in order to parse correctly the provisioning document sent by DT. I
> > also added a unit test for it. Would you mind to review this patch please?
> > Thanks.
> 
> I use your patch in the code, but it dosen't work. I only set GPRS APN and
> Settings Name, use a  User Pin as "123456". When I received and input the
> right pin, it still tells me "The configuration message you received dose
> not have valid APNs" just as before.
> 
> This is xml file I used, very simply, just for a test. Please refer:
> 
> <wap-provisioningdoc><characteristic type="BOOTSTRAP"><parm name="NAME"
> value="China Unicom"/></characteristic><characteristic type="NAPDEF"><parm
> name="NAME" value="China Unicom"/><parm name="NAPID"
> value="China_Unicom_NAPID"/><parm name="BEARER" value="GSM-GPRS"/><parm
> name="NAP-ADDRESS" value="3gwap"/><parm name="NAP-ADDRTYPE"
> value="APN"/><parm name="INTERNET"/></characteristic></wap-provisioningdoc>

This provisioning document is invalid as it doesn't have APPLICATION nodes so the message you see in the screen is correct. I tested the patch with the DT platform and I was able to send the message and install the APN in the provisioning document it sends (it includes APPLICATION nodes).
Dear  José Antonio Olivera Ortega ,

What'a APPLICATION node? Why our OMA CP push message must have a APPLICATION node? Dose other system also need this kind of APPLICATION node? 

I am waiting for your reply.
Many thanks.
TIAN Min
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #22)
> (In reply to 田旻 from comment #21)
> > (In reply to José Antonio Olivera Ortega [:jaoo] from comment #18)
> > > Created attachment 8415875 [details] [diff] [review]
> > > v1
> > > 
> > > Gabriele, this patch fixes the provisioning document parser as It needs a
> > > change in order to parse correctly the provisioning document sent by DT. I
> > > also added a unit test for it. Would you mind to review this patch please?
> > > Thanks.
> > 
> > I use your patch in the code, but it dosen't work. I only set GPRS APN and
> > Settings Name, use a  User Pin as "123456". When I received and input the
> > right pin, it still tells me "The configuration message you received dose
> > not have valid APNs" just as before.
> > 
> > This is xml file I used, very simply, just for a test. Please refer:
> > 
> > <wap-provisioningdoc><characteristic type="BOOTSTRAP"><parm name="NAME"
> > value="China Unicom"/></characteristic><characteristic type="NAPDEF"><parm
> > name="NAME" value="China Unicom"/><parm name="NAPID"
> > value="China_Unicom_NAPID"/><parm name="BEARER" value="GSM-GPRS"/><parm
> > name="NAP-ADDRESS" value="3gwap"/><parm name="NAP-ADDRTYPE"
> > value="APN"/><parm name="INTERNET"/></characteristic></wap-provisioningdoc>
> 
> This provisioning document is invalid as it doesn't have APPLICATION nodes
> so the message you see in the screen is correct. I tested the patch with the
> DT platform and I was able to send the message and install the APN in the
> provisioning document it sends (it includes APPLICATION nodes).

Yes, I think you're right. This patch can work well now. Many thanks for your strong support. But I still wondering why application node is a must requirement?
(In reply to 田旻 from comment #24)
> Yes, I think you're right. This patch can work well now. Many thanks for
> your strong support. But I still wondering why application node is a must
> requirement?

You could read the specs at [1]. Basically it is because through APPLICATION node we figure out what settings the provisioning document provides.

[1 http://technical.openmobilealliance.org/Technical/release_program/cp_v1_1.aspx]
(In reply to Gabriele Svelto [:gsvelto] from comment #20)
> LGTM, thanks for dealing with this bug, I am swamped with other stuff and
> couldn't take it myself :(.

Thanks for the review. I was about to land this and did a last test after rebasing and I found something fishy as It didn't happen before. The error I see is:

E/GeckoConsole( 1655): [JavaScript Error: "ReferenceError: WapPushManager is not defined" {file: "app://wappush.gaiamobile.org/js/startup.js" line: 8}]

I guess this is because the last change made in the WAP PUSH app. Could you guys have a look please? Thanks.
Flags: needinfo?(stas)
Flags: needinfo?(gsvelto)
I backed out patch from bug 1001453 locally and the issue is gone.
(In reply to José Antonio Olivera Ortega [:jaoo] from comment #27)
> I backed out patch from bug 1001453 locally and the issue is gone.

Awww, that's weird, I don't understand why this is failing. I'm traveling today but I'll try to have a look tomorrow or Monday at the latest. I'm leaving the needinfo for that.
Can you reproduce this bug without your patch? 

I guess it may be a trivial regression with ordering of js files in index.html - we reference WapPushManager defined in wappush.js from startup.js, but wappush.js is listed below startup.js.
(In reply to Zbigniew Braniecki [:gandalf] from comment #29)
> I guess it may be a trivial regression with ordering of js files in
> index.html - we reference WapPushManager defined in wappush.js from
> startup.js, but wappush.js is listed below startup.js.


Yes, indeed. I hadn't paid attention as before the code in startup.js wouldn't be executed before onload() and so the issue was not triggered. José could you move startup.js at the bottom of the JS sources as part of your patch so that we don't need a separate commit just for this small change? On a separate node it seems that we need to add at least an integration test to prevent this kind of issues from slipping through in the future.
Flags: needinfo?(gsvelto)
Attached patch v2. r=gsveltoSplinter Review
Land this as soon as Travis goes green.
Attachment #8415875 - Attachment is obsolete: true
Everything seems to work correctly, test pass and Travis went green. Landed in Gaia master branch at https://github.com/jaoo/gaia/commit/db3e788ecd059e4fb2ba61af6ca11bdc242adc8c

Thanks Gabriele!
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 8417051 [details] [diff] [review]
v2. r=gsvelto

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): OMA CP test for DT
[User impact] if declined: OMA CP messages sent by DT cannot be parsed correctly.
[Testing completed]: Yes, new test added.
[Risk to taking this patch] (and alternatives if risky): Low
[String changes made]: No changes.
Attachment #8417051 - Flags: approval-gaia-v1.3?(fabrice)
Attachment #8417051 - Flags: approval-gaia-v1.3?(fabrice) → approval-gaia-v1.3+
This patch works well. Thanks.
Flags: needinfo?(sync-1)
Target Milestone: --- → 2.0 S1 (9may)
(Clearing the needinfo on me as it looks like Zibi's comment 29 was the right clue.)
Flags: needinfo?(stas)
Flags: in-moztrap?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: