Closed Bug 991445 Opened 6 years ago Closed 5 years ago

[Sora]OMA CP messages are not processed

Categories

(Firefox OS Graveyard :: RIL, defect, P1)

defect

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)

RESOLVED FIXED
1.4 S6 (25apr)
blocking-b2g 1.3+
Tracking Status
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)

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:
Attached file Log of Issue
The attachement only contains qxdm log.
Need ril related logs enabled to see what happened.
Component: Gaia::SMS → RIL
Flags: needinfo?(sync-1)
Assignee: nobody → btseng
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.
Please test the log you need.
(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
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
Flags: needinfo?(sync-1)
NI for questions in comment 7, since there is not much we can do in gecko side.
Flags: needinfo?(sync-1)
blocking-b2g: --- → 1.3?
Set component to Vendcom according to comment 7
Component: RIL → Vendcom
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?
Michael

Wondering if this found on QC RIL. Please help with the investigation
Flags: needinfo?(mvines)
The SR system can be used for non-Mozilla support requests, thanks.
Flags: needinfo?(mvines)
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.
(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: 5 years ago
Resolution: --- → INCOMPLETE
Keywords: qawanted
Duplicate of this bug: 997070
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)
(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)
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?
Resolution: INCOMPLETE → ---
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)
(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)
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 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?
Component: Vendcom → RIL
Vance - Is this a cert blocker for TCL?
Flags: needinfo?(vchen)
Yes, this is a cert blocker
Flags: needinfo?(vchen)
blocking-b2g: 1.3? → 1.3+
Whiteboard: [cert]
Here comes the corresponding test case of the newly added attributes/tags. :)
Attachment #8410767 - Flags: review?(vyang)
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 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 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)
(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
Add missed attributes: 0x3D, 0x3E, 0x3F.
Attachment #8410114 - Attachment is obsolete: true
Attachment #8411527 - Flags: review?(vyang)
Align wbxml_data_array for better understanding.
Attachment #8410767 - Attachment is obsolete: true
Attachment #8411528 - Flags: review?(vyang)
Attachment #8411527 - Flags: review?(vyang) → review+
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+
Attachment #8411530 - Flags: review?(vyang) → review+
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: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S1 (9may)
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.
Target Milestone: 2.0 S1 (9may) → 1.4 S6 (25apr)
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?
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?
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?
(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.
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
(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.
Attachment #8411527 - Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Attachment #8411528 - Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Attachment #8411530 - Flags: approval-mozilla-b2g28? → approval-mozilla-b2g28+
Flags: in-moztrap?
Flags: in-moztrap? → in-moztrap-
You need to log in before you can comment on or make changes to this bug.