Hi All, This is a bug in the samples but after evaluating this a little more there are two different paths we could take.
1. Update the samples to handle the path argument correctly in their client_open/server_open callbacks. 2. Add new APIs around persistent storage so that device properties can be handled separately from security. Does anyone know of any applications that will be impacted by this issue? I can update the IoTivity samples but not outside applications. If there are not any applications that will be impacted (or they can easily be updated and there is no objection), I can update the samples and add some comments around client_open/server_open to clarify handling different databases so that we can avoid this issue going forward. Otherwise I will look into option two. Thanks, Alex From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Alex Kelley via iotivity-dev Sent: Tuesday, March 14, 2017 10:57 AM To: Thomas Lea <tlea at icontrol.com>; i.mushfiq at samsung.com; Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com> Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] svr db, static provisioning - help needed Hi All, Thomas is correct. I thought the client_open/server_open functions in samples had been updated to accommodate the path similar to mediaserver.cpp but it appears a few have slipped through. Please assign the ticket to me and I will update the samples. Thanks, Alex From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Thomas Lea Sent: Tuesday, March 14, 2017 5:20 AM To: i.mushfiq at samsung.com<mailto:i.mushfiq at samsung.com>; Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com<mailto:nathan.heldt-sheller at intel.com>> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] svr db, static provisioning - help needed FYI, this will happen if the fopen function registered via OCRegisterPersistentStorageHandler does not honor the path (first argument) and blindly always opens the same file. Before the addition of the device properties data, it was ok to ignore path since it was always the same svr db path. Regards, Thomas Lea From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Muhammad Mushfiqul Islam Sent: Tuesday, March 14, 2017 12:36 AM To: Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com<mailto:nathan.heldt-sheller at intel.com>> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] svr db, static provisioning - help needed Hello, I investigated the issue, and it looks like, as soon as a server starts, it is changing the existing database file. First time, the server is loading the database, and immediately changing it, but working ok, as the initial database is fine. From the next time, it is using the changed database, so unable to handle incoming requests and hence sending 4.01 to all requests. The changed database is(66 byte): {_ "DeviceProperties": { "piid": "fa008167-3bbf-4c9d-8604-c9bcb96cb712"} } Which was initially(1.2 KB): {_ "acl": {"aclist": {"aces": [{"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/sec/acl", "rt": ["oic.r.acl"], "if": ["oic.if.baseline"], "rel": ""}], "permission": 2}, {"subjectuuid": "*", "resources": [{"href": "/oic/sec/doxm", "rt": ["oic.r.doxm"], "if": ["oic.if.baseline"], "rel": ""}, {"href": "/oic/sec/pstat", "rt": ["oic.r.pstat"], "if": ["oic.if.baseline"], "rel": ""}], "permission": 2}, {"subjectuuid": "*", "resources": [{"href": "/a/light", "rt": ["oic.core"], "if": ["oic.if.baseline"], "rel": ""}], "permission": 7}]}, "rowneruuid": "31313131-3131-3131-3131-313131313131", "rt": ["oic.r.acl"], "if": ["oic.if.baseline"]}, "pstat": {"isop": true, "cm": 0, "tm": 0, "om": 4, "sm": 4, "deviceuuid": "31313131-3131-3131-3131-313131313131", "rowneruuid": "31313131-3131-3131-3131-313131313131", "rt": ["oic.r.pstat"], "if": ["oic.if.baseline"]}, "doxm": {"oxms": [0], "oxmsel": 0, "sct": 1, "owned": true, "deviceuuid": "31313131-3131-3131-3131-313131313131", "devowneruuid": "32323232-3232-3232-3232-323232323232", "rowneruuid": "31313131-3131-3131-3131-313131313131", "rt": ["oic.r.doxm"], "if": ["oic.if.baseline"]}, "cred": {"creds": [{"credid": 1, "subjectuuid": "32323232-3232-3232-3232-323232323232", "credtype": 1, "privatedata": {"encoding": "oic.sec.encoding.raw", "data": h'41414141414141414141414141414141'}}], "rowneruuid": "31313131-3131-3131-3131-313131313131", "rt": ["oic.r.cred"], "if": ["oic.if.baseline"]} } This is a new issue in maser branch, I will raise a Jira ticket. - Thanks & Regards, Mushfiqul Islam Antu --------- Original Message --------- Sender : Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com<mailto:nathan.heldt-sheller at intel.com>> Date : 2017-03-14 05:44 (GMT+6) Title : Re: [dev] svr db, static provisioning - help needed To : null<dev at mobileink.com<mailto:dev at mobileink.com>>, null<thiagogcm at gmail.com<mailto:thiagogcm at gmail.com>> CC : null<iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>> Hi Thiago, Sorry for the slow reply, many of us were at the OCF All Members meeting in Amsterdam last week. Did you try running the security sample apps (see resource/csdk/security/README-building-and-running-secure-IoTivity-stack.txt)? I?m using commit 26756ec1431cb45ed877255ea53f74745c9ad2f9 and not having any issues like you describe. I?ve only tested the Debug build ($ scons RELEASE=0) on Linux, maybe try the above commit and applications to establish a baseline? Thanks, Nathan Heldt-Sheller Intel Corp. OSWG Security TG Chair From: Gregg Reynolds [mailto:[email protected]] Sent: Monday, March 13, 2017 2:02 PM To: Thiago Moura <thiagogcm at gmail.com<mailto:thiagogcm at gmail.com>> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com<mailto:nathan.heldt-sheller at intel.com>> Subject: Re: [dev] svr db, static provisioning - help needed hi thiago On Mar 11, 2017 8:28 PM, "Thiago Moura" <thiagogcm at gmail.com<mailto:thiagogcm at gmail.com>> wrote: Hi I am facing a similar problem with current master branch when I run simpleclient and simpleserver it works as expected, if I run again it throws error 46 (OC_STACK_UNAUTHORIZED_REQ<https://api-docs.iotivity.org/latest-c/octypes_8h.html#a8fc7163f720a1c3eb9beecb037a2c245a522cbc86d1d2b2f77215482e1aaaee99>). The stack is somehow overriding the .dat file.. If I restore the original file everything works again. On 1.2-rel (SECURED=1) it works fine across multiple executions Am I missing something or should I create a ticket on JIRA? unfortunately i cannot offer a solution, just wanted you to know you're not being ignored. i came across sth like this months ago but don't remember how i fixed it. :(. i hope to get back to iotivity Real Soon Now, but it might be a few days. g _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev [cid:image001.gif at 01D29CBD.BB926050] [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=i.mushfiq&do=bWFpbElEPTIwMTcwMzE0MDUzNjE0ZXBjbXMxcDE0OWIwNjczOTdiMWNlNjBlYjEyMGRiNDM1ZmE1MTRhZSZyZWNpcGllbnRBZGRyZXNzPWlvdGl2aXR5LWRldkBsaXN0cy5pb3Rpdml0eS5vcmc_] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170314/6cdf0012/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13402 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170314/6cdf0012/attachment.gif>
