Date   

Re: Question About CT2.2.6 on CTT1903.0.00 and How to reeset client OTM?

Kishen Maloor
 

Hi,

 

> When I run with CTT, sometimes client do not reset to OTM.

> So I delete the creds directory.

 

This is one way, but you can also call oc_reset() from your Client with a trigger (e.g. button/option) in it.

 

> CTT : Please send a unicast request message to resource with observe option = 1

 

You should call oc_stop_observe() in this case.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@...> on behalf of 김정진 <j.jin@...>
Date: Tuesday, November 5, 2019 at 3:28 AM
To: "iotivity-dev@..." <iotivity-dev@...>
Subject: [dev] Question About CT2.2.6 on CTT1903.0.00 and How to reeset client OTM?

 

Hi. I'm Jeognjin.

I am making a CLI program on ubuntu raspberrypi and trying to pass CT2.2.2, CT2.2.6.
(With make TCP=1 IPV4=1 IPV6=1 SECURITY=1 PKI=1)

1.
When I run with CTT, sometimes client do not reset to OTM.
So I delete the creds directory.
Then client generates new UUID.
So I want to reset only the OTM, but I can't find the example code.

2. I run CTT1903.0.0 and CT2.2.6
PICS with oic.d.sensor

CTT : Please send a unicast request message to resource with observe option = 0  one of 5, so I chose /ThreeAxisResURI 
So I called
- oc_do_observe(uri, endpoint,NULL,&observe_notify_cb,HIGH_QOS,NULL);

In the CTT log
- INFO Request obser options is None

Anyway, it went well. So I can get notification from CTT.

Next, 
CTT : Please send a unicast request message to resource with observe option = 1
I called
- oc_do_observe(uri, endpoint,NULL,&observe_notify_cb,LOW_QOS,NULL);

In the CTT log
- INFO Request obser options is 1

Waited a while, but I did not get a notification.

Thanks for reading.


Iotivity maintenance 2019-11-8 @ 19:00 to 20:00 UTC

Ryan Finnin Day <rday@...>
 

What: The Linux Foundation will be applying updates to Iotivity
infrastructure

When: Friday, November 8, 2019 @ 19:00 to 20:00 UTC

Why: Operating system updates to CentOS7 are available

Impact: Iotivity infrastructure will be unavailable intermittently during
the maintenance window while systems are upgraded and rebooted.

Affected systems include Jenkins, Jenkins sandbox, Gerrit, and Jira.

Notices will be posted here and on
https://status.linuxfoundation.org/
before and after the maintenance.


Question About CT2.2.6 on CTT1903.0.00 and How to reeset client OTM?

김정진
 

Hi. I'm Jeognjin.

I am making a CLI program on ubuntu raspberrypi and trying to pass CT2.2.2, CT2.2.6.
(With make TCP=1 IPV4=1 IPV6=1 SECURITY=1 PKI=1)

1.
When I run with CTT, sometimes client do not reset to OTM.
So I delete the creds directory.
Then client generates new UUID.
So I want to reset only the OTM, but I can't find the example code.

2. I run CTT1903.0.0 and CT2.2.6
PICS with oic.d.sensor

CTT : Please send a unicast request message to resource with observe option = 0  one of 5, so I chose /ThreeAxisResURI 
So I called
- oc_do_observe(uri, endpoint,NULL,&observe_notify_cb,HIGH_QOS,NULL);

In the CTT log
- INFO Request obser options is None

Anyway, it went well. So I can get notification from CTT.

Next, 
CTT : Please send a unicast request message to resource with observe option = 1
I called
- oc_do_observe(uri, endpoint,NULL,&observe_notify_cb,LOW_QOS,NULL);

In the CTT log
- INFO Request obser options is 1

Waited a while, but I did not get a notification.

Thanks for reading.


IoTivity v2.0.5 release announcement

Nathan Heldt-Sheller
 

Hello IoTivity Devs,

 

We’re happy to announce the release of IoTivity Lite 2.0.5 to accompany the launch of OCF v2.0.5 certification program.  The download is available on IoTivity.org here: https://iotivity.org/downloads/iotivity-v2.0.5.  The same code can be pulled from the IoTivity Lite git repo, using the tag “2.0.5”.

 

This is the most complete and stable release of IoTivity yet, and is fully certifiable (as Server, Client, and Onboarding Tool) against the OCF v2.0.5 (a.k.a. Essen) specifications.

 

Major credit to Kishen Maloor of Intel, as well as Samsung’s security team and Intel’s Android team for their respective contributions.  Thanks also to CPM Mitch Kettrick and Comarch folks for working diligently over the past month to resolve and close late-breaking issues.

 

Our next releases will be a bugfix release for IoTivity Classic, and a follow-on release of IoTivity Lite 2.0.5 that fully incorporates all the latest Android API updates.

 

Thanks,
Nathan / OSWG Chair

 

 


OCF Gaborone draft version 0.3 CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find an early draft (v0.3) of a CR against the Open Connectivity Foundation’s next specification (codenamed “Gaborone”). Thus draft document provides a current snapshot of the specification development and is subject to change. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


OCF Gaborone draft version 0.3 CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs against the Open Connectivity Foundation’s next specification (codenamed “Gaborone”). These draft documents provide a current snapshot of the specification development and are subject to change. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


OCF Gaborone draft version 0.3 CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs against the Open Connectivity Foundation’s next specification (codenamed “Gaborone”). These draft documents provide a current snapshot of the specification development and are subject to change. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


OCF Gaborone draft version 0.3 CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs against the Open Connectivity Foundation’s next specification (codenamed “Gaborone”). These draft documents provide a current snapshot of the specification development and are subject to change. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


OCF Gaborone draft version 0.3 CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs against the Open Connectivity Foundation’s next specification (codenamed “Gaborone”). These draft documents provide a current snapshot of the specification development and are subject to change. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


Re: OBT Crash

Kishen Maloor
 

Hi,

 

I am unable to reproduce your crash. I assume you did a "make cleanall" before you rebuilt the stack. Also, I assume you're using the latest source.

 

> I tried to provision the ACE as you suggested but the error code now is the same when I run the apps without using the OBT: 17

>

> The OBT crashes every time I select option 4 (Discover owned devices), regardless of any > previous step.

 

Well, if you were able to provision the ACE, then you'd have to have used options 4/5/6 to discover an owned device first. So, your 2nd statement wouldn't be accurate.

It suggests that option 4 worked for you once without crashing, and it then somehow stopped working???

 

Also, if you saw error code 17, then it suggests that you probably did not provision a credential at all to the Client and the Server.

 

Try this after a fresh build:

-Run the OBT, Client and Server.

-Use option 1 to discover the unowned Client and Server.

-Use option 7 twice to onboard the Client and Server.

-Use option 4 to discover the owned Client and Server.

-Use option 11 to provision pairwise credentials to the Client and Server.

-Use option 13 twice to provision an ACE to both the devices. (Only the Server needs an ACE. But I see that simpleclient/simpleserver do not configure a device name

for you to able to  distinguish one from the other, as you only see their UUIDs. So, for sake of simplicity in your current testing, you can provision it to both)

 

After this, the Client and Server should be able to communicate.

 

If you're still seeing a crash, then I'd have to look at logs and a backtrace from gdb captured with a DEBUG=1 build to make sense of your situation.

 

What OS/machine are you using? Are the OBT, Client and Server all running on the same machine?

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: Thiago Moura <thiagogcm@...>
Date: Tuesday, August 27, 2019 at 9:32 AM
To: "Maloor, Kishen" <kishen.maloor@...>
Cc: iotivity-dev <iotivity-dev@...>
Subject: Re: [dev] OBT Crash

 

Hi Kishen

 

Thanks for the prompt reply.

 

I tried to provision the ACE as you suggested but the error code now is the same when I run the apps without using the OBT: 17

 

The OBT crashes every time I select option 4 (Discover owned devices), regardless of any previous step.

 

I built with DEBUG option now. These are logs just before the crash:

 

DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:815>: -Done parsing-------
DEBUG: ../../messaging/coap/engine.c <coap_receive:167>:   Parsed: CoAP version: 1, token: 0x81B2, mid: 23612
DEBUG: ../../messaging/coap/engine.c <coap_receive:175>:   type: NON
DEBUG: ../../messaging/coap/engine.c <coap_receive:589>: created new response buffer for uri oic/res
DEBUG: ../../messaging/coap/engine.c <coap_receive:639>: calling oc_ri_invoke_client_cb
[1]    22738 segmentation fault (core dumped)  ./onboarding_tool

 

 

 

On Tue, Aug 27, 2019 at 12:28 PM Maloor, Kishen <kishen.maloor@...> wrote:

Hi,

 

> I'm experimenting the latest changes on iotivity-lite and cannot run the simpleclient / server apps.

> First, when I use the pairwise credential option, the server returns error code 6.

 

You have to both provision credentials and provision an access control entry (ACE) to  the server (option 12 or 13 - 13 is simpler) for the two to communicate.

Error code 6 maps to OC_STATUS_UNAUTHORIZED. So it seems you only provisioned credentials, but did not provision the ACE.

 

> And if I select the option to discover owned devices to try a different provision, the OBT chash.

 

Did it crash soon after you used options 4/5/6 to discover owned devices? It would be great if this were reproducible, and you could provide the exact sequence of options

you used in the tool.

 

> Is this a known issue?

 

No.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@...> on behalf of Thiago Moura <thiagogcm@...>
Date: Tuesday, August 27, 2019 at 7:50 AM
To: iotivity-dev <iotivity-dev@...>
Subject: [dev] OBT Crash

 

Hi

 

I'm experimenting the latest changes on iotivity-lite and cannot run the simpleclient / server apps.

 

First, when I use the pairwise credential option, the server returns error code 6. And if I select the option to discover owned devices to try a different provision, the OBT chash.

 

Is this a known issue?

 

regards,
--

Thiago Guedes Cunha de Moura
cel.: (31)99484-9864



--

Thiago Guedes Cunha de Moura
cel.: (31)99484-9864


Re: OBT Crash

Thiago Moura
 

Hi Kishen

Thanks for the prompt reply.

I tried to provision the ACE as you suggested but the error code now is the same when I run the apps without using the OBT: 17

The OBT crashes every time I select option 4 (Discover owned devices), regardless of any previous step.

I built with DEBUG option now. These are logs just before the crash:

DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:815>: -Done parsing-------
DEBUG: ../../messaging/coap/engine.c <coap_receive:167>:   Parsed: CoAP version: 1, token: 0x81B2, mid: 23612
DEBUG: ../../messaging/coap/engine.c <coap_receive:175>:   type: NON
DEBUG: ../../messaging/coap/engine.c <coap_receive:589>: created new response buffer for uri oic/res
DEBUG: ../../messaging/coap/engine.c <coap_receive:639>: calling oc_ri_invoke_client_cb
[1]    22738 segmentation fault (core dumped)  ./onboarding_tool



On Tue, Aug 27, 2019 at 12:28 PM Maloor, Kishen <kishen.maloor@...> wrote:

Hi,

 

> I'm experimenting the latest changes on iotivity-lite and cannot run the simpleclient / server apps.

> First, when I use the pairwise credential option, the server returns error code 6.

 

You have to both provision credentials and provision an access control entry (ACE) to  the server (option 12 or 13 - 13 is simpler) for the two to communicate.

Error code 6 maps to OC_STATUS_UNAUTHORIZED. So it seems you only provisioned credentials, but did not provision the ACE.

 

> And if I select the option to discover owned devices to try a different provision, the OBT chash.

 

Did it crash soon after you used options 4/5/6 to discover owned devices? It would be great if this were reproducible, and you could provide the exact sequence of options

you used in the tool.

 

> Is this a known issue?

 

No.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@...> on behalf of Thiago Moura <thiagogcm@...>
Date: Tuesday, August 27, 2019 at 7:50 AM
To: iotivity-dev <iotivity-dev@...>
Subject: [dev] OBT Crash

 

Hi

 

I'm experimenting the latest changes on iotivity-lite and cannot run the simpleclient / server apps.

 

First, when I use the pairwise credential option, the server returns error code 6. And if I select the option to discover owned devices to try a different provision, the OBT chash.

 

Is this a known issue?

 

regards,
--

Thiago Guedes Cunha de Moura
cel.: (31)99484-9864



--
Thiago Guedes Cunha de Moura
cel.: (31)99484-9864


Re: OBT Crash

Kishen Maloor
 

Hi,

 

> I'm experimenting the latest changes on iotivity-lite and cannot run the simpleclient / server apps.

> First, when I use the pairwise credential option, the server returns error code 6.

 

You have to both provision credentials and provision an access control entry (ACE) to  the server (option 12 or 13 - 13 is simpler) for the two to communicate.

Error code 6 maps to OC_STATUS_UNAUTHORIZED. So it seems you only provisioned credentials, but did not provision the ACE.

 

> And if I select the option to discover owned devices to try a different provision, the OBT chash.

 

Did it crash soon after you used options 4/5/6 to discover owned devices? It would be great if this were reproducible, and you could provide the exact sequence of options

you used in the tool.

 

> Is this a known issue?

 

No.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@...> on behalf of Thiago Moura <thiagogcm@...>
Date: Tuesday, August 27, 2019 at 7:50 AM
To: iotivity-dev <iotivity-dev@...>
Subject: [dev] OBT Crash

 

Hi

 

I'm experimenting the latest changes on iotivity-lite and cannot run the simpleclient / server apps.

 

First, when I use the pairwise credential option, the server returns error code 6. And if I select the option to discover owned devices to try a different provision, the OBT chash.

 

Is this a known issue?

 

regards,
--

Thiago Guedes Cunha de Moura
cel.: (31)99484-9864


OBT Crash

Thiago Moura
 

Hi

I'm experimenting the latest changes on iotivity-lite and cannot run the simpleclient / server apps.

First, when I use the pairwise credential option, the server returns error code 6. And if I select the option to discover owned devices to try a different provision, the OBT chash.

Is this a known issue?

regards,
--
Thiago Guedes Cunha de Moura
cel.: (31)99484-9864


Add INFO.yaml to IoTivity project.

Suresh Channamallu <schannamallu@...>
 

Hi Nathan,

As one the best to have requirement for release engineering team, we need to add one INFO.yaml file to all the repos which we are using in our project.
This INFO.yaml contains all the details regarding the project, committers and the approvers.

So can you check this sample file - https://github.com/onap/integration/blob/master/INFO.yaml
and add a INFO.yaml for our project in a same way


Please let me know if you have any queries.


--
Thanks & Regards,
Suresh.channamallu


OCF draft CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs for Open Connectivity Foundation’s next Core specification releases, codenamed “Fargo.” These draft documents provide a current snapshot of the specification development and are subject to change. Additional CRs will follow upon approval from the relevant OCF WGs. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


Re: Jenkins issue

Mats Wichmann
 

On 8/22/19 9:51 AM, Vitalii via Lists.Iotivity.Org wrote:
Hi,

 

I’m faced with permanent build issue on Jenkins server:
https://jenkins.iotivity.org/job/iotivity-verify-unit_tests/3299/console
15:24:05 Download
/home/jenkins/workspace/iotivity-verify-unit_tests/extlibs/hippomocks-8e210c5808d490b26fff69151c801fa28d291fcb.zip
from
https://github.com/dascandy/hippomocks/archive/8e210c5808d490b26fff69151c801fa28d291fcb.zip
complete
15:24:05 Unzipping hippomocks
15:24:05 Unpacking
/home/jenkins/workspace/iotivity-verify-unit_tests/extlibs/hippomocks-8e210c5808d490b26fff69151c801fa28d291fcb.zip
...
15:24:05 Renaming hippomocks directory
15:24:05 OSError: [Errno 20] Not a directory:
15:24:05   File
"/home/jenkins/workspace/iotivity-verify-unit_tests/SConstruct", line 57:
15:24:05     SConscript(build_dir + 'resource/SConscript')

 

Any suggestions?


Thanks,
Vitalii.
You may end up needing to file a ticket on that one, it looks like the
Jenkins instance didn't populate its environment properly. Maybe. WIll
need more information.

It's not clear from the output whether it failed to get a correct value
for "build_dir", or whether "resource" is missing, maybe add a little
bit of debug in your patch so you can see in the Jenkins log what
happened. build_dir is set in build_common/SConscript, which has been
processed, since that call happens earlier in the SConstruct than the
line which fails.

Also note the line number, 57, doesn't match the current line number in
SConstruct - are you modifying SConstruct? Or patching against some
different version than HEAD?


Jenkins issue

Vitalii
 

Hi,

 

I’m faced with permanent build issue on Jenkins server:
https://jenkins.iotivity.org/job/iotivity-verify-unit_tests/3299/console
15:24:05 Download /home/jenkins/workspace/iotivity-verify-unit_tests/extlibs/hippomocks-8e210c5808d490b26fff69151c801fa28d291fcb.zip from https://github.com/dascandy/hippomocks/archive/8e210c5808d490b26fff69151c801fa28d291fcb.zip complete
15:24:05 Unzipping hippomocks
15:24:05 Unpacking /home/jenkins/workspace/iotivity-verify-unit_tests/extlibs/hippomocks-8e210c5808d490b26fff69151c801fa28d291fcb.zip ...
15:24:05 Renaming hippomocks directory
15:24:05 OSError: [Errno 20] Not a directory:
15:24:05   File "/home/jenkins/workspace/iotivity-verify-unit_tests/SConstruct", line 57:
15:24:05     SConscript(build_dir + 'resource/SConscript')

 

Any suggestions?


Thanks,
Vitalii.

 

 

  


OCF draft CRs for IoTivity review

OCF Staff <staff@...>
 

Dear IoTivity Developers,

 

In the attached .zip file you will find early drafts (v0.3) of CRs for Open Connectivity Foundation’s next Core specification releases, codenamed “Fargo.” These draft documents provide a current snapshot of the specification development and are subject to change. Additional CRs will follow upon approval from the relevant OCF WGs. If you have any questions, please direct them to staff@....

 

Best regards,

OCF Staff

___________________________

Open Connectivity Foundation
3855 SW 153rd Drive
Beaverton, Oregon  97003
Phone:  +1.503.619.0673
Email: staff@...

 

 


Re: Are there any public APIs indicating failure due to security in IoTivity-lite?

Kishen Maloor
 

> I am writing some test code and was wondering if there is any public API that

> indicates failure due to security?

 

No, there isn’t.

 

For simple APIs (GET, POST,...) the response code received in the callback provides an indication of what happened.

 

But for more complex APIs (e.g. onboarding/provisioning), the Client only knows if the entire operation succeeded or failed, either by the return value from the API call

that initiates the operation, or via its callback.

 

In this case I could see a more informative error code (to your question) being made available somehow.

For that we'd start by constructing a list of error codes that collectively capture (at an appropriate granularity) the various steps of the processes.

 

Thanks,

-Kishen.

 

-- 

Kishen Maloor

Intel Corporation

 

From: <iotivity-dev@...> on behalf of George Nash <george.nash@...>
Date: Friday, August 16, 2019 at 2:53 PM
To: "iotivity-dev@..." <iotivity-dev@...>
Subject: [dev] Are there any public APIs indicating failure due to security in IoTivity-lite?

 

I am writing some test code and was wondering if there is any public API that indicates failure due to security?

 

I was hoping, using a public API, that I could discover failure due to security.  Ideally it would indicate the reason for the failure. i.e. failed because device is not onboarded. Failed because interface is not provisioned etc.

 

Example test steps:

 

step 1:

client discovers resource

calls oc_do_get on resource (Expect failure, OTM not yet performed, the GET oc_request_handler not called.  Using public APIs, can I find out about the failure?)

 

step 2:

perform OTM of server/client device

call oc_do_get on resource (Expect failure, not yet provisioned, the GET oc_request_handler not called.  Using public APIs, can I find out about the failure?)

 

step 3:

provision server/client (good provision that will allow client/server to communicate)

call oc_do_get on resource (Expect success, the GET oc_request_handler will be called )

 

 

 

 

 

 

               

 

 

 

 

               

 


Are there any public APIs indicating failure due to security in IoTivity-lite?

George Nash
 

I am writing some test code and was wondering if there is any public API that indicates failure due to security?

 

I was hoping, using a public API, that I could discover failure due to security.  Ideally it would indicate the reason for the failure. i.e. failed because device is not onboarded. Failed because interface is not provisioned etc.

 

Example test steps:

 

step 1:

client discovers resource

calls oc_do_get on resource (Expect failure, OTM not yet performed, the GET oc_request_handler not called.  Using public APIs, can I find out about the failure?)

 

step 2:

perform OTM of server/client device

call oc_do_get on resource (Expect failure, not yet provisioned, the GET oc_request_handler not called.  Using public APIs, can I find out about the failure?)

 

step 3:

provision server/client (good provision that will allow client/server to communicate)

call oc_do_get on resource (Expect success, the GET oc_request_handler will be called )