Hello, Regarding discovery logic, are there any other contributor? This problem prevent next step continue.
We cannot take any progress due to this blocker. BR, Uze Choi From: ??? (Uze Choi) [mailto:[email protected]] Sent: Friday, April 14, 2017 3:55 PM To: Habib Virji (habib.virji at samsung.com); 'Ziran Sun'; 'i.mushfiq at samsung.com' Cc: 'nathan.heldt-sheller at intel.com'; 'Daniel.Mihai at microsoft.com'; 'vkandalla at graniteriverlabs.com'; 'lab_mgr at openconnectivity.org'; 'Towhidul Islam'; 'Mark Trayer'; '???'; 'ofer at tekoia.com'; 'richard.a.bardini at intel.com'; '????'; 'b.scriber at cablelabs.com'; 'dbartolome at at4wireless.com'; '???'; 'david.r.kaufman at honeywell.com'; 'todd.malsbary at intel.com'; 'srikguru at microsoft.com'; '???'; 'ed.agis at intel.com'; 'joseph.l.morrow at intel.com'; '???'; 'craig at ecaspia.com'; 'Jacek Hryszkiewicz'; 'Mitch Kettrick' Subject: RE: IoTivity 1.3-rel vs CTT 1.5.4 - Test Results Ziran/Habib, Could you check the discovery response payload applying the OCF1.0 spec? BR, Uze Choi From: Jacek Hryszkiewicz [mailto:[email protected]] Sent: Friday, April 14, 2017 3:31 PM To: 'Mitch Kettrick'; 'Ziran Sun'; i.mushfiq at samsung.com Cc: nathan.heldt-sheller at intel.com; Daniel.Mihai at microsoft.com; vkandalla at graniteriverlabs.com; lab_mgr at openconnectivity.org; 'Towhidul Islam'; 'Mark Trayer'; '???'; '???'; ofer at tekoia.com; richard.a.bardini at intel.com; '????'; b.scriber at cablelabs.com; dbartolome at at4wireless.com; '???'; david.r.kaufman at honeywell.com; todd.malsbary at intel.com; wovander at cisco.com; srikguru at microsoft.com; '???'; ed.agis at intel.com; '???'; joseph.l.morrow at intel.com; '???'; craig at ecaspia.com Subject: RE: IoTivity 1.3-rel vs CTT 1.5.4 - Test Results Hi, Issue 1: This is IUT issue. CTT sends RETIREVE request for oic/res with the interface oic.if.baseline. Proper response for such request is an array of objects (see schema and RAML) while here IUT responds with an object: {"n":"Vendor Smart Home AirCon Device","di":"6a757374-776f-726b-4465-765575696430","rt":["oic.wk.res"],"if":["oic.if.ll","oic.if.baseline"],"links":[{"href":"/oic/sec/doxm","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["oic.r.doxm"],"if":["oic.if.baseline"],"p":{"bm":1},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/oic/sec/pstat","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["oic.r.pstat"],"if":["oic.if.baseline"],"p":{"bm":1},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/oic/d","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["oic.wk.d","oic.d.airconditioner"],"if":["oic.if.baseline","oic.if.r"],"p":{"bm":1},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/oic/p","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["oic.wk.p"],"if":["oic.if.baseline","oic.if.r"],"p":{"bm":1},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/oic/introspection","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["oic.wk.introspection"],"if":["oic.if.baseline","oic.if.r"],"p":{"bm":1},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/BinarySwitchResURI","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["oic.r.switch.binary"],"if":["oic.if.baseline","oic.if.a"],"p":{"bm":3},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/TemperatureResURI","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["oic.r.temperature"],"if":["oic.if.baseline","oic.if.a"],"p":{"bm":3},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/AirFlowResURI","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["oic.r.airflow"],"if":["oic.if.baseline","oic.if.a"],"p":{"bm":3},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/Vendor/AirConditioner/TimerClock","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["x.com.vendor.timer"],"if":["oic.if.baseline","oic.if.a"],"p":{"bm":1},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/Vendor/AirConditioner/Swinger","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["x.com.vendor.swing"],"if":["oic.if.baseline","oic.if.a"],"p":{"bm":1},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/vendor/aircon/collection/extra","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["oic.wk.col","x.com.vendor.aircon.collection.extra"],"if":["oic.if.baseline","oic.if.ll","oic.if.b"],"p":{"bm":1},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]},{"href":"/vendor/aircon/collection","anchor":"ocf://6a757374-776f-726b-4465-765575696430","rt":["oic.wk.col","x.com.vendor.aircon.collection"],"if":["oic.if.baseline","oic.if.ll","oic.if.b"],"p":{"bm":1},"eps":[{"ep":"coap://192.168.56.101:47103","pri":1},{"ep":"coaps://192.168.56.101:53909","pri":1},{"ep":"coap://[fe80::36bc:ba82:adf0:c83a]:0","pri":1},{"ep":"coaps://[fe80::36bc:ba82:adf0:c83a]:0","pri":1}]}]} Best Regards, Jacek Hryszkiewicz From: Mitch Kettrick [mailto:[email protected]] Sent: Thursday, April 13, 2017 8:03 PM To: 'Ziran Sun' <ziran.sun at samsung.com>; i.mushfiq at samsung.com; jacek.hryszkiewicz at comarch.com Cc: nathan.heldt-sheller at intel.com; Daniel.Mihai at microsoft.com; vkandalla at graniteriverlabs.com; lab_mgr at openconnectivity.org; 'Towhidul Islam' <t.islam at samsung.com>; 'Mark Trayer' <m.trayer at samsung.com>; '???' <jinchoe at samsung.com>; '???' <uzchoi at samsung.com>; ofer at tekoia.com; richard.a.bardini at intel.com; '????' <dwarka.dayama at samsung.com>; b.scriber at cablelabs.com; dbartolome at at4wireless.com; '???' <jminl.choi at samsung.com>; david.r.kaufman at honeywell.com; todd.malsbary at intel.com; wovander at cisco.com; srikguru at microsoft.com; '???' <moonki1.hong at samsung.com>; ed.agis at intel.com; '???' <daeken.kwon at samsung.com>; joseph.l.morrow at intel.com; '???' <j3s3h3.jin at samsung.com>; craig at ecaspia.com Subject: RE: IoTivity 1.3-rel vs CTT 1.5.4 - Test Results Hi, 1. It looks like several test cases did not run with an exception thrown failure like this: 1.193s 11:56:13 ERROR:?Exception thrown from python script: Failed to run python script from file "C:\Program Files (x86)\OCF Certification Test Tool\Configuration\OCF\TestCases\Resource_CT1_2_6.py" Traceback (most recent ... 1.193s 11:56:13 DEBUG:?continued: ...call last): File "C:\Program Files (x86)\OCF Certification Test Tool\Configuration\OCF\TestCases\Resource_CT1_2_6.py", line 211, in File "C:\Program Files (x86)\OCF Certification Test Tool\Configuration\OCF\TestCases\Resource_CT1_2_6.py", line 138, in run File "C:\Program Files (x86)\OCF Certification Test Tool\Configuration\OCF\TestCasesUtils\CT_Security_Common.py", line 25, in add_aces_for_all_resources File "C:\Program Files (x86)\OCF Certification Test Tool\Configuration\OCF\TestCasesUtils\CT_Common.py", line 159, in get_base_links TypeError: iteration over non-sequence of type NoneType Can you look into this please, Jacek? 2. Regarding the issue with the Endpoint test case, can you confirm what the ACL is on the IUT? We are silent on what ACL/ACE to use in this test case and it's possible that this is what is causing the failures. 3. I also noticed that you're exposing IPv6 Endpoints and none of them are accessible. Does the IUT support IPv6? If not, those Endpoints should not be exposed. No sense in spending too much more time on these logs until the first issue is resolved. Mitch From: Ziran Sun [mailto:[email protected]] Sent: Thursday, April 13, 2017 8:49 AM To: i.mushfiq at samsung.com; cpm at openconnectivity.org Cc: nathan.heldt-sheller at intel.com; Daniel.Mihai at microsoft.com; vkandalla at graniteriverlabs.com; lab_mgr at openconnectivity.org; 'Towhidul Islam'; 'Mark Trayer'; '???'; jacek.hryszkiewicz at comarch.com; '???'; ofer at tekoia.com; richard.a.bardini at intel.com; '????'; b.scriber at cablelabs.com; dbartolome at at4wireless.com; '???'; david.r.kaufman at honeywell.com; todd.malsbary at intel.com; wovander at cisco.com; srikguru at microsoft.com; '???'; ed.agis at intel.com; '???'; joseph.l.morrow at intel.com; '???'; craig at ecaspia.com Subject: RE: IoTivity 1.3-rel vs CTT 1.5.4 - Test Results Hi, Just let you know that versioning related patches are not all in yet. They are dependent on a provisioning related patch. We are hoping to have them in ASAP. Best regards, Ziran From: ??? [mailto:[email protected]] Sent: 13 April 2017 14:40 To: cpm at openconnectivity.org Cc: nathan.heldt-sheller at intel.com; Daniel.Mihai at microsoft.com; vkandalla at graniteriverlabs.com; lab_mgr at openconnectivity.org; Towhidul Islam; Mark Trayer; Ziran Sun; ???; jacek.hryszkiewicz at comarch.com; ???; ofer at tekoia.com; richard.a.bardini at intel.com; ????; b.scriber at cablelabs.com; dbartolome at at4wireless.com; ???; david.r.kaufman at honeywell.com; todd.malsbary at intel.com; wovander at cisco.com; srikguru at microsoft.com; ???; ed.agis at intel.com; ???; joseph.l.morrow at intel.com; ???; craig at ecaspia.com Subject: IoTivity 1.3-rel vs CTT 1.5.4 - Test Results Dear Mitch, I am sharing the Conformance Test result of IoTivity 1.3-rel branch against CTT 1.5.4 Most of the test could not finish because of a issue regarding discovery. TC Error Log Comment CT1.1.1, CT1.1.5, CT_Introspection1.1.1, CT1.2.2, CT1.2.3, CT1.2.6, CT1.7.7.1, CT1.7.8.1, CT1.7.8.2, CT1.7.8.3, CT1.7.9.1, CT1.7.9.2, CT1.7.10.4 ?? ??? ??? ??????. This is a new issue. Need to analyze what is the cause. CT1.7.2.1 ?? ??? ??? ??????. ?? ??? ??? ??????. old issue CT1.1.3 ?? ??? ??? ??????. Seems like a versioning issue, need to analyze more CT_Endpoint1.1.1.1 ?? ??? ??? ??????. IoTivity Issue. IoTivity resources are not responding to the endpoints with 'coap' protocol. Endpoints with 'coaps' protocol are working fine. Also looks like all the resources are listed with both 'coap' (non-secured) & 'coaps'(secured) endpoint, which should not be there. Moreover, IP versions which the resource is not using, are also listed in endpoint information. - Thanks & Regards, Mushfiqul Islam Antu --------- Original Message --------- Sender : Muhammad Mushfiqul Islam <i.mushfiq at samsung.com> ./Lead Engineer/SRBD-SW Engineering Group/Samsung Electronics Date : 2017-04-11 11:53 (GMT+6) Title : IoTivity 1.3-rel vs CTT 1.5.3 - Test Results Dear Mitch, As new release branch of IoTivity has been forked, I am sharing the Conformance Test result with CTT 1.5.3 All the results looks pretty much same as before. TC Error Log Comment CT 1.1.1 ?? ??? ??? ??????. 1. Looks like according to new schema for OCF1.0, "links" is no longer required. But IoTivity is sending response including "links" CT1.2.2 ?? ??? ??? ??????. 1. oic.r.pstat resource shows 2 schema mismatch: -> 'deviceuuid' is not listed in response -> 'name' is listed in response, which is not desired. => is the schema for pstat resource has been updated in this version(1.5.3) ? CT1.2.3 ?? ??? ??? ??????. 1. CTT is trying to update an read-only property(e.g. "range") and expecting to get success response if in OCF1.0 schema, range is not read only, then I think it is a issue with the new schema. A device will always have a physical/mechanical limit of the range it can operate, and no client should be able to update it. Even if update is permitted, that would not bear any sense. E.g., suppose an air-conditioner can lower the temperature to a minimum value of 10 degree Celsius. Now, if a client changes the lower limit to 2 degree Celsius, that is not possible for the device mechanically, and thus the information would be wrong. So 'range' should always be read only. CT1.7.2.1 ?? ??? ??? ??????. Some new issue with 'oic.r.pstat' resource. CTT issue CT1.7.8.3 ?? ??? ??? ??????. cid:image006.png at 01D2A3D1.4638DDF0 Same as CT1.2.3 CT1.7.9.1 ?? ??? ??? ??????. 1. introspection resource problem, IoTIvity should fix. 2. looks like '/oic/sec/acl' resource is not following the new schema. => So according to new schema, permissions should be given to endpoints instead of urls, is this right? CT_Endpoint1.1.1.1 ?? ??? ??? ??????. 1.IoTivity Issue. IoTivity resources are not responding to the endpoints with 'coap' protocol. Endpoints with 'coaps' protocol are working fine. Also looks like all the resources are listed with both 'coap' (non-secured) & 'coaps'(secured) endpoint, which should not be there. Moreover, IP versions which the resource is not using, are also listed in endpoint information. CT_Introspection1.1.2 ?? ??? ??? ??????. cid:image009.png at 01D2A3D1.4638DDF0 1. IoTivity Issue 'data' is not mentioned in spec, yet /oic/introspection resource has it - Thanks & Regards, Mushfiqul Islam Antu --------- Original Message --------- Sender : Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com> Date : 2017-03-31 20:11 (GMT+6) Title : RE: CTT 1.5.3 - IoTivity master - Test ResultsIIn IoTivity To : null<Daniel.Mihai at microsoft.com> CC : null<cpm at openconnectivity.org>, Muhammad Mushfiqul Islam<i.mushfiq at samsung.com>, null<vkandalla at graniteriverlabs.com>, null<lab_mgr at openconnectivity.org>, Towhidul Islam<t.islam at samsung.com>, Mark Trayer<m.trayer at samsung.com>, Ziran Sun<ziran.sun at samsung.com>, JinHyeock Choi<jinchoe at samsung.com>, null<jacek.hryszkiewicz at comarch.com>, Uze Choi<uzchoi at samsung.com>, null<ofer at tekoia.com>, null<richard.a.bardini at intel.com>, DWARKAPRASAD DAYAMA<dwarka.dayama at samsung.com>, null<b.scriber at cablelabs.com>, null<dbartolome at at4wireless.com>, jongmin choi<jminl.choi at samsung.com>, null<david.r.kaufman at honeywell.com>, null<todd.malsbary at intel.com>, null<wovander at cisco.com>, null<srikguru at microsoft.com>, Peter Moonki Hong<moonki1.hong at samsung.com>, null<Ed.Agis at intel.com>, Daeken Kwon<daeken.kwon at samsung.com>, null<joseph.l.morrow at intel.com>, Sam-Hak Jin<j3s3h3.jin at samsung.com>, null<craig at ecaspia.com> Okay I'll look into it, thanks Dan! On Mar 31, 2017 7:08 AM, Daniel Mihai <Daniel.Mihai at microsoft.com> wrote: I?m not an expert or a fan of the pstatresource.c source code, but here?s my understanding of this recent change: https://gerrit.iotivity.org/gerrit/#/c/17993/13/resource/csdk/security/src/pstatresource.c 1. *One* pstat property has been added (dos) 2. *Both* PSTAT_MAP_SIZE and WRITEABLE_PROPERTY_SIZE have been incremented 3. There is at least one code path ? in PstatToCBORPayload() @line 156 ? where pstatMapSize = PSTAT_MAP_SIZE + WRITEABLE_PROPERTY_SIZE So, on that code path, the single new property gets counted twice. Dan From: Heldt-Sheller, Nathan [mailto:[email protected]] Sent: Thursday, March 30, 2017 6:58 PM To: Daniel Mihai <Daniel.Mihai at microsoft.com>; Mitch Kettrick <cpm at openconnectivity.org>; 'Jacek Hryszkiewicz' <jacek.hryszkiewicz at comarch.com>; i.mushfiq at samsung.com Cc: 'Mark Trayer' <m.trayer at samsung.com>; 'Wouter van der Beek' <wovander at cisco.com>; 'Craig Pratt' <craig at ecaspia.com>; 'jongmin choi' <jminl.choi at samsung.com>; 'Uze Choi' <uzchoi at samsung.com>; 'Vamshi Kandalla' <vkandalla at graniteriverlabs.com>; Morrow, Joseph L <joseph.l.morrow at intel.com>; 'Ofer Rotschield' <ofer at tekoia.com>; Malsbary, Todd <todd.malsbary at intel.com>; 'Diego Bartolom? Arquillo' <dbartolome at at4wireless.com>; 'Daeken Kwon' <daeken.kwon at samsung.com>; Agis, Ed <Ed.Agis at intel.com>; 'Jason Smith' <lab_mgr at openconnectivity.org>; 'Peter Moonki Hong' <moonki1.hong at samsung.com>; 'DWARKAPRASAD DAYAMA' <dwarka.dayama at samsung.com>; 'Towhidul Islam' <t.islam at samsung.com>; 'Sam-Hak Jin' <j3s3h3.jin at samsung.com>; 'Kaufman, David R ' <david.r.kaufman at honeywell.com>; 'JinHyeock Choi' <jinchoe at samsung.com>; Bardini, Richard A <richard.a.bardini at intel.com>; 'Ziran Sun' <ziran.sun at samsung.com>; Srikrishna Gurugubelli <srikguru at microsoft.com>; 'Brian Scriber' <b.scriber at cablelabs.com> Subject: RE: CTT 1.5.3 - IoTivity master - Test ResultsIIn IoTivity Well that?s pretty strong evidence! I see your changeset dropped the min size (?PSTAT_MAP_SIZE?, since renamed to ?PSTAT_MIN_MAP_SIZE?) from 7 to 6. Here?s the current snippet from Master (as of the merge of 18173); can you clarify for me why 6 is the correct size, please, given isop at this point is still read-write? // PSTAT Map size - Number of read-write items +2 for rt and if. // TODO [IOT-1958] isOp becomes read-only; -1 here static const uint8_t PSTAT_MIN_MAP_SIZE = 7; // dos, isOp, tm, om, rowneruuid, rt, if // .dos Property map size static const uint8_t PSTAT_DOS_MAP_SIZE = 2; // s, p // Number of read-only Properties, added to map if not creating a writable-only // representation. // TODO [IOT-1958] isOp becomes read-only; +1 here static const uint8_t READ_ONLY_PROPERTY_SIZE = 2; // cm, sm From: Daniel Mihai [mailto:[email protected]] Sent: Thursday, March 30, 2017 6:08 PM To: Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com>; Mitch Kettrick <cpm at openconnectivity.org>; 'Jacek Hryszkiewicz' <jacek.hryszkiewicz at comarch.com>; i.mushfiq at samsung.com Cc: 'Mark Trayer' <m.trayer at samsung.com>; 'Wouter van der Beek' <wovander at cisco.com>; 'Craig Pratt' <craig at ecaspia.com>; 'jongmin choi' <jminl.choi at samsung.com>; 'Uze Choi' <uzchoi at samsung.com>; 'Vamshi Kandalla' <vkandalla at graniteriverlabs.com>; Morrow, Joseph L <joseph.l.morrow at intel.com>; 'Ofer Rotschield' <ofer at tekoia.com>; Malsbary, Todd <todd.malsbary at intel.com>; 'Diego Bartolom? Arquillo' <dbartolome at at4wireless.com>; 'Daeken Kwon' <daeken.kwon at samsung.com>; Agis, Ed <Ed.Agis at intel.com>; 'Jason Smith' <lab_mgr at openconnectivity.org>; 'Peter Moonki Hong' <moonki1.hong at samsung.com>; 'DWARKAPRASAD DAYAMA' <dwarka.dayama at samsung.com>; 'Towhidul Islam' <t.islam at samsung.com>; 'Sam-Hak Jin' <j3s3h3.jin at samsung.com>; 'Kaufman, David R ' <david.r.kaufman at honeywell.com>; 'JinHyeock Choi' <jinchoe at samsung.com>; Bardini, Richard A <richard.a.bardini at intel.com>; 'Ziran Sun' <ziran.sun at samsung.com>; Srikrishna Gurugubelli <srikguru at microsoft.com>; 'Brian Scriber' <b.scriber at cablelabs.com> Subject: Re: CTT 1.5.3 - IoTivity master - Test ResultsIIn IoTivity Fyi, I prepared this smaller fix a couple of days ago precisely because CTT was hitting the pstat error mentioned below. That unblocked my CTT testing. <https://gerrit.iotivity.org/gerrit/#/c/18229/> https://gerrit.iotivity.org/gerrit/#/c/18229/ Dan _____ From: Heldt-Sheller, Nathan < <mailto:nathan.heldt-sheller at intel.com> [email protected]> Sent: Thursday, March 30, 2017 6:03 PM To: Daniel Mihai; Mitch Kettrick; 'Jacek Hryszkiewicz'; <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com Cc: 'Mark Trayer'; 'Wouter van der Beek'; 'Craig Pratt'; 'jongmin choi'; 'Uze Choi'; 'Vamshi Kandalla'; Morrow, Joseph L; 'Ofer Rotschield'; Malsbary, Todd; 'Diego Bartolom? Arquillo'; 'Daeken Kwon'; Agis, Ed; 'Jason Smith'; 'Peter Moonki Hong'; 'DWARKAPRASAD DAYAMA'; 'Towhidul Islam'; 'Sam-Hak Jin'; 'Kaufman, David R '; 'JinHyeock Choi'; Bardini, Richard A; 'Ziran Sun'; Srikrishna Gurugubelli; 'Brian Scriber' Subject: RE: CTT 1.5.3 - IoTivity master - Test ResultsIIn IoTivity >> CTT errors out when the map size is too large. It wouldn?t ever see this case, since it is never the recipient of a POST from DUT, right? Anyway, it?s a side point I think? J From: Daniel Mihai [ <mailto:Daniel.Mihai at microsoft.com> mailto:[email protected]] Sent: Thursday, March 30, 2017 5:56 PM To: Heldt-Sheller, Nathan < <mailto:nathan.heldt-sheller at intel.com> nathan.heldt-sheller at intel.com>; Mitch Kettrick < <mailto:cpm at openconnectivity.org> cpm at openconnectivity.org>; 'Jacek Hryszkiewicz' < <mailto:jacek.hryszkiewicz at comarch.com> jacek.hryszkiewicz at comarch.com>; <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com Cc: 'Mark Trayer' < <mailto:m.trayer at samsung.com> m.trayer at samsung.com>; 'Wouter van der Beek' < <mailto:wovander at cisco.com> wovander at cisco.com>; 'Craig Pratt' < <mailto:craig at ecaspia.com> craig at ecaspia.com>; 'jongmin choi' < <mailto:jminl.choi at samsung.com> jminl.choi at samsung.com>; 'Uze Choi' < <mailto:uzchoi at samsung.com> uzchoi at samsung.com>; 'Vamshi Kandalla' < <mailto:vkandalla at graniteriverlabs.com> vkandalla at graniteriverlabs.com>; Morrow, Joseph L < <mailto:joseph.l.morrow at intel.com> joseph.l.morrow at intel.com>; 'Ofer Rotschield' < <mailto:ofer at tekoia.com> ofer at tekoia.com>; Malsbary, Todd < <mailto:todd.malsbary at intel.com> todd.malsbary at intel.com>; 'Diego Bartolom? Arquillo' < <mailto:dbartolome at at4wireless.com> dbartolome at at4wireless.com>; 'Daeken Kwon' < <mailto:daeken.kwon at samsung.com> daeken.kwon at samsung.com>; Agis, Ed < <mailto:Ed.Agis at intel.com> Ed.Agis at intel.com>; 'Jason Smith' < <mailto:lab_mgr at openconnectivity.org> lab_mgr at openconnectivity.org>; 'Peter Moonki Hong' < <mailto:moonki1.hong at samsung.com> moonki1.hong at samsung.com>; 'DWARKAPRASAD DAYAMA' < <mailto:dwarka.dayama at samsung.com> dwarka.dayama at samsung.com>; 'Towhidul Islam' < <mailto:t.islam at samsung.com> t.islam at samsung.com>; 'Sam-Hak Jin' < <mailto:j3s3h3.jin at samsung.com> j3s3h3.jin at samsung.com>; 'Kaufman, David R ' < <mailto:david.r.kaufman at honeywell.com> david.r.kaufman at honeywell.com>; 'JinHyeock Choi' < <mailto:jinchoe at samsung.com> jinchoe at samsung.com>; Bardini, Richard A < <mailto:richard.a.bardini at intel.com> richard.a.bardini at intel.com>; 'Ziran Sun' < <mailto:ziran.sun at samsung.com> ziran.sun at samsung.com>; Srikrishna Gurugubelli < <mailto:srikguru at microsoft.com> srikguru at microsoft.com>; 'Brian Scriber' < <mailto:b.scriber at cablelabs.com> b.scriber at cablelabs.com> Subject: RE: CTT 1.5.3 - IoTivity master - Test ResultsIIn IoTivity >> changed the CBOR map size so that it wasn?t unnecessarily large in the >> writable-only case CTT errors out when the map size is too large. Dan From: Heldt-Sheller, Nathan [ <mailto:nathan.heldt-sheller at intel.com> mailto:[email protected]] Sent: Thursday, March 30, 2017 5:54 PM To: Daniel Mihai < <mailto:Daniel.Mihai at microsoft.com> Daniel.Mihai at microsoft.com>; Mitch Kettrick < <mailto:cpm at openconnectivity.org> cpm at openconnectivity.org>; 'Jacek Hryszkiewicz' < <mailto:jacek.hryszkiewicz at comarch.com> jacek.hryszkiewicz at comarch.com>; <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com Cc: 'Mark Trayer' < <mailto:m.trayer at samsung.com> m.trayer at samsung.com>; 'Wouter van der Beek' < <mailto:wovander at cisco.com> wovander at cisco.com>; 'Craig Pratt' < <mailto:craig at ecaspia.com> craig at ecaspia.com>; 'jongmin choi' < <mailto:jminl.choi at samsung.com> jminl.choi at samsung.com>; 'Uze Choi' < <mailto:uzchoi at samsung.com> uzchoi at samsung.com>; 'Vamshi Kandalla' < <mailto:vkandalla at graniteriverlabs.com> vkandalla at graniteriverlabs.com>; Morrow, Joseph L < <mailto:joseph.l.morrow at intel.com> joseph.l.morrow at intel.com>; 'Ofer Rotschield' < <mailto:ofer at tekoia.com> ofer at tekoia.com>; Malsbary, Todd < <mailto:todd.malsbary at intel.com> todd.malsbary at intel.com>; 'Diego Bartolom? Arquillo' < <mailto:dbartolome at at4wireless.com> dbartolome at at4wireless.com>; 'Daeken Kwon' < <mailto:daeken.kwon at samsung.com> daeken.kwon at samsung.com>; Agis, Ed < <mailto:Ed.Agis at intel.com> Ed.Agis at intel.com>; 'Jason Smith' < <mailto:lab_mgr at openconnectivity.org> lab_mgr at openconnectivity.org>; 'Peter Moonki Hong' < <mailto:moonki1.hong at samsung.com> moonki1.hong at samsung.com>; 'DWARKAPRASAD DAYAMA' < <mailto:dwarka.dayama at samsung.com> dwarka.dayama at samsung.com>; 'Towhidul Islam' < <mailto:t.islam at samsung.com> t.islam at samsung.com>; 'Sam-Hak Jin' < <mailto:j3s3h3.jin at samsung.com> j3s3h3.jin at samsung.com>; 'Kaufman, David R ' < <mailto:david.r.kaufman at honeywell.com> david.r.kaufman at honeywell.com>; 'JinHyeock Choi' < <mailto:jinchoe at samsung.com> jinchoe at samsung.com>; Bardini, Richard A < <mailto:richard.a.bardini at intel.com> richard.a.bardini at intel.com>; 'Ziran Sun' < <mailto:ziran.sun at samsung.com> ziran.sun at samsung.com>; Srikrishna Gurugubelli < <mailto:srikguru at microsoft.com> srikguru at microsoft.com>; 'Brian Scriber' < <mailto:b.scriber at cablelabs.com> b.scriber at cablelabs.com> Subject: RE: CTT 1.5.3 - IoTivity master - Test ResultsIIn IoTivity I don?t believe my changes would impact this area; I only updated the pstat resource to include the dos property, and changed the CBOR map size so that it wasn?t unnecessarily large in the writable-only case (the POST representation). From: Daniel Mihai [ <mailto:Daniel.Mihai at microsoft.com> mailto:[email protected]] Sent: Wednesday, March 29, 2017 5:58 PM To: Mitch Kettrick < <mailto:cpm at openconnectivity.org> cpm at openconnectivity.org>; 'Jacek Hryszkiewicz' < <mailto:jacek.hryszkiewicz at comarch.com> jacek.hryszkiewicz at comarch.com>; <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com Cc: Heldt-Sheller, Nathan < <mailto:nathan.heldt-sheller at intel.com> nathan.heldt-sheller at intel.com>; 'Mark Trayer' < <mailto:m.trayer at samsung.com> m.trayer at samsung.com>; 'Wouter van der Beek' < <mailto:wovander at cisco.com> wovander at cisco.com>; 'Craig Pratt' < <mailto:craig at ecaspia.com> craig at ecaspia.com>; 'jongmin choi' < <mailto:jminl.choi at samsung.com> jminl.choi at samsung.com>; 'Uze Choi' < <mailto:uzchoi at samsung.com> uzchoi at samsung.com>; 'Vamshi Kandalla' < <mailto:vkandalla at graniteriverlabs.com> vkandalla at graniteriverlabs.com>; Morrow, Joseph L < <mailto:joseph.l.morrow at intel.com> joseph.l.morrow at intel.com>; 'Ofer Rotschield' < <mailto:ofer at tekoia.com> ofer at tekoia.com>; Malsbary, Todd < <mailto:todd.malsbary at intel.com> todd.malsbary at intel.com>; 'Diego Bartolom? Arquillo' < <mailto:dbartolome at at4wireless.com> dbartolome at at4wireless.com>; 'Daeken Kwon' < <mailto:daeken.kwon at samsung.com> daeken.kwon at samsung.com>; Agis, Ed < <mailto:Ed.Agis at intel.com> Ed.Agis at intel.com>; 'Jason Smith' < <mailto:lab_mgr at openconnectivity.org> lab_mgr at openconnectivity.org>; 'Peter Moonki Hong' < <mailto:moonki1.hong at samsung.com> moonki1.hong at samsung.com>; 'DWARKAPRASAD DAYAMA' < <mailto:dwarka.dayama at samsung.com> dwarka.dayama at samsung.com>; 'Towhidul Islam' < <mailto:t.islam at samsung.com> t.islam at samsung.com>; 'Sam-Hak Jin' < <mailto:j3s3h3.jin at samsung.com> j3s3h3.jin at samsung.com>; 'Kaufman, David R ' < <mailto:david.r.kaufman at honeywell.com> david.r.kaufman at honeywell.com>; 'JinHyeock Choi' < <mailto:jinchoe at samsung.com> jinchoe at samsung.com>; Bardini, Richard A < <mailto:richard.a.bardini at intel.com> richard.a.bardini at intel.com>; 'Ziran Sun' < <mailto:ziran.sun at samsung.com> ziran.sun at samsung.com>; Srikrishna Gurugubelli < <mailto:srikguru at microsoft.com> srikguru at microsoft.com>; 'Brian Scriber' < <mailto:b.scriber at cablelabs.com> b.scriber at cablelabs.com> Subject: RE: CTT 1.5.3 - IoTivity master - Test ResultsIIn IoTivity >> There is some issue with the response payload for RETRIEVE oic/sec/pstat Fyi, I hit a similar problem a couple of days ago. Nathan mentioned to me yesterday that he fixed the CBOR format of /pstat in IoTivity, as part of this larger change: <https://gerrit.iotivity.org/gerrit/#/c/18173/> https://gerrit.iotivity.org/gerrit/#/c/18173/ Dan From: Mitch Kettrick [ <mailto:cpm at openconnectivity.org> mailto:[email protected]] Sent: Tuesday, March 28, 2017 4:26 PM To: 'Jacek Hryszkiewicz' < <mailto:jacek.hryszkiewicz at comarch.com> jacek.hryszkiewicz at comarch.com>; <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com Cc: 'Heldt-Sheller, Nathan' < <mailto:nathan.heldt-sheller at intel.com> nathan.heldt-sheller at intel.com>; Daniel Mihai < <mailto:Daniel.Mihai at microsoft.com> Daniel.Mihai at microsoft.com>; 'Mark Trayer' < <mailto:m.trayer at samsung.com> m.trayer at samsung.com>; 'Wouter van der Beek' < <mailto:wovander at cisco.com> wovander at cisco.com>; 'Craig Pratt' < <mailto:craig at ecaspia.com> craig at ecaspia.com>; 'jongmin choi' < <mailto:jminl.choi at samsung.com> jminl.choi at samsung.com>; 'Uze Choi' < <mailto:uzchoi at samsung.com> uzchoi at samsung.com>; 'Vamshi Kandalla' < <mailto:vkandalla at graniteriverlabs.com> vkandalla at graniteriverlabs.com>; 'Morrow, Joseph L' < <mailto:joseph.l.morrow at intel.com> joseph.l.morrow at intel.com>; 'Ofer Rotschield' < <mailto:ofer at tekoia.com> ofer at tekoia.com>; 'Malsbary, Todd' < <mailto:todd.malsbary at intel.com> todd.malsbary at intel.com>; 'Diego Bartolom? Arquillo' < <mailto:dbartolome at at4wireless.com> dbartolome at at4wireless.com>; 'Daeken Kwon' < <mailto:daeken.kwon at samsung.com> daeken.kwon at samsung.com>; 'Agis, Ed' < <mailto:Ed.Agis at intel.com> Ed.Agis at intel.com>; 'Jason Smith' < <mailto:lab_mgr at openconnectivity.org> lab_mgr at openconnectivity.org>; 'Peter Moonki Hong' < <mailto:moonki1.hong at samsung.com> moonki1.hong at samsung.com>; 'DWARKAPRASAD DAYAMA' < <mailto:dwarka.dayama at samsung.com> dwarka.dayama at samsung.com>; 'Towhidul Islam' < <mailto:t.islam at samsung.com> t.islam at samsung.com>; 'Sam-Hak Jin' < <mailto:j3s3h3.jin at samsung.com> j3s3h3.jin at samsung.com>; 'Kaufman, David R ' < <mailto:david.r.kaufman at honeywell.com> david.r.kaufman at honeywell.com>; 'JinHyeock Choi' < <mailto:jinchoe at samsung.com> jinchoe at samsung.com>; 'Bardini, Richard A' < <mailto:richard.a.bardini at intel.com> richard.a.bardini at intel.com>; 'Ziran Sun' < <mailto:ziran.sun at samsung.com> ziran.sun at samsung.com>; Srikrishna Gurugubelli < <mailto:srikguru at microsoft.com> srikguru at microsoft.com>; 'Brian Scriber' < <mailto:b.scriber at cablelabs.com> b.scriber at cablelabs.com> Subject: RE: CTT 1.5.3 - IoTivity master - Test ResultsIIn IoTivity Hi Antu, This looks to be an issue with the Device. From the log file: 1.265s 12:05:31 VERBOSE:?-> 192.168.56.1:49182->192.168.56.101:33105 CON-GET ID=41233, Token=5190F2BF, Options=[URI-Port=33105, URI-Path=oic, sec, pstat, Accept=application/cbor], Secured=true 1.270s 12:05:31 VERBOSE:?<- 192.168.56.101:33105->192.168.56.1:49182 ACK-2.05 Content ID=41233, Token=5190F2BF, Options=[URI-Path=oic, sec, pstat, ContentFormatVersion=2, 0, 4, 8, Content-Type=application/cbor], Secured=true For some reason, the Device responded with a Content-Format Version to a request message with an Accept Option of "application/cbor" which is not defined. Something must have changed with the device lately to change that. The device responded to this same message differently two days ago. Mitch From: Jacek Hryszkiewicz [ <mailto:jacek.hryszkiewicz at comarch.com> mailto:[email protected]] Sent: Tuesday, March 28, 2017 4:09 AM To: <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com; 'Mitch Kettrick' Cc: 'Heldt-Sheller, Nathan'; 'Daniel Mihai'; 'Mark Trayer'; 'Wouter van der Beek'; 'Craig Pratt'; 'jongmin choi'; 'Uze Choi'; 'Vamshi Kandalla'; 'Morrow, Joseph L'; 'Ofer Rotschield'; 'Malsbary, Todd'; 'Diego Bartolom? Arquillo'; 'Daeken Kwon'; 'Agis, Ed'; 'Jason Smith'; 'Peter Moonki Hong'; 'DWARKAPRASAD DAYAMA'; 'Towhidul Islam'; 'Sam-Hak Jin'; 'Kaufman, David R '; 'JinHyeock Choi'; 'Bardini, Richard A'; 'Ziran Sun'; 'Srikrishna Gurugubelli'; 'Brian Scriber' Subject: RE: CTT 1.5.3 - IoTivity master - Test ResultsIIn IoTivity Hi, This is not expected behavior. There is some issue with the response payload for RETRIEVE oic/sec/pstat. Could you please check what data IUT sends for such request? Jacek Hryszkiewicz From: Muhammad Mushfiqul Islam [ <mailto:i.mushfiq at samsung.com> mailto:[email protected]] Sent: Tuesday, March 28, 2017 8:17 AM To: Mitch Kettrick < <mailto:cpm at openconnectivity.org> cpm at openconnectivity.org> Cc: 'Jacek Hryszkiewicz' < <mailto:jacek.hryszkiewicz at comarch.com> jacek.hryszkiewicz at comarch.com>; 'Heldt-Sheller, Nathan' < <mailto:nathan.heldt-sheller at intel.com> nathan.heldt-sheller at intel.com>; 'Daniel Mihai' < <mailto:Daniel.Mihai at microsoft.com> Daniel.Mihai at microsoft.com>; Mark Trayer < <mailto:m.trayer at samsung.com> m.trayer at samsung.com>; 'Wouter van der Beek' < <mailto:wovander at cisco.com> wovander at cisco.com>; 'Craig Pratt' < <mailto:craig at ecaspia.com> craig at ecaspia.com>; jongmin choi < <mailto:jminl.choi at samsung.com> jminl.choi at samsung.com>; Uze Choi < <mailto:uzchoi at samsung.com> uzchoi at samsung.com>; 'Vamshi Kandalla' < <mailto:vkandalla at graniteriverlabs.com> vkandalla at graniteriverlabs.com>; 'Morrow, Joseph L' < <mailto:joseph.l.morrow at intel.com> joseph.l.morrow at intel.com>; 'Ofer Rotschield' < <mailto:ofer at tekoia.com> ofer at tekoia.com>; 'Malsbary, Todd' < <mailto:todd.malsbary at intel.com> todd.malsbary at intel.com>; 'Diego Bartolom? Arquillo' < <mailto:dbartolome at at4wireless.com> dbartolome at at4wireless.com>; Daeken Kwon < <mailto:daeken.kwon at samsung.com> daeken.kwon at samsung.com>; 'Agis, Ed' < <mailto:Ed.Agis at intel.com> Ed.Agis at intel.com>; 'Jason Smith' < <mailto:lab_mgr at openconnectivity.org> lab_mgr at openconnectivity.org>; Peter Moonki Hong < <mailto:moonki1.hong at samsung.com> moonki1.hong at samsung.com>; DWARKAPRASAD DAYAMA < <mailto:dwarka.dayama at samsung.com> dwarka.dayama at samsung.com>; Towhidul Islam < <mailto:t.islam at samsung.com> t.islam at samsung.com>; Sam-Hak Jin < <mailto:j3s3h3.jin at samsung.com> j3s3h3.jin at samsung.com>; 'Kaufman, David R ' < <mailto:david.r.kaufman at honeywell.com> david.r.kaufman at honeywell.com>; JinHyeock Choi < <mailto:jinchoe at samsung.com> jinchoe at samsung.com>; 'Bardini, Richard A' < <mailto:richard.a.bardini at intel.com> richard.a.bardini at intel.com>; Ziran Sun < <mailto:ziran.sun at samsung.com> ziran.sun at samsung.com>; 'Srikrishna Gurugubelli' < <mailto:srikguru at microsoft.com> srikguru at microsoft.com>; 'Brian Scriber' < <mailto:b.scriber at cablelabs.com> b.scriber at cablelabs.com> Subject: RE: CTT 1.5.3 - IoTivity master - Test ResultsIIn IoTivity Dear Mitch IoTIvity has not yet updated content-format from "application/cbor" to "application/vnd.ocf_cbor". May be, because of that, all the testcases are failing in CTT v1.5.3. Common failure message: cid:image001.png at 01D2A986.96674DB0 Is this an expected behavior in case the server responds with content-format="application/cbor" ? - Thanks & Regards, Mushfiqul Islam Antu --------- Original Message --------- Sender : Mitch Kettrick < <mailto:cpm at openconnectivity.org> cpm at openconnectivity.org> Date : 2017-03-27 20:34 (GMT+6) Title : CTT 1.5.2 - IoTivity master - Test Results - CTT v1.5.3 Uploaded To : null< <mailto:jacek.hryszkiewicz at comarch.com> jacek.hryszkiewicz at comarch.com>, null< <mailto:nathan.heldt-sheller at intel.com> nathan.heldt-sheller at intel.com>, null< <mailto:Daniel.Mihai at microsoft.com> Daniel.Mihai at microsoft.com>, Muhammad Mushfiqul Islam< <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com> CC : Mark Trayer< <mailto:m.trayer at samsung.com> m.trayer at samsung.com>, null< <mailto:wovander at cisco.com> wovander at cisco.com>, null< <mailto:craig at ecaspia.com> craig at ecaspia.com>, jongmin choi< <mailto:jminl.choi at samsung.com> jminl.choi at samsung.com>, Uze Choi< <mailto:uzchoi at samsung.com> uzchoi at samsung.com>, null< <mailto:vkandalla at graniteriverlabs.com> vkandalla at graniteriverlabs.com>, null< <mailto:joseph.l.morrow at intel.com> joseph.l.morrow at intel.com>, null< <mailto:ofer at tekoia.com> ofer at tekoia.com>, null< <mailto:todd.malsbary at intel.com> todd.malsbary at intel.com>, null< <mailto:dbartolome at at4wireless.com> dbartolome at at4wireless.com>, Daeken Kwon< <mailto:daeken.kwon at samsung.com> daeken.kwon at samsung.com>, null< <mailto:Ed.Agis at intel.com> Ed.Agis at intel.com>, null< <mailto:lab_mgr at openconnectivity.org> lab_mgr at openconnectivity.org>, Peter Moonki Hong< <mailto:moonki1.hong at samsung.com> moonki1.hong at samsung.com>, DWARKAPRASAD DAYAMA< <mailto:dwarka.dayama at samsung.com> dwarka.dayama at samsung.com>, Towhidul Islam< <mailto:t.islam at samsung.com> t.islam at samsung.com>, Sam-Hak Jin< <mailto:j3s3h3.jin at samsung.com> j3s3h3.jin at samsung.com>, null< <mailto:david.r.kaufman at honeywell.com> david.r.kaufman at honeywell.com>, JinHyeock Choi< <mailto:jinchoe at samsung.com> jinchoe at samsung.com>, null< <mailto:richard.a.bardini at intel.com> richard.a.bardini at intel.com>, Ziran Sun< <mailto:ziran.sun at samsung.com> ziran.sun at samsung.com>, null< <mailto:srikguru at microsoft.com> srikguru at microsoft.com>, null< <mailto:b.scriber at cablelabs.com> b.scriber at cablelabs.com> Hi Jacek, The change in oic.wk.res was part of the Endpoint feature. This Endpoint feature is in Bugzilla already but I created another one for this issue specifically (BZ #1584). Comarch released CTT v1.5.3!!! (thanks, Jacek). It fixes several of the issues that have been found below. From Comarch: OCF CTT Release Version 1.5.3 (2017-03-27) Notes: 1. CTT 1.5.3 has been released to OCF members as an interim release version of the tool and can be used ONLY for testing purposes. 2. Implemented features - Schema updates - CT5.2.1.2 ? piid value added to the simulator - CT5.2.1.3 ? timeout value updated to 72 - Update for Check_4 in CT1.1.1 ? introspection resource added - Update for Check_1 in CT5.2.1.6 ? Yes/No update - Endpoint test ? href validation added - Fix for ?range? updating values 3. Fixed issues: - Fix for #1550 (Update Device Map Schema (JSON) with OCF 1.0 Devices), - Fix for #1567 (CTT - Change NULL UUID to "nil UUID"). Antu, can you please run IoTivity master against this latest version of the CTT? Additional comments below. Mitch From: Jacek Hryszkiewicz [ <mailto:jacek.hryszkiewicz at comarch.com> mailto:[email protected]] Sent: Monday, March 27, 2017 3:55 AM To: 'Mitch Kettrick'; 'Heldt-Sheller, Nathan'; 'Daniel Mihai'; <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com Cc: 'Mark Trayer'; 'Wouter van der Beek'; 'Craig Pratt'; 'jongmin choi'; 'Uze Choi'; 'Vamshi Kandalla'; 'Morrow, Joseph L'; 'Ofer Rotschield'; 'Malsbary, Todd'; 'Diego Bartolom? Arquillo'; 'Daeken Kwon'; 'Agis, Ed'; 'Jason Smith'; 'Peter Moonki Hong'; 'DWARKAPRASAD DAYAMA'; 'Towhidul Islam'; 'Sam-Hak Jin'; 'Kaufman, David R '; 'JinHyeock Choi'; 'Bardini, Richard A'; 'Ziran Sun'; 'Srikrishna Gurugubelli'; 'Brian Scriber' Subject: RE: RE: RE: RE: RE: FW: CTT 1.5.2 - IoTivity master - Test Results Hi, There was a change in the schema file ?oic.wk.res-schema-ll.json? ??links? property was removed ? If this is how it should look like then please create an issue in the Bugzilla for that because new format of the response have to be handled properly in the CTT See other comments inline. Jacek From: Mitch Kettrick [ <mailto:cpm at openconnectivity.org> mailto:[email protected]] Sent: Friday, March 24, 2017 11:53 PM To: 'Heldt-Sheller, Nathan' < <mailto:nathan.heldt-sheller at intel.com> nathan.heldt-sheller at intel.com>; 'Daniel Mihai' < <mailto:Daniel.Mihai at microsoft.com> Daniel.Mihai at microsoft.com>; <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com Cc: 'Jacek Hryszkiewicz' < <mailto:jacek.hryszkiewicz at comarch.com> jacek.hryszkiewicz at comarch.com>; 'Mark Trayer' < <mailto:m.trayer at samsung.com> m.trayer at samsung.com>; 'Wouter van der Beek' < <mailto:wovander at cisco.com> wovander at cisco.com>; 'Craig Pratt' < <mailto:craig at ecaspia.com> craig at ecaspia.com>; 'jongmin choi' < <mailto:jminl.choi at samsung.com> jminl.choi at samsung.com>; 'Uze Choi' < <mailto:uzchoi at samsung.com> uzchoi at samsung.com>; 'Vamshi Kandalla' < <mailto:vkandalla at graniteriverlabs.com> vkandalla at graniteriverlabs.com>; 'Morrow, Joseph L' < <mailto:joseph.l.morrow at intel.com> joseph.l.morrow at intel.com>; 'Ofer Rotschield' < <mailto:ofer at tekoia.com> ofer at tekoia.com>; 'Malsbary, Todd' < <mailto:todd.malsbary at intel.com> todd.malsbary at intel.com>; 'Diego Bartolom? Arquillo' < <mailto:dbartolome at at4wireless.com> dbartolome at at4wireless.com>; 'Daeken Kwon' < <mailto:daeken.kwon at samsung.com> daeken.kwon at samsung.com>; 'Agis, Ed' < <mailto:Ed.Agis at intel.com> Ed.Agis at intel.com>; 'Jason Smith' < <mailto:lab_mgr at openconnectivity.org> lab_mgr at openconnectivity.org>; 'Peter Moonki Hong' < <mailto:moonki1.hong at samsung.com> moonki1.hong at samsung.com>; 'DWARKAPRASAD DAYAMA' < <mailto:dwarka.dayama at samsung.com> dwarka.dayama at samsung.com>; 'Towhidul Islam' < <mailto:t.islam at samsung.com> t.islam at samsung.com>; 'Sam-Hak Jin' < <mailto:j3s3h3.jin at samsung.com> j3s3h3.jin at samsung.com>; 'Kaufman, David R ' < <mailto:david.r.kaufman at honeywell.com> david.r.kaufman at honeywell.com>; 'JinHyeock Choi' < <mailto:jinchoe at samsung.com> jinchoe at samsung.com>; 'Bardini, Richard A' < <mailto:richard.a.bardini at intel.com> richard.a.bardini at intel.com>; 'Ziran Sun' < <mailto:ziran.sun at samsung.com> ziran.sun at samsung.com>; 'Srikrishna Gurugubelli' < <mailto:srikguru at microsoft.com> srikguru at microsoft.com>; 'Brian Scriber' < <mailto:b.scriber at cablelabs.com> b.scriber at cablelabs.com> Subject: RE: RE: RE: RE: RE: FW: CTT 1.5.2 - IoTivity master - Test Results Hi all, Thanks to everyone for taking a closer look at these issues. Comments below (check all the way down through several emails down to issue #27 for all of them). Comarch plans to release a new version of the CTT on Monday to correct as many of the CTT issues as possible. Hopefully we're able to close out some of the IoTivity bugs too. Have a great weekend! Mitch From: Heldt-Sheller, Nathan [ <mailto:nathan.heldt-sheller at intel.com> mailto:[email protected]] Sent: Friday, March 24, 2017 12:24 PM To: Daniel Mihai; Mitch Kettrick; <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com Cc: 'Jacek Hryszkiewicz'; Mark Trayer; 'Wouter van der Beek'; 'Craig Pratt'; jongmin choi; Uze Choi; 'Vamshi Kandalla'; Morrow, Joseph L; 'Ofer Rotschield'; Malsbary, Todd; 'Diego Bartolom? Arquillo'; Daeken Kwon; Agis, Ed; 'Jason Smith'; Peter Moonki Hong; DWARKAPRASAD DAYAMA; Towhidul Islam; Sam-Hak Jin; 'Kaufman, David R '; JinHyeock Choi; Bardini, Richard A; Ziran Sun; Srikrishna Gurugubelli; Brian Scriber Subject: RE: RE: RE: RE: RE: FW: CTT 1.5.2 - IoTivity master - Test Results Sorry I didn?t catch #11; it didn?t have my name so I skimmed past it! Dan is right: there is no requirement in the Spec that says setting the ?isOp? or ?tm? or ?cm? bits propagates to anything else? *** however *** Updating the new ?device onboarding state? Property in the OCF 1.0 Spec (pstat.dos) does in fact cause the Server to change some other values in a few cases. This state machine is not implemented yet! I have the change ready but I?m waiting on the merge of the pstat.dos Property ( <https://gerrit.iotivity.org/gerrit/#/c/17993/> https://gerrit.iotivity.org/gerrit/#/c/17993/) to push it. In short, device onboarding state feature from OCF 1.0 is still in progress (see <https://jira.iotivity.org/browse/IOT-1763> https://jira.iotivity.org/browse/IOT-1763). Until this JIRA is marked ?resolved?, don?t expect device state to work as spec?d in OCF 1.0! Side note: I haven?t read the latest TCs for managing device onboarding state, but in general, the CTT will need to set every Property then move the device to the new state via update to ?dos?; it should not set the ?dos? Property and expect the Server to update all the related Properties (there are a few exceptions, e.g. setting dos to RESET state, and the doxm ?isOp? Property, which is read-only and set by Server, for example). See the SVR definitions (section 13) for Property-by-Property, state-by-state definition of who sets each value. [MK] Correct. The CTT does not comprehend pstat.dos yet. It seems that some areas of the OCF 1.0 security code have been merged into IoTivity. A handful of changes have also been incorporated into a few test cases. On top of that, the Security TG has written 20+ test cases (some TCs may be combined in some cases) that are still in the process of being discussed between the Sec WG and Comarch. Once those are implemented, we'll have a lot of new logs to analyze, issues to resolve, etc. In summary, we're in this funky state where we're straddling OIC v1.1 and OCF 1.0 with both IoTivity and the CTT/CTR. I expect things to get worse before they get better with respect to the security TCs as IoTivity is updated, new schema files for the SVRs are merged and new test cases are implemented in the CTT. Nathan, should we set up a distribution list for the Security issues that we find while testing? Should it be the OSWG Security TG mailing list? We may also want to start having that meeting weekly pretty soon so that we can discuss any open issues more frequently. Thanks, Nathan From: Daniel Mihai [ <mailto:Daniel.Mihai at microsoft.com> mailto:[email protected]] Sent: Friday, March 24, 2017 9:59 AM To: Mitch Kettrick < <mailto:cpm at openconnectivity.org> cpm at openconnectivity.org>; <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com Cc: 'Jacek Hryszkiewicz' < <mailto:jacek.hryszkiewicz at comarch.com> jacek.hryszkiewicz at comarch.com>; Mark Trayer < <mailto:m.trayer at samsung.com> m.trayer at samsung.com>; 'Wouter van der Beek' < <mailto:wovander at cisco.com> wovander at cisco.com>; Heldt-Sheller, Nathan < <mailto:nathan.heldt-sheller at intel.com> nathan.heldt-sheller at intel.com>; 'Craig Pratt' < <mailto:craig at ecaspia.com> craig at ecaspia.com>; jongmin choi < <mailto:jminl.choi at samsung.com> jminl.choi at samsung.com>; Uze Choi < <mailto:uzchoi at samsung.com> uzchoi at samsung.com>; 'Vamshi Kandalla' < <mailto:vkandalla at graniteriverlabs.com> vkandalla at graniteriverlabs.com>; Morrow, Joseph L < <mailto:joseph.l.morrow at intel.com> joseph.l.morrow at intel.com>; 'Ofer Rotschield' < <mailto:ofer at tekoia.com> ofer at tekoia.com>; Malsbary, Todd < <mailto:todd.malsbary at intel.com> todd.malsbary at intel.com>; 'Diego Bartolom? Arquillo' < <mailto:dbartolome at at4wireless.com> dbartolome at at4wireless.com>; Daeken Kwon < <mailto:daeken.kwon at samsung.com> daeken.kwon at samsung.com>; Agis, Ed < <mailto:Ed.Agis at intel.com> Ed.Agis at intel.com>; 'Jason Smith' < <mailto:lab_mgr at openconnectivity.org> lab_mgr at openconnectivity.org>; Peter Moonki Hong < <mailto:moonki1.hong at samsung.com> moonki1.hong at samsung.com>; DWARKAPRASAD DAYAMA < <mailto:dwarka.dayama at samsung.com> dwarka.dayama at samsung.com>; Towhidul Islam < <mailto:t.islam at samsung.com> t.islam at samsung.com>; Sam-Hak Jin < <mailto:j3s3h3.jin at samsung.com> j3s3h3.jin at samsung.com>; 'Kaufman, David R ' < <mailto:david.r.kaufman at honeywell.com> david.r.kaufman at honeywell.com>; JinHyeock Choi < <mailto:jinchoe at samsung.com> jinchoe at samsung.com>; Bardini, Richard A < <mailto:richard.a.bardini at intel.com> richard.a.bardini at intel.com>; Ziran Sun < <mailto:ziran.sun at samsung.com> ziran.sun at samsung.com>; Srikrishna Gurugubelli < <mailto:srikguru at microsoft.com> srikguru at microsoft.com>; Brian Scriber < <mailto:b.scriber at cablelabs.com> b.scriber at cablelabs.com> Subject: Re: RE: RE: RE: RE: FW: CTT 1.5.2 - IoTivity master - Test Results Mitch, for #11, did you mean that /doxm property values should automatically change when posting values {"cm": 0, "tm": 0, "isop": false} to /pstat? [MK] As Nathan said, this is behavior that is specified in CR32. In this test case, the Device is put into RFOTM and CR32 specified that the "isop" Property shall be FALSE. Looking at the test case, it says: Step 34: For OCF v1.0 and newer Devices, CTT puts the Device into RFOTM state. As Nathan said, there is no way to do this directly and we haven't told Comarach exactly what "put the Device into RFOTM state" means or how to do it. That is one thing that is on my plate to add to the test spec: how to manage all of the device transitions specified in CR32. Ned has a presentation about what it means but the work still has to be done to add it to the CTR/CTT. So after digging a bit more, this is a CTR (i.e. test spec) issue at the moment but since this hasn't been implemented in IoTivity yet, we're again straddling OIC v1.1 and OCF 1.0 behavior. Things will start to get complicated if we make changes now and then end up having to back out specific security CRs that don't get implemented in time. It's going to be a balancing act. a. If yes, please point me to the Security spec text mandating that kind of transition. I don't remember such mandate, but it is very possible that I don't remember it. Even if it is in the spec, I don't remember seeing anyone implement that kind of transition in IoTivity (but, I don't always get a heads-up about IoTivity changes, so I might have missed such changes). b. If no, please point me to the latest spec for CT1.7.2.1 . Dan From: Muhammad Mushfiqul Islam < <mailto:i.mushfiq at samsung.com> [email protected]> Sent: Friday, March 24, 2017 4:00 AM To: Mitch Kettrick Cc: 'Jacek Hryszkiewicz'; Mark Trayer; 'Wouter van der Beek'; 'Heldt-Sheller, Nathan'; 'Craig Pratt'; jongmin choi; Uze Choi; 'Vamshi Kandalla'; 'Morrow, Joseph L'; 'Ofer Rotschield'; 'Malsbary, Todd'; 'Diego Bartolom? Arquillo'; Daeken Kwon; Daniel Mihai; 'Ed Agis'; 'Jason Smith'; Peter Moonki Hong; DWARKAPRASAD DAYAMA; Towhidul Islam; Sam-Hak Jin; 'Kaufman, David R '; JinHyeock Choi; Muhammad Mushfiqul Islam; 'Richard Bardini'; Ziran Sun; Srikrishna Gurugubelli; Brian Scriber Subject: FW: RE: RE: RE: RE: FW: CTT 1.5.2 - IoTivity master - Test Results Dear Mitch, Thanks for your feedback. I am attaching the PICS I used for testing. Please ignore my previous reply. Please find my inline replies. - Thanks & Regards, Mushfiqul Islam Antu --------- Original Message --------- Sender : Mitch Kettrick <cpm at openconnectivity.org> Date : 2017-03-24 05:28 (GMT+6) Title : RE: RE: RE: FW: CTT 1.5.2 - IoTivity master - Test Results To : null<jacek.hryszkiewicz at comarch.com>, Muhammad Mushfiqul Islam<i.mushfiq at samsung.com>, Mark Trayer<m.trayer at samsung.com>, null<wovander at cisco.com>, null<nathan.heldt-sheller at intel.com>, null<craig at ecaspia.com>, null<Daniel.Mihai at microsoft.com>, jongmin choi<jminl.choi at samsung.com> CC : Uze Choi<uzchoi at samsung.com>, null<vkandalla at graniteriverlabs.com>, null<joseph.l.morrow at intel.com>, null<ofer at tekoia.com>, null<todd.malsbary at intel.com>, null<dbartolome at at4wireless.com>, Daeken Kwon<daeken.kwon at samsung.com>, null<Daniel.Mihai at microsoft.com>, null<Ed.Agis at intel.com>, null<lab_mgr at openconnectivity.org>, Peter Moonki Hong<moonki1.hong at samsung.com>, DWARKAPRASAD DAYAMA<dwarka.dayama at samsung.com>, Towhidul Islam<t.islam at samsung.com>, Sam-Hak Jin<j3s3h3.jin at samsung.com>, null<david.r.kaufman at honeywell.com>, JinHyeock Choi<jinchoe at samsung.com>, null<richard.a.bardini at intel.com>, Ziran Sun<ziran.sun at samsung.com>, srikguru at microsoft.com, null<b.scriber at cablelabs.com> NOTE: The previous email was sent before I was done editing it. Please respond to this version. Hi Antu, Thanks for running these and performing an initial analysis. Can you please include the PICS in the zip file you send? That would help debug some of the issues we're seeing. Jacek, for every CTT bug, I'll open an item in Bugzilla so that we can track them. After your investigation, let me know which ones are CTT bugs and I'll open a BZ issue for them. Antu, I'm assigning all IoTivity issues to you. I know that you won't be addressing all of them but maybe you (or Uze?) can hand them out to the correct IoTivity implementers. Thanks. Until we have new schema files and several of the new Security CRs have been implemented, I don't think it makes sense to spend too much time reviewing the majority of the failures in the Security test cases. It seems like the device is still compliant with the way things were done in OIC v1.1. Executive Summary: ? 4 old items closed ? 14 new items opened ? 23 total items open We're slowly peeling the onion. We still have a long way to go? NEW ACTION ITEMS: 1. CT1.1.1: I noticed this in the log file: 0.037s 10:55:02 VERBOSE:?-> 192.168.56.1:49227->224.0.1.187:5683 NON-GET ID=44120, Token=64F7D133, Options=[URI-Path=oic, res, Accept=application/cbor], Since this is an OCF 1.0 Device (i.e. "icv": "ocf.1.0.0"), the Accept Option should be application/vnd.ocf+cbor. If the CTT uses this Accept Option, the IUT should respond appropriately. Since "di" is in the response in a GET /oic/res, the CTT should have flagged an error if it is using the OCF 1.0 schema file definitions. What is needed in the PICS to make this work properly? Does the test case need to be updated to state that it should be run using the latest Content-Format and Content-Format Version supported by the IUT? ACTION: Jacek [JH] 1. This request is from rediscovery phase which I think must be application/cbor (?di? value required in the response) 2. We have to clarify what Accept Option value CTT should use. In my opinion test cases need to be updated (another loop for different Accept Option value). We cannot test only application/vnd.ocf+cbor for ocf.1.0.0 ? we have to test both values. [MK] I'm not sure that it makes sense to test every single Content Format in every single test case. We have very specific test cases for the Versioning feature. I don't see a reason to test that again in CT1.1.1. I will start a separate thread on this but my opinion is that we should only test the newest Content-Format and Content-Format version supported by the IUT on all test cases other than the Versioning test case. 2. CT1.1.1: The schema file issue regarding "pri" and "1" vs. 1 is fixed in the master branch on Git. Please download the latest version of the oic link schema file. ACTION: Jacek [JH] Newest schema files updated in the CTT 1.5.3 3. CT1.1.1: There looks to be an IoTivity bug related to the Default Interface. When the CTT sends GET /oic/res?rt=oic.r.temperature, the Device should respond using the oic.if.a (or oic.if.s) Interface since that is the Default Interface for oic.r.temperature. It looks like the Device is responding using the baseline Interface. ACTION: Antu [Antu]: Should the reply follow interface of oic.r.temperature resource? As the query is made to /oic/res, should not the response follow default interface of /oic/res? Current response is: [ { "di": "6a757374-776f-726b-4465-765575696430", "links": [ { "href": "/TemperatureResURI", "rt": [ "oic.r.temperature" ], "if": [ "oic.if.baseline", "oic.if.a" ], "p": { "bm": 3, "sec": true, "port": 54279 }, "eps": [{"ep": "coap://192.168.56.101:41268","pri": 1}, { "ep": "coaps://192.168.56.101:54279", "pri": 1 }, { "ep": "coap://[fe80::36bc:ba82:adf0:c83a]:0", "pri": 1 }, { "ep": "coaps://[fe80::36bc:ba82:adf0:c83a]:0", "pri": 1 } ] } ] }] I think this response is fine, as there is no rt & if in the scope of /oic/res. rt & if info inside links is out of scope of this query. Also, if the client does not know which interfaces a resource support, how can it make a proper GET request? [MK] My bad. You're rightWwe're in this funky state where the CTT has OCF 1.0 schema files but the Device is responding with a Content Format of "application/cbor". Maybe this problem will go away once Jacek looks into issue #1? Let's wait and see if this error goes away. 4. CT1.1.1: In looking through the logs, it appeared that the Device was responding twice to several of the multicast request messages. This isn't a failure per se and the CTT didn't catch it? but I did. J I confirmed in Wireshark that the Device is responding twice for some reason as seen in the screenshot below. ACTION: Antu [Antu]: Yes, you are right. But the problem is, I am unable to reproduce the problem other than CTT. I checked IoTivity <-> IoTivity & IoTivity <-> Copper plugin. In both cases, I am getting only one response from the server. I used same request packet as in this example below, still no luck. I will dig down this issue more if I get time. [MK] I went back to testing done on CT 1.3.26 and this problem wasn't there at that time. This problem may go away when the CTT starts sending an Accept Option of "application/ vnd.ocf_cbor" but I hope that we're able to solve it. Are you using "rt" queries when you're doing the IoTivity <-> IoTivity tests? From my review of the logs, it appears to only happen in response to multicast request messages; unicast is working normally. cid:image002.jpg at 01D2A986.96674DB0 5. CT1.1.1: This looks like a CTT issue: CT1.1.1_Check_36: Verification with ID "CT1.1.1_Check_36" threw the exception: validate_rt_not_start_with_oic_if_not_defined() takes exactly 2 arguments (1 given) ACTION: Jacek [JH] Fixed in CTT 1.5.3 6. CT1.1.1: You did not include the PICS that you used for testing but this error looks odd: 309.574s 11:00:12 ERROR:?CT1.1.1_Check_35: IUT does not expose the sensor interface as the Default Interface for the binary switch Resource. {'if': ['oic.if.a', 'oic.if.baseline'], 'di': '6A757374-776F-726B-4465-765575696430'... 309.574s 11:00:12 DEBUG:?continued: ..., 'rt': ['oic.r.switch.binary'], 'href': '/BinarySwitchResURI/Child', 'p': {'bm': 2, 'port': 54279, 'sec': True}} IUT exposes actuator Interface. Did you set the "jurisdictionSwitch": true in the PICS? Otherwise, oic.if.a is the correct Default Interface for oic.r.switch.binary. ACTION: Antu [Antu]: Yes, I used "jurisdictionSwitch": true in PICS. Should I change it to false to make the binary switch as actuator? [MK] You can do it either way. If you set "jurisdictionSwitch": true, then you can only sense so you should be exposing "oic.if.s" and not "oic.if.a" like the log above. If you change it to false, then exposing oic.if.a like you did is correct. So change one or the other but not both. 7. CT1.2.2: The response to GET Vendor/AirConditioner/TimerClock?if=oic.if.baseline did not include the "rt" or "if" Properties. ACTION: Antu [Antu]: If you remember, this is a very old issue. from IUT side, there is absolutely no reason why a single resource will act differently than the other resource. And this /AirConditioner/TimerClock resource is the only slow response resource in IUT. While I check manually, there is always rt & if present in baseline query GET response. Probably a timing related issue in CTT, but I am not sure. If you check the CTT log, the actuator GET response has rt & if. So. It seems to me that these 2 response are swapped at CTT side. But again, I am not sure. [MK] Very cool. I hadn't noticed that you were testing slow response. Great work! Looking at the logs, it seemed to pass for confirmable requests and fail for non-confirmable requests. Here is the log in question: 125.678s 11:02:45 INFO:?Sending unicast NON RETRIEVE request with: /Vendor/AirConditioner/TimerClock?if=oic.if.baseline 125.678s 11:02:45 VERBOSE:?-> 192.168.56.1:49232->192.168.56.101:54279 NON-GET ID=57725, Token=3ECC33B2, Options=[URI-Port=54279, URI-Path=Vendor, AirConditioner, TimerClock, URI-Query=if=oic.if.baseline, Accept=application/cbor], Secured=true 126.210s 11:02:46 INFO:?Prompting "Waiting for CoAP response... " 135.666s 11:02:55 VERBOSE:?<- 192.168.56.101:54279->192.168.56.1:49232 NON-2.05 Content ID=57725, Token=3ECC33B2, Options=[URI-Path=Vendor, AirConditioner, TimerClock, Content-Type=application/cbor], Secured=true 135.666s 11:02:55 VERBOSE:?<- {"x.com.vendor.timer.hour":10,"x.com.vendor.timer.minute":30,"x.com.vendor.timer.reset":false,"x.com.vendor.timer.second":30} 135.666s 11:02:55 VERBOSE:?<- {"x.com.vendor.timer.hour":10,"x.com.vendor.timer.minute":30,"x.com.vendor.timer.reset":false,"x.com.vendor.timer.second":30} -snip- 135.679s 11:02:55 INFO:?Sending unicast NON RETRIEVE request with: /Vendor/AirConditioner/TimerClock?if=oic.if.a 135.680s 11:02:55 VERBOSE:?-> 192.168.56.1:49232->192.168.56.101:54279 NON-GET ID=57726, Token=3ECC33B3, Options=[URI-Port=54279, URI-Path=Vendor, AirConditioner, TimerClock, URI-Query=if=oic.if.a, Accept=application/cbor], Secured=true 135.686s 11:02:55 VERBOSE:?<- 192.168.56.101:54279->192.168.56.1:49232 NON-2.05 Content ID=57726, Token=3ECC33B3, Options=[URI-Path=Vendor, AirConditioner, TimerClock, Content-Type=application/cbor, Block2=0+ (1024B/block [6])], Secured=true 135.687s 11:02:55 VERBOSE:?-> 192.168.56.1:49232->192.168.56.101:54279 NON-GET ID=57727, Token=3ECC33B3, Options=[URI-Port=54279, URI-Path=Vendor, AirConditioner, TimerClock, URI-Query=if=oic.if.a, Accept=application/cbor, Block2=1 (1024B/block [6])], Secured=true 135.688s 11:02:55 VERBOSE:?<- 192.168.56.101:54279->192.168.56.1:49232 NON-2.05 Content ID=57727, Token=3ECC33B3, Options=[URI-Path=Vendor, AirConditioner, TimerClock, Content-Type=application/cbor, Block2=1 (1024B/block [6])], Secured=true 135.689s 11:02:55 VERBOSE:?<- {"rt":["x.com.vendor.timer"],"if":["oic.if.a","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline", "oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline", "oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline", "oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline", "oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline", "oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline", "oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline","oic.if.baseline"],"x.com.vendor.timer.hour":10,"x.com.vendor.timer.minute":30,"x.com.vendor.timer.reset":false,"x.com.vendor.timer.second":30} 136.401s 11:02:56 INFO:?Prompting "Waiting for CoAP response... " [MK] The tokens and message IDs for the request and response messages match. You'll notice that the response does not include "rt" or "if" with oic.if.baseline but it does include them with oic.if.r. I don't think it's an issue with the CTT. 8. CT1.2.3: The CTT is attempting to UPDATE the "range" Property and it expects the request to be successful. After a bit of digging, it turns out that the "range" Property is not defined as "readOnly": true. ACTION: Mark 9. CT1.2.3: Looking through the logs, I saw this, which needs to be corrected in the CTT. The new values should be different than the current values in an UPDATE request. ACTION: Jacek [JH] Fixed in CTT 1.5.3 7.280s 11:14:30 INFO:?Processing property named 'range' with old value '[10.01, 40.99]' 7.280s 11:14:30 INFO:?Sending unicast CON UPDATE request with query: /TemperatureResURI 7.280s 11:14:30 DEBUG:?CON UPDATE request body: {"range": [10.01, 40.99]} 7.280s 11:14:30 VERBOSE:?-> 192.168.56.1:49234->192.168.56.101:54279 CON-POST ID=55138, Token=7ECBC441, Options=[URI-Port=54279, URI-Path=TemperatureResURI, Content-Type=application/cbor, Accept=application/cbor], Secured=true 7.280s 11:14:30 VERBOSE:?-> {"range":[10.01,40.99]} 10. CT1.2.6: This test case did not run because the CTT could not rediscover the IUT. However, the "di" is unchanged from CT1.2.3 which ran immediately before this test case. ACTION: Jacek [JH] We will check that. It is strange because I see two responses from IUT: 0.026s 11:19:31 VERBOSE:?-> 192.168.56.1:49235->224.0.1.187:5683 NON-GET ID=36554, Token=063A55B6, Options=[URI-Path=oic, res, Accept=application/cbor], 0.039s 11:19:31 VERBOSE:?<- 192.168.56.101:41268->192.168.56.1:49235 NON-2.05 Content ID=36554, Token=063A55B6, Options=[URI-Path=oic, res, Content-Type=application/cbor, Block2=0+ (1024B/block [6])], 0.045s 11:19:31 VERBOSE:?-> 192.168.56.1:49235->192.168.56.101:41268 NON-GET ID=36555, Token=063A55B6, Options=[URI-Path=oic, res, Accept=application/cbor, Block2=1 (1024B/block [6])], 0.052s 11:19:31 VERBOSE:?<- 192.168.56.101:41268->192.168.56.1:49235 NON-2.05 Content ID=36554, Token=063A55B6, Options=[URI-Path=oic, res, Content-Type=application/cbor, Block2=0+ (1024B/block [6])], 0.069s 11:19:31 VERBOSE:?<- 192.168.56.101:41268->192.168.56.1:49235 NON-2.05 Content ID=36555, Token=063A55B6, Options=[URI-Path=oic, res, Content-Type=application/cbor, Block2=1+ (1024B/block [6])], 0.069s 11:19:31 VERBOSE:?-> 192.168.56.1:49235->192.168.56.101:41268 RST-Empty Message ID=36555, Token=, Options=[], Could you please create a Bugzilla issue for that? [MK] Done ? BZ #1583 cid:image003.jpg at 01D2A986.96674DB0 11. In CT1.7.2.1 there is this failure: 5.916s 10:39:35 ERROR: Device is owned but expected to be unowned There seems to be an issue with the code not lining up to the latest security spec. The CTT is expecting the Device to go from "owned": true to "owned": false when put into RFOTM. The Device is not doing that. We need someone from the Sec WG who understands the updated onboarding sequence to check both the test case and the logs to see what needs to be changed. ACTION: Dan, can you take this one since you've been writing CRs to the onboarding sequence? 12. There is a default ACE that looks like below. Why is there a wildcard for the "rt" value? ACTION: Jong-Min/Antu {"subjectuuid":"*","resources":[{"href":"/oic/res","rt":["oic.wk.res"],"if":["oic.if.ll"],"rel":""},{"href":"/oic/d","rt":["oic.wk.d"],"if":["oic.if.baseline","oic.if.r"],"rel":""}, {"href":"/oic/p","rt":["oic.wk.p"],"if":["oic.if.baseline","oic.if.r"],"rel":""},{"href":"/oic/introspection","rt":["oic.wk.introspection"],"if":["oic.if.baseline","oic.if.r"],"rel":""}, {"href":"/oic/introspection/payload","rt":["*"],"if":["oic.if.baseline","oic.if.r"],"rel":""}],"permission":2} [Antu]: Actually I coud not find the resource type of this resource, so I added "*" so that whatever the resource type is, the server does not block the client. [MK] In the past, I've seen the "rt" blank (i.e. "rt":[""]). I think putting an "*" in there is wrong. 13. Endpoint test case: When CTT sends a GET with an Accept Option of "application/vnd.ocf_cbor", the IUT should respond with a response the complies with OCF 1.0. ACTTION: Antu [Antu]: I raise Jira issue for this 14. Endpoint test case: There was an exception thrown. Please investigate. ACTION: Jacek [JH] Fixed in CTT 1.5.3 OLD ACTION ITEMS: 15. It seems as though the CTT has an older version of the oic.oic-link-schema.json file. The file used by the CTT still has the "sec" and "port" Parameters. ACTION: Jacek [JH] We will update the schema file. We did not do that before because issue #1496 is not resolved. [MK] Bug 1496 is related to updating the test checks that verify the "sec" and "port" flags. The CTT should always pull in the latest schema files from the master branch in Git (a few caveats below). [JH] Updated in CTT 1.5.3 16. The "icv" Property of the IUT is still "core.1.1.0" so the CTT thinks its testing an OIC v1.1 Device. The "icv" should be "ocf.1.0.0". This should also be declared in the PICS. That is likely why ACTION: Antu CLOSED 17. oic.wk.introspectionInfo.json is in the OIC v1.1 folder for the CTT; it should not be there. Need to make sure that all of the OIC v1.1 schema files are from the tagged schemas in Git. ACTION: Jacek [JH] I will remove the introspection file from OIC1.1 directory. Please note that introspection related files are not in the OCF github ? should be added. [MK] Agreed. They were just moved to github today. Thanks, Mark and Richard. [JH] Updated in CTT 1.5.3 18. CT1.1.1 The Introspection Resource URI cannot start with "/oic" or "/ocf" which violates the OCF namespace. In other words, Introspection shall not use a well-known, pre-defined URI. ACTION: Antu [Antu]: I raise Jira issue for this 19. The Device is still returning the OIC v1.1 response for /oic/res ({"di":"6a757374-776f-726b-4465-765575696430","links"?). The "di" was removed for OCF 1.0. Is the Device configured as an OCF 1.0 Device? ACTION: Antu. [MK] This looks to be a CTT issue. See new issue #1 above. CLOSED. 20. CT1.2.2: I don't see the Property "name" in the Introspection Resource Type schema I have. I looked for the official file in Git but couldn't find it. Why is this Property there? ACTION: Antu [Antu]: I raise Jira issue for this 21. CT1.2.2: The Introspection RAML file does not call out "if": "oic.if.r" but it is in the spec. The RAML file needs to be updated. ACTION: Wouter 22. CT1.2.2: The CTT is complaining about "rt" and "if" on the Introspection Resource in CT1.2.2 which should be fine. At least I don't see any problems. ACTION: Jacek [JH] Could anybody please send me the full CTT result log file? [MK] I sent the log files to Jacek. These same failure show up in the current logs too. [JH] Problem related to missing schema for introspection for oic.if.r 23. CT1.2.2: The "piid" failure is because the CTT thinks the Device is OIC v1.1. Update "icv" Property value as described above. ACTION: Antu CLOSED. This failure went away after Antu updated the "icv" as expected. 24. CT1.2.2: Same problem with the "deviceuuid" Property of /pstat; it was removed in OCF 1.0. The CTT expects this Property to be there because it thinks it's interacting with an OIC v1.1 Device. (NOTE: the new OCF 1.0 SVR schema files have not been moved to master yet so this error won't go away until that happens). ACTION: Nathan/Craig? [MK] This issue did not go away as anticipated in the NOTE. We need updated RAML files for the SVRs. 25. CT1.7.2.1: The "devowneruuid" issue is being tracked by Bug 1541. The test cases still needs be updated though. ACTION: Mitch (I have to take at least one action, right? J) [MK] This issue was fixed today via CWG CR 0051. It now has to be integrated into the CTT per Bug 1567. ACTION: Jacek [JH] Updated in CTT 1.5.3 26. The issues with Introspection are being worked by Wouter and Sri (the implementer of that feature) which is being tracked in another email thread. ACTION: Wouter 27. The Versioning issue is likely being caused by an incorrect "icv" value. Update to "core.1.1.0" and re-run. ACTION: Antu CLOSED Thanks, Mitch From: Jacek Hryszkiewicz [ <mailto:jacek.hryszkiewicz at comarch.com> mailto:[email protected]] Sent: Thursday, March 23, 2017 4:02 AM To: <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com; 'Mitch Kettrick' Cc: 'Wouter van der Beek'; 'Uze Choi'; 'Heldt-Sheller, Nathan'; 'Craig Pratt'; 'Vamshi Kandalla'; 'Morrow, Joseph L'; 'Ofer Rotschield'; 'Malsbary, Todd'; 'Diego Bartolom? Arquillo'; 'Daeken Kwon'; 'Daniel Mihai'; 'jongmin choi'; 'Ed Agis'; 'Jason Smith'; 'Peter Moonki Hong'; 'DWARKAPRASAD DAYAMA'; 'Towhidul Islam'; 'Sam-Hak Jin'; 'Kaufman, David R '; 'Mark Trayer'; 'JinHyeock Choi'; 'Richard Bardini'; 'Ziran Sun'; <mailto:srikguru at microsoft.com> srikguru at microsoft.com Subject: RE: RE: RE: FW: CTT 1.5.2 - IoTivity master - Test Results One update ? see below. Jacek Hryszkiewicz From: Jacek Hryszkiewicz [ <mailto:jacek.hryszkiewicz at comarch.com> mailto:[email protected]] Sent: Thursday, March 23, 2017 10:54 AM To: 'i.mushfiq at samsung.com' < <mailto:i.mushfiq at samsung.com> i.mushfiq at samsung.com>; 'Mitch Kettrick' < <mailto:cpm at openconnectivity.org> cpm at openconnectivity.org> Cc: 'Wouter van der Beek' < <mailto:wovander at cisco.com> wovander at cisco.com>; 'Uze Choi' < <mailto:uzchoi at samsung.com> uzchoi at samsung.com>; 'Heldt-Sheller, Nathan' < <mailto:nathan.heldt-sheller at intel.com> nathan.heldt-sheller at intel.com>; 'Craig Pratt' < <mailto:craig at ecaspia.com> craig at ecaspia.com>; 'Vamshi Kandalla' < <mailto:vkandalla at graniteriverlabs.com> vkandalla at graniteriverlabs.com>; 'Morrow, Joseph L' < <mailto:joseph.l.morrow at intel.com> joseph.l.morrow at intel.com>; 'Ofer Rotschield' < <mailto:ofer at tekoia.com> ofer at tekoia.com>; 'Malsbary, Todd' < <mailto:todd.malsbary at intel.com> todd.malsbary at intel.com>; 'Diego Bartolom? Arquillo' < <mailto:dbartolome at at4wireless.com> dbartolome at at4wireless.com>; 'Daeken Kwon' < <mailto:daeken.kwon at samsung.com> daeken.kwon at samsung.com>; 'Daniel Mihai' < <mailto:Daniel.Mihai at microsoft.com> Daniel.Mihai at microsoft.com>; 'jongmin choi' < <mailto:jminl.choi at samsung.com> jminl.choi at samsung.com>; 'Ed Agis' < <mailto:Ed.Agis at intel.com> Ed.Agis at intel.com>; 'Jason Smith' < <mailto:lab_mgr at openconnectivity.org> lab_mgr at openconnectivity.org>; 'Peter Moonki Hong' < <mailto:moonki1.hong at samsung.com> moonki1.hong at samsung.com>; 'DWARKAPRASAD DAYAMA' < <mailto:dwarka.dayama at samsung.com> dwarka.dayama at samsung.com>; 'Towhidul Islam' < <mailto:t.islam at samsung.com> t.islam at samsung.com>; 'Sam-Hak Jin' < <mailto:j3s3h3.jin at samsung.com> j3s3h3.jin at samsung.com>; 'Kaufman, David R ' < <mailto:david.r.kaufman at honeywell.com> david.r.kaufman at honeywell.com>; 'Mark Trayer' < <mailto:m.trayer at samsung.com> m.trayer at samsung.com>; 'JinHyeock Choi' < <mailto:jinchoe at samsung.com> jinchoe at samsung.com>; 'Richard Bardini' < <mailto:richard.a.bardini at intel.com> richard.a.bardini at intel.com>; 'Ziran Sun' < <mailto:ziran.sun at samsung.com> ziran.sun at samsung.com>; 'srikguru at microsoft.com' < <mailto:srikguru at microsoft.com> srikguru at microsoft.com> Subject: RE: RE: RE: FW: CTT 1.5.2 - IoTivity master - Test Results Dear All, Please find my comments below. Best Regards, -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170418/7c8b2581/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 823 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170418/7c8b2581/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 344 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170418/7c8b2581/attachment-0001.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.jpg Type: image/jpeg Size: 2557 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170418/7c8b2581/attachment-0002.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image004.jpg Type: image/jpeg Size: 4778 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170418/7c8b2581/attachment-0003.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.gif Type: image/gif Size: 13402 bytes Desc: ?????? ?? ????????. URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170418/7c8b2581/attachment.gif>
