Secure provisioning tool broken (maybe only sample app) (#100) · Issues · IoTivity / iotivity-classic

Secure provisioning tool broken (maybe only sample app)

are broken. I’m working off the 1.1-rel branch.
I want to be able to 1) take ownership of both simpleclient and

simpleserver using “Just Works", 2) Provision credentials between

simpleclient and simpleserver, and 3) Provision ACLs.
Both samples seem to be configured via the persistent storage interface

to support security; so I expect 1), 2) and 3) above to just work

using the two available provisioning tools, but neither work.
In all tests below, I’m using

resource/provisioning/examples/provisioningclient

, with its PDM.db deleted and a fresh oic_svr_db_client.dat each time, for

consistency sake.
Here are some observations:

to start afresh (I assume they’ll get recreated), I run each of the apps

separately along with the provisioning tool, and can discover them, but

receive the “Error!!! in OwnershipTransfer” message.
2) If I however copy the prebuilt

resource/csdk/security/provisioning/sample/oic_svr_db_svr_justworks.dat

into either oic_svr_db_client/server.dat, and again separately run

the samples with the tool, I am able to discover them as un-owned and

provision them successfully. This makes no sense to me, but I say

it to provide more data to possibly help with the fix.
3) Even if I’m able to get two apps “owned" in the view of the

provisioning tool through hacks, I’m unable to provision a 128-bit

symmetric key between the two samples. I see the following error messages:
31:56.294 INFO: SRPAPI: In SRPProvisionCredentials

31:56.294 DEBUG: PDM: Binding Done

31:56.294 ERROR: PDM: Requested value not found

31:56.294 ERROR: SRPAPI: Internal error occured

provisionCredentials is failed
4) If I try to provision an ACL, the tool asks me for

"16 digit URNs" instead of a text representation of UUIDs, which is what

I would’ve expected. I’ve noticed that the parsing code in the ACL

resource

handler expects a CBOR Text String with the UUID, so this clearly seems

to be an issue.

JIRA migration meta data