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)
Firefox OS Graveyard
Gaia::Wappush
Tracking
(blocking-b2g:1.3+, 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)
3.73 MB,
application/x-zip-compressed
|
Details | |
1.89 KB,
application/zip
|
Details | |
46 bytes,
text/x-github-pull-request
|
Details | Review | |
4.16 KB,
patch
|
fabrice
:
approval-gaia-v1.3+
|
Details | Diff | Splinter Review |
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:
Comment 2•10 years ago
|
||
Is it Wap-Push related?
Updated•10 years ago
|
Component: Gaia::SMS → Gaia::Wappush
Assignee | ||
Comment 3•10 years ago
|
||
(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.
Assignee | ||
Comment 6•10 years ago
|
||
(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.
Assignee | ||
Comment 7•10 years ago
|
||
(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.
Comment 8•10 years ago
|
||
NI, on :mvines to confirm this is not a RIL specific issue ?
Flags: needinfo?(mvines)
Updated•10 years ago
|
Flags: needinfo?(mvines) → needinfo?(anshulj)
Bevis, could you check if this issue is similar to bug 991445?
Flags: needinfo?(anshulj) → needinfo?(btseng)
Comment 10•10 years ago
|
||
(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)
Yes this one is a cert blocker
Flags: needinfo?(vchen)
Comment 13•10 years ago
|
||
Jose - Can you take a look?
blocking-b2g: 1.3? → 1.3+
Flags: needinfo?(josea.olivera)
Whiteboard: [cert]
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(josea.olivera)
Assignee | ||
Comment 14•10 years ago
|
||
(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)
Assignee | ||
Comment 15•10 years ago
|
||
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
Assignee | ||
Comment 16•10 years ago
|
||
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
Assignee | ||
Comment 17•10 years ago
|
||
Assignee | ||
Comment 18•10 years ago
|
||
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)
Assignee | ||
Comment 19•10 years ago
|
||
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 20•10 years ago
|
||
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+
Comment 21•10 years ago
|
||
(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>
Assignee | ||
Comment 22•10 years ago
|
||
(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).
Comment 23•10 years ago
|
||
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
Comment 24•10 years ago
|
||
(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?
Assignee | ||
Comment 25•10 years ago
|
||
(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]
Assignee | ||
Comment 26•10 years ago
|
||
(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)
Assignee | ||
Comment 27•10 years ago
|
||
I backed out patch from bug 1001453 locally and the issue is gone.
Comment 28•10 years ago
|
||
(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.
Comment 29•10 years ago
|
||
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.
Comment 30•10 years ago
|
||
(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)
Assignee | ||
Comment 31•10 years ago
|
||
Land this as soon as Travis goes green.
Attachment #8415875 -
Attachment is obsolete: true
Assignee | ||
Comment 32•10 years ago
|
||
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!
Assignee | ||
Updated•10 years ago
|
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 33•10 years ago
|
||
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)
Updated•10 years ago
|
Attachment #8417051 -
Flags: approval-gaia-v1.3?(fabrice) → approval-gaia-v1.3+
Comment 34•10 years ago
|
||
This patch works well. Thanks.
Updated•10 years ago
|
status-b2g-v2.0:
--- → fixed
Target Milestone: --- → 2.0 S1 (9may)
Assignee | ||
Updated•10 years ago
|
status-b2g-v1.3:
--- → affected
status-b2g-v1.4:
--- → affected
Comment 35•10 years ago
|
||
(Clearing the needinfo on me as it looks like Zibi's comment 29 was the right clue.)
Flags: needinfo?(stas)
Comment 36•10 years ago
|
||
v1.4: https://github.com/mozilla-b2g/gaia/commit/cacf9065aaedd854245766f968ad7cf6b086ea44 v1.3: https://github.com/mozilla-b2g/gaia/commit/0d02564946814acfdab13f0b9867d140d318b8ac
status-b2g-v1.3T:
--- → affected
Updated•10 years ago
|
Updated•10 years ago
|
Flags: in-moztrap?
Updated•10 years ago
|
Flags: in-moztrap? → in-moztrap+
You need to log in
before you can comment on or make changes to this bug.
Description
•