Closed
Bug 991445
Opened 10 years ago
Closed 10 years ago
[Sora]OMA CP messages are not processed
Categories
(Firefox OS Graveyard :: RIL, defect, P1)
Firefox OS Graveyard
RIL
Tracking
(blocking-b2g:1.3+, firefox29 wontfix, firefox30 fixed, firefox31 fixed, b2g-v1.3 fixed, b2g-v1.3T fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)
People
(Reporter: sync-1, Assigned: bevis)
References
Details
(Whiteboard: [cert])
Attachments
(6 files, 2 obsolete files)
4.31 MB,
application/x-zip-compressed
|
Details | |
19.12 KB,
application/zip
|
Details | |
4.32 MB,
application/zip
|
Details | |
4.62 KB,
patch
|
vicamo
:
review+
bajaj
:
approval-mozilla-b2g28+
|
Details | Diff | Splinter Review |
7.34 KB,
patch
|
vicamo
:
review+
bajaj
:
approval-mozilla-b2g28+
|
Details | Diff | Splinter Review |
27.15 KB,
patch
|
vicamo
:
review+
bajaj
:
approval-mozilla-b2g28+
|
Details | Diff | Splinter Review |
Firefox OS v1.3 Mozilla build ID:20140323004002 DEFECT DESCRIPTION: The device does not process OMA CP messages. There is no indication of the reception of an OMA CP message in the device UI. No icon, no ringtone. There is also no message in the inbox. REPRODUCING PROCEDURES: Precondition: German Telekom.de SIM card is inserted in the device. The device is registered to German Telekom.de network (262.01). 1. Use the VQG test platform to send an OMA CP message to the device 2. Log in and go to VQG->RDM 3. Select one link to send a message, e.g.0: RDM.01 - Internet Profile NOTE: this can only be used with a German TMO or a UK TMO SIM card. Check with different OMA CP messages. None was processed and could be used. They seemed to be just discarded. EXPECTED BEHAVIOUR: ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior:
Assignee | ||
Comment 2•10 years ago
|
||
The attachement only contains qxdm log. Need ril related logs enabled to see what happened.
Component: Gaia::SMS → RIL
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(sync-1)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → btseng
Assignee | ||
Comment 3•10 years ago
|
||
qawanted to see how this behaves in Moz RIL 1.3. If not working, please help to enable ril logs in adb logcat to see what really happened.
Keywords: qawanted
(In reply to Bevis Tseng [:bevistseng] (btseng@mozilla.com) from comment #2) > The attachement only contains qxdm log. > Need ril related logs enabled to see what happened. I will give you ril logs as soon as possible.
Assignee | ||
Comment 6•10 years ago
|
||
(In reply to buri.blff from comment #5) > Created attachment 8405973 [details] > 4019X_121+FG_OMA_CP_Message_20140411.zip > > Please test the log you need. Hi, From the log, I didn't even see any incoming SMS (UNSOLICITED_RESPONSE_NEW_SMS) received from RIL. That means there was no incoming messages representing OMA CP messages from the logs. :( Regards, Bevis Tseng
Assignee | ||
Comment 7•10 years ago
|
||
We didn't see any problem from gecko part. Need modem expert to check if there is any problem of receiving the SMS. or is the log correctly captured while receiving the OMA CP message?
Assignee: btseng → nobody
Assignee | ||
Comment 8•10 years ago
|
||
NI for questions in comment 7, since there is not much we can do in gecko side.
Flags: needinfo?(sync-1)
Comment 10•10 years ago
|
||
IIRC, OMA CP only supports USERPIN and NETWPIN security mechanism. If you are using any other: - no security, - USERNETWPIN (bug 928775) - USERPINMAC(supported but not tested --> feature disabled) Then the user will not see any message. Is this the situation?
Comment 11•10 years ago
|
||
Michael Wondering if this found on QC RIL. Please help with the investigation
Flags: needinfo?(mvines)
Comment 12•10 years ago
|
||
The SR system can be used for non-Mozilla support requests, thanks.
Flags: needinfo?(mvines)
Comment 13•10 years ago
|
||
As Bevis mentioned, from the logs I don't even see an unsol_new_sms message. Also, there was an issue with OMA CP sms parsing that we resolved in AU_LINUX_GECKO_B2G_JB_3.2.01.03.00.112.279. Please confirm if you are using this or a later AU. If you are, please file an SR and we will provide the necessary support.
Comment 14•10 years ago
|
||
(In reply to Michael Vines [:m1] [:evilmachines] from comment #12) > The SR system can be used for non-Mozilla support requests, thanks. Ok - reporter, please file a SR.
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Closed: 10 years ago
Resolution: --- → INCOMPLETE
Comment 16•10 years ago
|
||
Dear all, please find attached another set data regarding the OMA CP reception. It includes: - QXDM file - ADB log taken in parallel to the QXDM log - XML file showing the content of the OMA CP message Please note: these logs were taken using SW 124. The OMA CP message was sent from the TMO VQG test sever. Please note: this OMA CP message's authentication mechanism is the Network PIN. In the QXDM log you can see beginning at time stamp 14:40:36.380 the reception of the OMA CP message. So it is verified that the message has been sent out and was also received by the device. The question is what prevents the device from processing the message? On the device is there any kind of whitelist which could prevent the successful reception of an OMA CP message?
(In reply to liangxin from comment #16) > Created attachment 8409986 [details] > Soul35_124_OMACP_2010417.zip > > Dear all, > > please find attached another set data regarding the OMA CP reception. It > includes: > - QXDM file > - ADB log taken in parallel to the QXDM log > - XML file showing the content of the OMA CP message > > Please note: these logs were taken using SW 124. The OMA CP message was sent > from the TMO VQG test sever. > Please note: this OMA CP message's authentication mechanism is the Network > PIN. > > In the QXDM log you can see beginning at time stamp 14:40:36.380 the > reception > of the OMA CP message. So it is verified that the message has been sent out > and > was also received by the device. The question is what prevents the device > from > processing the message? > > On the device is there any kind of whitelist which could prevent the > successful > reception of an OMA CP message? Hi Liang Xin, thanks for the complete log!! But could you also submit a SR to QCT and attach these logs? Mozilla will help to check the logs, but in the meantime, I think it will be more effective if QCT can also start to check the logs as well
Flags: needinfo?(sync-1) → needinfo?(liang.xin)
Comment 18•10 years ago
|
||
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #17) > (In reply to liangxin from comment #16) > > Created attachment 8409986 [details] > > Soul35_124_OMACP_2010417.zip > > > > Dear all, > > > > please find attached another set data regarding the OMA CP reception. It > > includes: > > - QXDM file > > - ADB log taken in parallel to the QXDM log > > - XML file showing the content of the OMA CP message > > > > Please note: these logs were taken using SW 124. The OMA CP message was sent > > from the TMO VQG test sever. > > Please note: this OMA CP message's authentication mechanism is the Network > > PIN. > > > > In the QXDM log you can see beginning at time stamp 14:40:36.380 the > > reception > > of the OMA CP message. So it is verified that the message has been sent out > > and > > was also received by the device. The question is what prevents the device > > from > > processing the message? > > > > On the device is there any kind of whitelist which could prevent the > > successful > > reception of an OMA CP message? > > Hi Liang Xin, thanks for the complete log!! But could you also submit a SR > to QCT and attach these logs? Mozilla will help to check the logs, but in > the meantime, I think it will be more effective if QCT can also start to > check the logs as well I have submited this issue to QCT and attached these log.
Flags: needinfo?(liang.xin)
Assignee | ||
Comment 19•10 years ago
|
||
Hi All, I've dig out the problem today with Liangxin's log and the xml file he provided. In the log, I saw the binary data of the wap push was printed. Hence, I created the following PDUs to simulate the scenario by sending these PDUs to the emulator: sms pdu 00400C919471117426890004001010000000008C0B05040B8423F00003030301F3062F1F2DB69180923842364343363938313230303239333932333539373633344433313637384537373338343532323800020B6A1F542D4D6F62696C6520496E7465726E657400696E7465726E65742D61706E00C54601C6560187070683000101C65501871106831201871006AB0187070683000187090689018708060369 sms pdu 00400C919471117426890004001010000000008C0B05040B8423F000030303026E7465726E65742E742D6D6F62696C650001870F06033135300001874806033139332E3235342E3136302E3030310001874806033139332E3235342E3136302E3133300001C65A01870C069A01870D0603742D6D6F62696C650001870E0603746D00010101C60001550187360000060377320001872206831201870706830001 sms pdu 00400C91947111742689000400101000000000530B05040B8423F00003030303C6000159018700000706035374617274207061676500018700013A00000603687474703A2F2F7777772E742D6D6F62696C652D6661766F726974656E2E64650001871C01010101 Eventually, this CP message was not parsed correctly because the attribute |DNS-ADDR| in tag <param> was not recognized in current implementation. After checking the predefined |CP_ATTRIBUTE_FIELDS| in |CpPduHelper.jsm| [1], we found that |DNS-ADDR| is not defined. The reason is that, we still refer to the old code page 0 defined in WAP-183-ProvCont-20010724-A instead of the new one in OMA-WAP-TS-ProvCont-V1_1-20090421-C. I'll upload the patch later to address this. Please kindly help to give it a try to see if the problem is resolved in the real network. Thanks, Bevis -- [1] http://hg.mozilla.org/mozilla-central/file/9584fced1895/dom/wappush/src/gonk/CpPduHelper.jsm#l246
Status: RESOLVED → REOPENED
blocking-b2g: --- → 1.3?
status-b2g-v1.3:
--- → affected
status-b2g-v1.3T:
--- → affected
status-b2g-v1.4:
--- → affected
status-b2g-v2.0:
--- → affected
Resolution: INCOMPLETE → ---
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → btseng
> The reason is that, we still refer to the old code page 0 defined in
> WAP-183-ProvCont-20010724-A instead of the new one in
> OMA-WAP-TS-ProvCont-V1_1-20090421-C.
>
Thanks for your prompt investigation Bevis, could you also help to check and make sure that there is no other newly-add attributes in OMA-WAP-TS-ProvCont-V1_1-20090421-C that we haven't implemented?
Thanks
Vance
Flags: needinfo?(btseng)
Assignee | ||
Comment 21•10 years ago
|
||
(In reply to Vance Chen [:vchen][vchen@mozilla.com] from comment #20) > OMA-WAP-TS-ProvCont-V1_1-20090421-C that we haven't implemented? > Vance Yes, I've reviewed it again and included them in the patch being uploaded.
Flags: needinfo?(btseng)
Assignee | ||
Comment 22•10 years ago
|
||
The reason that CP message cannot be handled is that the attribute |DNS-ADDR| is not recognized in current CpPduHelper.jsm which is already defined in the OMA-CP standard. This patch is to update the code page 0 attributes/tag/values according to OMA-WAP-TS-ProvCont-V1_1-20090421-C instead of the old one we refer to in WAP-183-ProvCont-20010724-A.
Attachment #8410114 -
Flags: review?(vyang)
Comment 23•10 years ago
|
||
Comment on attachment 8410114 [details] [diff] [review] Patch Part1 v1: Update CP Code Page 0 to the one defined in OMA-WAP-TS-ProvCont-V1_1-20090421-C. r=vyang, a=1.3+ Review of attachment 8410114 [details] [diff] [review]: ----------------------------------------------------------------- Can you help attach new test cases for these fields as well?
Updated•10 years ago
|
Component: Vendcom → RIL
Yes, this is a cert blocker
Flags: needinfo?(vchen)
Updated•10 years ago
|
blocking-b2g: 1.3? → 1.3+
Whiteboard: [cert]
Assignee | ||
Comment 26•10 years ago
|
||
Here comes the corresponding test case of the newly added attributes/tags. :)
Attachment #8410767 -
Flags: review?(vyang)
Assignee | ||
Updated•10 years ago
|
Attachment #8410114 -
Attachment description: Patch v1: Update CP Code Page 0 to the one defined in OMA-WAP-TS-ProvCont-V1_1-20090421-C. r=vyang, a=1.3+ → Patch Part1 v1: Update CP Code Page 0 to the one defined in OMA-WAP-TS-ProvCont-V1_1-20090421-C. r=vyang, a=1.3+
Comment 27•10 years ago
|
||
Comment on attachment 8410767 [details] [diff] [review] Patch Part2 v1: Modify Test cases to verify newly added attributes. r=vyang, a=1.3+ Review of attachment 8410767 [details] [diff] [review]: ----------------------------------------------------------------- Well, I guess I can only rubber-stamp here. Maybe we can reformat that binary array to include indentations like that xml does. Let's see what can we do for better readability in the future. Thank you.
Attachment #8410767 -
Flags: review?(vyang) → review+
Comment 28•10 years ago
|
||
Comment on attachment 8410114 [details] [diff] [review] Patch Part1 v1: Update CP Code Page 0 to the one defined in OMA-WAP-TS-ProvCont-V1_1-20090421-C. r=vyang, a=1.3+ Review of attachment 8410114 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/wappush/src/gonk/CpPduHelper.jsm @@ +311,5 @@ > add("name", "TRAFFIC-HANDL-PRIO", 0, 0x39); > add("name", "TRANSFER-DELAY", 0, 0x3A); > add("name", "GUARANTEED-BITRATE-UPLINK", 0, 0x3B); > add("name", "GUARANTEED-BITRATE-DNLINK", 0, 0x3C); > add("version", "", 0, 0x45); We missed 0x3D, 0x3E, 0x3F here.
Attachment #8410114 -
Flags: review?(vyang)
Assignee | ||
Comment 29•10 years ago
|
||
(In reply to Vicamo Yang [:vicamo][:vyang] from comment #28) > @@ +311,5 @@ > > add("name", "TRAFFIC-HANDL-PRIO", 0, 0x39); > > add("name", "TRANSFER-DELAY", 0, 0x3A); > > add("name", "GUARANTEED-BITRATE-UPLINK", 0, 0x3B); > > add("name", "GUARANTEED-BITRATE-DNLINK", 0, 0x3C); > > add("version", "", 0, 0x45); > > We missed 0x3D, 0x3E, 0x3F here. Sorry, my bad. I'll add these 3 attributes and the corresponding test cases. Thanks, Bevis
Assignee | ||
Comment 30•10 years ago
|
||
Add missed attributes: 0x3D, 0x3E, 0x3F.
Attachment #8410114 -
Attachment is obsolete: true
Attachment #8411527 -
Flags: review?(vyang)
Assignee | ||
Comment 31•10 years ago
|
||
Align wbxml_data_array for better understanding.
Attachment #8410767 -
Attachment is obsolete: true
Attachment #8411528 -
Flags: review?(vyang)
Assignee | ||
Comment 32•10 years ago
|
||
Attachment #8411530 -
Flags: review?(vyang)
Updated•10 years ago
|
Attachment #8411527 -
Flags: review?(vyang) → review+
Comment 33•10 years ago
|
||
Comment on attachment 8411528 [details] [diff] [review] Patch Part2 v2: Align wbxml_data_array for better understanding. r=vyang, a=1.3+ Review of attachment 8411528 [details] [diff] [review]: ----------------------------------------------------------------- Excellent!!!
Attachment #8411528 -
Flags: review?(vyang) → review+
Updated•10 years ago
|
Attachment #8411530 -
Flags: review?(vyang) → review+
Assignee | ||
Comment 34•10 years ago
|
||
Try server result is green: https://tbpl.mozilla.org/?tree=Try&rev=3857df56e4ac https://tbpl.mozilla.org/?tree=Try&rev=b30752a41283
Keywords: checkin-needed
Comment 35•10 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/9f8d77205b1f https://hg.mozilla.org/integration/b2g-inbound/rev/50e4a1ca236c https://hg.mozilla.org/integration/b2g-inbound/rev/56c769a1a173
Flags: in-testsuite+
Keywords: checkin-needed
Comment 36•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/9f8d77205b1f https://hg.mozilla.org/mozilla-central/rev/50e4a1ca236c https://hg.mozilla.org/mozilla-central/rev/56c769a1a173
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S1 (9may)
Comment 37•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/436884f12e45 https://hg.mozilla.org/releases/mozilla-aurora/rev/c04fa70ed442 https://hg.mozilla.org/releases/mozilla-aurora/rev/03d3f4512890 Please request approval-mozilla-b2g28 on these patches when you feel they are sufficiently baked for v1.3 uplift.
status-firefox29:
--- → wontfix
status-firefox30:
--- → fixed
status-firefox31:
--- → fixed
Target Milestone: 2.0 S1 (9may) → 1.4 S6 (25apr)
Assignee | ||
Comment 38•10 years ago
|
||
Comment on attachment 8411527 [details] [diff] [review] Patch Part1 v2: Update CP Code Page 0 to the one defined in OMA-WAP-TS-ProvCont-V1_1-20090421-C. r=vyang, a=1.3+ NOTE: This flag is now for security issues only. 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 #): No. It's because that the implementation didn't cach up the latest OMA CP Specification. User impact if declined: Partner cannot get approval of the test certificate. Testing completed: Yes. Risk to taking this patch (and alternatives if risky): No String or UUID changes made by this patch:N/A
Attachment #8411527 -
Flags: approval-mozilla-b2g28?
Assignee | ||
Comment 39•10 years ago
|
||
Comment on attachment 8411528 [details] [diff] [review] Patch Part2 v2: Align wbxml_data_array for better understanding. r=vyang, a=1.3+ NOTE: This flag is now for security issues only. 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 #): No. It's because that the implementation didn't cach up the latest OMA CP Specification. User impact if declined: Partner cannot get approval of the test certificate. Testing completed: Yes. Risk to taking this patch (and alternatives if risky): No String or UUID changes made by this patch:N/A
Attachment #8411528 -
Flags: approval-mozilla-b2g28?
Assignee | ||
Comment 40•10 years ago
|
||
Comment on attachment 8411530 [details] [diff] [review] Patch Part3 v2: Modify Test cases to verify newly added attributes. r=vyang, a=1.3+ NOTE: This flag is now for security issues only. 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 #): No. It's because that the implementation didn't cach up the latest OMA CP Specification. User impact if declined: Partner cannot get approval of the test certificate. Testing completed: Yes. Risk to taking this patch (and alternatives if risky): No String or UUID changes made by this patch:N/A
Attachment #8411530 -
Flags: approval-mozilla-b2g28?
Assignee | ||
Comment 41•10 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #37) > https://hg.mozilla.org/releases/mozilla-aurora/rev/436884f12e45 > https://hg.mozilla.org/releases/mozilla-aurora/rev/c04fa70ed442 > https://hg.mozilla.org/releases/mozilla-aurora/rev/03d3f4512890 > > Please request approval-mozilla-b2g28 on these patches when you feel they > are sufficiently baked for v1.3 uplift. Thanks for reminding. I've fired the request for approval-mozilla-b2g28.
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 42•10 years ago
|
||
1) Please don't set checkin-needed when it's not ready for checkin (still needs approval). 2) Approvals are queried daily, so no need to request checkin once approved.
Keywords: checkin-needed
Assignee | ||
Comment 43•10 years ago
|
||
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #42) > 1) Please don't set checkin-needed when it's not ready for checkin (still > needs approval). > 2) Approvals are queried daily, so no need to request checkin once approved. Oops. Sorry and thanks for the clarification of checkin and approval policy.
Updated•10 years ago
|
Attachment #8411527 -
Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Updated•10 years ago
|
Attachment #8411528 -
Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Updated•10 years ago
|
Attachment #8411530 -
Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Updated•10 years ago
|
Keywords: checkin-needed
Updated•10 years ago
|
Keywords: checkin-needed
Comment 44•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/094a1130d96f https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/f36506f6c30f https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/2c2c3c475b47
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
•