[Improvement] add a way to stop an ongoing discovery
Hello,

Currently all discovery functions have an implicit timeout of 60s by default... The problem is that when I start a discovery (via obt or normal api), I pass a data pointer. However I do not know when to free it since I do not have any way to either stop an ongoing discovery or be notified that the discovery process finished.

Looking at the code, it seems easier to just let the user handle the timeout itself and add a stop function (that will just call free_discovery_cb() for obt for example) and remove the hardcoded timeout altogether.

This may require an api breakage :(

Thanks

Kishen Maloor
Kishen Maloor @KISHEN · 9 months ago
Maintainer
@farid

The discovery calls perform a multicast and may receive 0, 1, or >1 responses and the Client doesn't know how many responses will arrive from Servers. As the oc_obt API callback param needs to be alive over that period during which responses may arrive, a 60s waiting period was arbitrarily chosen as an upper bound. In practice, a Client would receive and process all the responses from Servers in a few seconds (well within that 60s period), so it was a safe choice, but since the Client fundamentally doesn't know when discovery is "over", we needed a mechanism to free up internal stack resources such as that callback object.

Applications shouldn't be required to choose this timeout because not only do they lack the information to make that choice, the resource being freed in this case belongs to the stack.

If you're passing your own objects to the discovery API from your application, you're free timeout those objects whenever appropriate to the application. If the discovery callback were then somehow triggered for a certain call after the app freed that object, then app logic could for e.g. be written to confirm the existence of that object before proceeding. In other words, you don't have to rely on whatever hidden timeout the stack sets for its internal cleanup.

farid
farid @farid · 9 months ago
@KISHEN Thank you for the answer. I understand the logic, however I still think there is something missing: consider the following 2 use cases: 1: I malloc() a user data and start a discover. When I discover the device, I could stop the discovery before the timeout (but ok, I can live with that, no big deal :-) ). (by the way, what happens if we start a discovery and a second one before the timeout? Will both discovery callbacks be triggered or there is a transaction id somewhere?) 2: In the case there is no answer, the callback will never be called. When can I then free the data?

From what you say, I will need to add a "user data" management layer in a global variable for example and keep track of them. In a way this force the application to have a mechanism to free up internal app resources while we could benefit from the mechanism already available in the iotivity stack

If you are still not convinced, then I have no other choice than making this mechanism you described in my application (not sure how yet) :-)

Ok for the fixed timeout, no need to set change it by the application.

Kishen Maloor
Kishen Maloor @KISHEN · 9 months ago
Maintainer
@farid

Just so it's clear, when you invoke the discovery API the multicast request is sent just once. After that it depends on receiving Server devices responding and those responses reaching. Said another way, the Client isn't actively "discovering" - its just processing responses that are received. The Client app can choose to ignore any remaining responses or resources by returning STOP_DISCOVERY. In practice, responses arrive immediately and are processed in sequence. That timeout is merely a worst case upper bound, taking into consideration any delays over constrained networks (for e.g. Thread).

When I discover the device, I could stop the discovery before the timeout

Strictly speaking the Client shouldn't even be aware that such a timeout exists, and it doesn't have to be aware. Client logic can be written based on its own requirements to reissue discovery requests at any chosen interval, and any number of times. Those internal callback objects would be created and freed by the stack and Client wouldn't even know.

by the way, what happens if we start a discovery and a second one before the timeout?

You may get duplicate responses to the 2nd discovery request of what you received from those same Servers to the first discovery. Sometimes if the muleicast was dropped by some Server or by the network, then the 2nd discovery may hit, and you get the response. Its usually the reason why Clients may choose to issue multiple discovery requests to ensure that all reachable Servers see the request and respond.

Will both discovery callbacks be triggered

Well, you could reuse the same physical callback in the code for the first request (if you were thinking otherwise). But, yes callbacks would be invoked as usual you process the responses to record new resources that you haven't already captured (for e.g.). The Client needn't worry about the discovery callback being for the first or 2nd request.

or there is a transaction id somewhere?)

There's a distinct token, but that's a low-level CoAP detail that the application wouldn't get involved in.

In the case there is no answer, the callback will never be called. When can I then free the data?

You don't have to free user_data from the discovery callback. Rather you could set a timer (oc_set_delayed_callback()) to trigger at some point determined by you and free the object inside that timer callback.

From what you say, I will need to add a "user data" management layer in a global variable for example and keep track of them. In a way this force the application to have a mechanism to free up internal app resources while we could benefit from the mechanism already available in the iotivity stack

Again, the fact that there's a timer at all is an internal detail that you are not supposed to know :-) That is not relevant to any Client behavior becuase as I last explained there is fundamentally no way to know when discovery is "over". You just have to pick a suitable time or point (for e.g. after processing the response from the first discovered device) at which to free those app allocated resources.

Multiple calls to oc_do_ip_discovery fail on windows.
Reproduction steps:
on windows:

Update simpleclient_windows sample as indicated below.
build code.
start SimpleServer.exe
onboard and provision SimpleServer (recommend using wildcard ACL) so it can be called from the SimpleClient.exe
Run SimpleClient.exe (may need to onboard and provision SimpleClient depending on provision settings done for SimpleServer)
Expected output:

DISCOVERY 1 CALLED
DISCOVERY 2 CALLED
Actual output:
DISCOVERY 1 CALLED
 
note:
Only the first call to oc_do_ip_discovery is successful.
 
Code change in the simpleclient_windows sample code
static oc_discovery_flags_t
discovery1(const char *anchor, const char *uri, oc_string_array_t types,
oc_interface_mask_t iface_mask, oc_endpoint_t *endpoint,
oc_resource_properties_t bm, void *user_data)
{
printf("DISCOVERY 1 CALLED\n");
oc_free_server_endpoints(endpoint);
return OC_CONTINUE_DISCOVERY;
}

static oc_discovery_flags_t
discovery2(const char *anchor, const char *uri, oc_string_array_t types,
oc_interface_mask_t iface_mask, oc_endpoint_t *endpoint,
oc_resource_properties_t bm, void *user_data)
{
printf("DISCOVERY 2 CALLED\n");
oc_free_server_endpoints(endpoint);
return OC_CONTINUE_DISCOVERY;
}

static void
issue_requests(void)
{
oc_do_ip_discovery("core.light", &discovery1, NULL);
oc_do_ip_discovery("core.light", &discovery2, NULL);
}
 

JIRA migration meta data

JIRA Issue ID: LITE-83

Reporter: georgen

Assignee: kmaloor

Creator: georgen

Created at: 2019-08-29T14:19:41.000-0700

Found in Version: master

Fix in Version: None

Issue Severity: Major

Reproducibility: Always (100%)

Operating System: Windows

Hardware/ OEM Platform: None

External URL: None

Bugzilla ID: None

Product: None

Status: To Do

Components: base stack

Priority: P3

Due Date: None

Issue Type: Bug
END of JIRA migration meta data

There seems to be a timing issue during initialization, particularly with respect to the Windows connectivity layer. On examining the logs, you will find that the send_msg() failed, so the discovery packet wasn't even sent.
But if I set a delayed_callback() inside issue_requests() and issued the back to back discoveries inside that callback (after a delay of say 5-10s from issue_requests()), I see that both callbacks are invoked.

There is an error in iotivity-lite-swig file when building on Windows.

CustomBuild is missing.

With the move to Iotivity-Lite, the WES feature must be implemented in Lite.

JIRA migration meta data

JIRA Issue ID: LITE-39

Reporter: ibrahimdanish

Assignee: kmaloor

Creator: ibrahimdanish

Created at: 2018-03-18T04:18:14.000-0700

Found in Version: N/A

Fix in Version: None

Issue Severity: Enhancement

Reproducibility: Always (100%)

Operating System: None

Hardware/ OEM Platform: None

External URL: None

Bugzilla ID: None

Product: None

Status: In Progress

Components: wes

Priority: P2

Due Date: None

Issue Type: New Feature
END of JIRA migration meta data

OSWG Weekly CC April 1, 2019:
user
reports that there is some work done on WES in the Samsung branch (enrollee only), but that there is no substance around the mediator code.  Kishen plans to implement WES in Lite but it is not clear yet when it reaches the top of his TODO list... best guess is late April to align with the Lite-based OTGC release.

user
commented that the CTT is testing only the enrollee functionality for WES.  CWG will probably need to create TCs to validate the mediator functionality.  Ed and Mitch to take offline.

Please note that work on this feature is ongoing on the "wes" branch of IoTivity Lite.

Hi.
I tried to build from Linux port for enable SWUPDATE resource.
So in <iotivity-lite>/port/linux, I ran make SWUPDATE=1, then got this error

-DOC_PKI -DOC_DYNAMIC_ALLOCATION -DOC_SOFTWARE_UPDATE -DOC_SECURITY -lm -pthread -lrt -lboost_system -lcppnetlib-uri
In file included from ../../port/oc_connectivity.h:24:0, from ../../include/oc_buffer.h:22, from ../../messaging/coap/coap.h:56, from ../../messaging/coap/separate.h:51, from ../../messaging/coap/oc_coap.h:20, from ../../include/oc_api.h:32, from ../../apps/smart_home_server_with_mock_swupdate.cpp:17: ../../include/oc_endpoint.h:77:62: error: anonymous variadic macros were introduced in C++11 [-Werror=variadic-macros] #define oc_make_ipv4_endpoint(__name__, __flags__, __port__, ...) ^
../../include/oc_endpoint.h:81:62: error: anonymous variadic macros were introduced in C++11 [-Werror=variadic-macros]
#define oc_make_ipv6_endpoint(__name__, __flags__, __port__, ...) ^
In file included from ../../port/oc_connectivity.h:27:0, from ../../include/oc_buffer.h:22, from ../../messaging/coap/coap.h:56, from ../../messaging/coap/separate.h:51, from ../../messaging/coap/oc_coap.h:20, from ../../include/oc_api.h:32, from ../../apps/smart_home_server_with_mock_swupdate.cpp:17: ../../port/oc_log.h:37:15: error: anonymous variadic macros were introduced in C++11 [-Werror=variadic-macros]
#define PRINT(...) printf(__VA_ARGS__) ^
../../port/oc_log.h:147:16: error: anonymous variadic macros were introduced in C++11 [-Werror=variadic-macros] #define OC_LOG(...) ^
../../port/oc_log.h:148:16: error: anonymous variadic macros were introduced in C++11 [-Werror=variadic-macros] #define OC_DBG(...) ^
../../port/oc_log.h:149:16: error: anonymous variadic macros were introduced in C++11 [-Werror=variadic-macros] #define OC_WRN(...) ^
../../port/oc_log.h:150:16: error: anonymous variadic macros were introduced in C++11 [-Werror=variadic-macros] #define OC_ERR(...) ^
../../apps/smart_home_server_with_mock_swupdate.cpp:33:33: fatal error: boost/network/uri.hpp: No such file or directory cc1plus: all warnings being treated as errors compilation terminated. Makefile:350: recipe for target 'smart_home_server_with_mock_swupdate' failed make: *** [smart_home_server_with_mock_swupdate] Error 1

Isn't the error printout in oc_blockwise_free_buffer a false positive?
I get a lot of "buffer is NULL" when I enable error printouts using plgd.dev branch.
Couldn't this error printout be removed from oc_blockwise_free?

static void
oc_blockwise_free_buffer(oc_list_t list, struct oc_memb *pool,
                         oc_blockwise_state_t *buffer)
{

  if (!buffer) {
    OC_ERR("buffer is NULL");
    return;
  }

  oc_free_string(&buffer->uri_query);
  oc_free_string(&buffer->href);
  oc_list_remove(list, buffer);
#ifdef OC_DYNAMIC_ALLOCATION
  free(buffer->buffer);
  buffer->buffer = NULL;
#endif
  oc_memb_free(pool, buffer);
}

we Follow the official website documentation: https://iotivity.org/getting-started-iotivity-device-simulation ，the topic is “Getting started with IoTivity - Device simulation”。and we do not change any code 。
But when we test the server app with the CTT tool， it failed.
we have try iotivity 2.2.0 with CTT_2002.5.0 failed
then we try iotivity 2.2.2 with CTT_2101.0.0 failed
our own porting device report the same problem.
how to make the official the server app pass the CTT? we need a a step by step howto document

Foolowing the instructions I'm getting the error below towards the very end.

otgc-linux/src/main/java/org/openconnectivity/otgc/utils/util/DialogHelper.java:[22,20] package javafx.scene does not exist

On the Server App I'm getting the following error

make: *** No rule to make target '../../apps/device_builder_server.c', needed by 'device_builder_server'. Stop.

I'm on Ubuntu 20.04. Any suggestions?

Is it possible to provide an Android APi that has been built?

System:Windows10

mingw32-make.exe NDK_HOME=%NDK_HOME% ANDROID_API=21 DEBUG=1 SECURE=1 IPV4=1 TCP=0 PKI=1 DYNAMIC=1
CLOUD=0 JAVA=1 IDD=1
21 was unexpected at this time.
if [ -d ../../deps/mbedtls ]; then
cd ../../deps/mbedtls &&
git clean -fdx . &&
git reset --hard &&
cd -;
fi &&
git submodule update --init &&
cd ../../deps/mbedtls &&
for patch in ../../patches/05_mbedtls_ocf-microsoft.patch ../../patches/06_mbedtls_constrained.patch ../../patches/08_mbedtls_C99.patch ../../patches/09-ocf-samsung-psk.patch ../../patches/10-ocf-samsung-anon.patch; do patch -r - -s -N -p1 < ${patch} ; done &&
echo "Patches applied in ../../deps/mbedtls/.git ../../patches/05_mbedtls_ocf-microsoft.patch ../../patches/06_mbedtls_constrained.patch ../../patches/08_mbedtls_C99.patch ../../patches/09-ocf-samsung-psk.patch ../../patches/10-ocf-samsung-anon.patch" > patched.txt
-d was unexpected at this time.
mingw32-make.exe: *** [Makefile:376: ../../deps/mbedtls/patched.txt] Error 255

if we delete another timer in current timer callback function, system may crash.
since in poll_event_callback_timers() , the 'next' node may be freed, but will be referenced by current loop.

while (event_cb != NULL) {
    next = event_cb->next;  //record the next node.

    if (oc_etimer_expired(&event_cb->timer)) {
      if (event_cb->callback(event_cb->data) == OC_EVENT_DONE) {
        oc_list_remove(list, event_cb);
        oc_memb_free(cb_pool, event_cb);
        event_cb = oc_list_head(list);
        continue;
      } else {
        OC_PROCESS_CONTEXT_BEGIN(&timed_callback_events);
        oc_etimer_restart(&event_cb->timer);
        OC_PROCESS_CONTEXT_END(&timed_callback_events);      
      }
    }
    event_cb = next; //here,  next can be freed by current timer's callback function event_cb->callback.
  }

To fix this issue, i submit a pr (commit 37bfad8). do you think this is a issue should be fixed ?

Error storing a new trust anchor
Open

Error storing a new trust anchor

When I store a new trust anchor, I sometimes receive an error using the same PEM encoded certificate.

I call "OCPki.addTrustAnchor" method with a PEM encoded certificate and it works but it sometimes returns an error using the same PEM certificate.

DEBUG: ../../security/oc_pki.c <pki_add_trust_anchor:265>: attempting to add a trust anchor

ERROR: ../../security/oc_pki.c <pki_add_trust_anchor:281>: could not parse the provided trust anchor: -8576

I have attached the PEM encoded certificate and the log file for a success storing and the PEM encoded certificate and the log file for a failed storing.

certificate_error.log

certificate_success.log

store_certificate_error.log

store_certificate_success.log

Drop or upload designs to attach

Linked issues
0

Trishia Yun
Trishia Yun @Trishia · 7 months ago
Developer
@KISHEN

I have witnessed same issue related to pki certificates installing mfgcert, trust anchor and so on. I guess this is because of these code on several functions in oc_pki.c : if (cert[cert_size - 1] != '\0') { cert_size += 1; } which is expending byte array to cert_size + 1 without array rellocation/re-sizing. So sometimes cert[cert_size-1] after cert_size += 1 can be wrong address's data (i.e. 0x4a ...) even if you are expecting '\0'. It makes parsing error in mbedtls_x509_crt_parse().

In many case of apps on android or java, the last data of byte array in pem cert is commonly '\r'(0x0a) when apps read a pem file.

To avoid this problem, apps should add '\0' via resizing byte array but I think it should be handled or resized in oc_pki.c

pki_add_trust_anchor(size_t device, const unsigned char *cert, size_t cert_size,
oc_sec_credusage_t credusage)
{
OC_DBG("attempting to add a trust anchor");

mbedtls_x509_crt cert1, cert2;
mbedtls_x509_crt_init(&cert1);
size_t c_size = cert_size;

/* Parse root cert */
if (oc_certs_is_PEM((const unsigned char *)cert, cert_size) != 0) {
OC_ERR("provided cert is not in PEM format");
return -1;
}
if (cert[cert_size - 1] != '\0') {
c_size += 1;
}
int ret = mbedtls_x509_crt_parse(&cert1, (const unsigned char *)cert, c_size);
if (ret < 0) {
OC_ERR("could not parse the provided trust anchor: %d", ret);
return -1;
}
OC_DBG("parsed the provided trust anchor");

/* Pass through all known trust anchors looking for a match */
oc_sec_creds_t *creds = oc_sec_get_creds(device);
oc_sec_cred_t *c = oc_list_head(creds->creds);
for (; c != NULL; c = c->next) {
if (c->credusage != credusage) {
continue;
}
mbedtls_x509_crt_init(&cert2);
ret = mbedtls_x509_crt_parse(
&cert2, (const unsigned char *)oc_string(c->publicdata.data),
oc_string_len(c->publicdata.data) + 1);
if (ret < 0) {
OC_ERR("could not parse stored certificate: %d", ret);
mbedtls_x509_crt_free(&cert2);
continue;
}

mbedtls_x509_crt *trustca = &cert2;
for (; trustca != NULL; trustca = trustca->next) {
  if (trustca->raw.len == cert1.raw.len &&
      memcmp(trustca->raw.p, cert1.raw.p, cert1.raw.len) == 0) {
    break;
  }
}

mbedtls_x509_crt_free(&cert2);

if (trustca) {
  mbedtls_x509_crt_free(&cert1);
  OC_DBG("found trust anchor in cred with credid %d", c->credid);
  return c->credid;
}

}

OC_DBG("adding a new trust anchor entry to /oic/sec/cred");

ret = oc_sec_add_new_cred(device, false, NULL, -1, OC_CREDTYPE_CERT,
credusage, "*", 0, 0, NULL, OC_ENCODING_PEM,
c_size - 1, (const uint8_t *)cert, NULL, NULL);
if (ret != -1) {
OC_DBG("added new trust anchor entry to /oic/sec/cred");
oc_sec_dump_cred(device);
} else {
OC_ERR("could not add trust anchor entry to /oic/sec/cred");
}

mbedtls_x509_crt_free(&cert1);
return ret;
}
Kishen Maloor
Kishen Maloor @KISHEN · 7 months ago
Maintainer
@Trishia

Yes, mbedTLS expects a string with the certificate(s) that is terminated by a NULL character. The underlying string matching functions it internally uses to locate the certificate header/footer stop at a NULL. So, I think they've just set a terminating NULL character convention for the input to their parse API to prevent out-of-bounds access. As such, I'd prefer to follow that same convention for input to the oc_pki APIs as well rather than reallocating/resizing the provided input string to add a NULL character. We should clarify this in the API documentation.

Trishia Yun
Trishia Yun @Trishia · 7 months ago
Developer
@KISHEN

Ok I got it. Thank you for your clear explanation.

But these code if (cert[cert_size - 1] != '\0') { cert_size += 1; } in oc_pki.c makes a lot of confusion to app developer who missed Null character at the end of byte array for pem data. That code works well accidentally but sometimes it fails. So I think you'd better remove that code for more clear convention if it is not essential code. In my case, that issue makes me confusion for a long time because there is no sample code to get byte data added null character on android sample apps.

Kishen Maloor
Kishen Maloor @KISHEN · 7 months ago
Maintainer
@Trishia

But these code if (cert[cert_size - 1] != '\0') { cert_size += 1; } in oc_pki.c makes a lot of confusion to app developer

Ideally, the API user shouldn't have to look inside the API implementation to know how to use it :). I think we should clarify this detail (i.e. to include a terminating NULL byte) in the API docs for oc_pki APIs.

As for why those lines you referred to exist, it is because mbedTLS's parse API needs the length of the cert + 1 (for the NULL byte). If a C app passes in the cert as a C string and happens to send strlen(cert) as the cert length to the API, then this line bumps up that length before handing the string to mbedTLS. That's all. The API implementation still requires that the cert string have a NULL byte at the end.

Diego Bartolome
Diego Bartolome @dbartolome · 7 months ago
Developer
@miguel has also verified the certificate in OTGC (by printing it) before calling the API and the content is exactly the same, when the operation fails and when goes well.

Kishen Maloor
Kishen Maloor @KISHEN · 7 months ago
Maintainer
@dbartolome @miguel

If you find an error log that looks different than the one above, please post it in this issue. The error log documented above is returned by mbedTLS.

ERROR: ../../security/oc_pki.c <pki_add_trust_anchor:281>: could not parse the provided trust anchor: -8576

Wouter van der Beek
Wouter van der Beek @wouter · 27 minutes ago
Developer
solution: provide javadoc info that a cert needs to be zero terminated in java before calling the C libarary.

Comments from MR 114:
"With oc_endpoint_string_parse_path exposed to Java we are
able to update the OCEndpointUtil.stringToEndpoint method so
it can take only one parameter. Since developers are already
using the stringToEndpoint method that takes two parameters
we need to still provide that method."
The only implementation I know that does this is OTGC, which we can have changed in an
upcoming release.

added android label

cc: @ljsachs

created merge request !121 to address this issue

based on branch:https://github.com/iotivity/iotivity-lite/tree/154-remove-stringtoendpoint-variant-that-takes-two-parameters

Since a few weeks its been possible to observe the oic/d resource. Changing the n parameter (name) on the oc/con resource will automaticaly change the n parameter on the oic/d resource. This will then trigger a notification to be sent to any observers of this resource. This works.

However, in the request callback for that resource (oc_core_device_handler() in https://github.com/iotivity/iotivity-lite/blob/master/api/oc_core_res.c) the piid resource has a condition on it.

if (request->origin && request->origin->version != OIC_VER_1_1_0) {
oc_rep_set_text_string(root, piid, piid);
}

This works fine when a client does a get on this resource, but when this is used for the notification scenario above the request->origin is not set and the piid will be ommited from the notification.

This will then look from a clients perspective as: Chainging the n parameter on oc/con deletes the piid on oic/d.

Hello,

I have followed the step to build iotivity-lite for Android as explained here: https://iotivity.org/documentation/building-iotivity-android

The command used to generate it was:
make NDK_HOME=~/android-build/android-arm64-27 ANDROID_API=27 ANDROID_ABI=arm64-v8a IPV4=1 DEBUG=1 SECURE=0

Then I added the iotivity-lite.jar to my libs folder and the libiotivity-lite-jni.so to the src/main/jniLibs/arm64-v8a.

When I run the app and try to init the stack (dummy code for now):

OcPlatform.getInstance().systemInit(object : OCMainInitHandler {
            override fun initialize(): Int {
                Log.d("AAAAA", "MyClass-initialize: ")
                return 0
//                TODO("Not yet implemented")
            }

            override fun registerResources() {
                Log.d("AAAAA", "MyClass-registerResources: ")
//                TODO("Not yet implemented")
            }

            override fun requestEntry() {
                Log.d("AAAAA", "MyClass-requestEntry: ")
//                TODO("Not yet implemented")
            }

        })

I get the following error:

2020-09-11 22:22:50.787 23689-23689/my.app.package W/System.err: Native code library failed to load. 
2020-09-11 22:22:50.787 23689-23689/my.app.package W/System.err: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "oc_is_owned_device" referenced by "/data/app/my.app.package-cinCjuUX7hShiEk9-VBcaw==/lib/arm64/libiotivity-lite-jni.so"...

Can anyone point me what I could be doing wrong?

onboarding failure if called from discovery callback
Hello,

I'm having a strange issue... the onboard process is failing if I do the provisioning from the callback (real use case were I do auto onboard a server) I was able to reproduce the probleme on linux by modifying the onboarding tool.... The modifications were done so that the following is done: 1- onboarding tool displays the menu and we select 1 - discover unowned device 2- we make sure only one server is discoverable. The obt tool will discover the server and immediately do otm_just_works() 3- uppon success, the modified obt tool do a discovery of owned devices automatically 4- a call to provision_ace2() is done... and we end up with a TLS handshake error

mbedtls_log: ../../deps/mbedtls/library/ssl_srv.c:1262: client hello v3, message type: 21 mbedtls_log: ../../deps/mbedtls/library/ssl_srv.c:1267: bad client hello message ERROR: ../../security/oc_tls.c <read_application_data:1956>: oc_tls: mbedtls_error: SSL - Processing of the ClientHello handshake message failed DEBUG: ../../security/oc_tls.c <oc_tls_free_peer:303>: oc_tls: removing peer mbedtls_log: ../../deps/mbedtls/library/ssl_tls.c:8980: => free mbedtls_log: ../../deps/mbedtls/library/ssl_tls.c:9045: <= free

Here is the modified obt tool to reproduce. Just start the server and do a discover unowned device: obt.diff

Drop or upload designs to attach

Linked issues
0

farid
farid @farid · 2 months ago
I think I've found the root cause. It is not the fact of calling the function from inside the callback... it is related to network latencies. And calling from the callback makes it almost always happen: The onboarding tool send a tls session close to the server... The server receives the close notify and send (twice) a close notify too... However, the onboarding tool already started a new session... and it receives a close notify from the sever in the middle of a handshake! Sometime it has no importance, but not always.

Now, about the fix, I have two points: 1- in oc_tls.c, every call to mbedtls_ssl_close_notify() are done twice... why? (maybe an old bug from an old mbedtls library?). I removed all the duplicated calls and added a call to mbedtls_ssl_session_reset() (not sure this call is needed or not, but depending on the version of the mbdedtls library, this may be necessary) 2- For the issue itself, when getting MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY, I've commented the call to mbedtls_ssl_close_notify() and replaced it with a call to mbedtls_ssl_session_reset(). My concern here is that maybe we should still call mbedtls_ssl_close_notify() if the message is not MBEDTLS_ERR_SSL_PEER_CLOSE_NOTIFY...

@kmaloor

I'm wondering how to make cloud de-register operation in server_certification_tests.c.

Cloud Register, Cloud Login, Cloud Logout, Cloud Refresh Token, Publish Resources operations work well but Cloud DeRegister only shows "Could not issue Cloud Register request" at any situation.

How can I do that operation successfully?
Inform me your guide to do this.

Thanks in advance.

Hello,
I've found one issue that happens only when the device is onboarded to the cloud and loses network connection.
When a connection to the server is lost the iotivity-lite process "TLS Process" defined in iotivity-lite/security/oc_tls.c
will hang for a longer period of time (probably timeout issue).

During this time a lot of events will queue up and the stack is not able to process them before the next "TLS Process" kicks again.
This leads to a state where oc_main_poll never returns and causes all sort of issue mostly when you have multithreaded environment and you are protecting the access to iotivity-lite API with shared recursive mutexes.

I have managed to fix this issue by placing a limit on how many polls can be invoked during one oc_main_poll but I would
like to ask you if there is a better way to solve this issue. Thanks.

My fix is as following:

M api/oc_main.c
@@ -280,7 +280,8 @@ oc_clock_time_t
 oc_main_poll(void)
 {
   oc_clock_time_t ticks_until_next_event = oc_etimer_request_poll();
-  while (oc_process_run()) {
+  int max_processes = 100;
+  while (oc_process_run() && (--max_processes > 0)) {
     ticks_until_next_event = oc_etimer_request_poll();
   }
   return ticks_until_next_event;

Dear community,
I'm searching information about Iotivity platform and in particular about interoperability among devices belonging to different standards and protocols.
For example, if I have two devices a switch button x and lamp y, once I impored them in the platform, how can lauch a command to lamp y to switch on the light? Using the Rest interface? Is it possibile to create a rule that make possibile to switch on the light y when the the switch button x is pressed? How this rule is described?
Thanks.

This is regression with testing with CTT
commits 66faa4a - eb95cf4 caused issue in test 1.4.5 Cloud: Last Error Code
Please see the logs:
CTT_Logs_Archive__3_.zip
It's in parts:

"Test IUT has to access non-existing cloud" and "Test create account return 4.01"

It could be reproduced every time.

FYI @mkettrick @wouter

Hello,
before this change the cps was set to failed right after the first failure https://gitlab.iotivity.org/iotivity/iotivity-lite/-/blob/137c690a4d73d7979f5f12b7f1edbe42ee52c13d/api/cloud/oc_cloud_manager.c#L220 but the provisioning didn't failed until the retry count is over, therefore it has been updated to report registering status until the retry count is zero https://gitlab.iotivity.org/iotivity/iotivity-lite/-/blob/master/api/cloud/oc_cloud_manager.c#L216
This is described in OCF Device To Cloud Service Specification v 2.1.0 6.2.3.2.3 ... Device shall transition to the "failed" state, unless the Device autonomously re-attempts the registration ...
So this means that the test must be updated and not the implementation, right?
FYI @ondrejtomcik @jkralik

Hi All.
please use tag 2.2.3 of Iotivity of testing.
note that that master has already progressed, hence seeing this failure.
it still needs to be fixed for a future iotivity/ctt release (on the CTT side).

I've checked and tag 2.2.3 pass all of the testcases.
Which branch, tag, shall we use for the Night builds for regression testing?
When I asked this question last time I get answer that we should use master

Hi Marek,
yes, the master should be used for regression testing.
so this is a new CTT issue due to code changes after releasing 2.2.3.
Note that gitlab will be retired soon.
please start using https://github.com/iotivity/iotivity-lite master
note this github repo is now currently synced from gitlab.

../../security/oc_tls.c:140:3: error: 'MBEDTLS_TLS_ECDH_ANON_WITH_AES_128_CBC_SHA256' undeclared here (not in a function)
MBEDTLS_TLS_ECDH_ANON_WITH_AES_128_CBC_SHA256,
^
Makefile:214: recipe for target 'obj/server/oc_tls.o' failed
make[3]: *** [obj/server/oc_tls.o] Error 1

Hi all,
It looks like can not work well on my ubuntu18.04, when i update iotivity-constrained to iotivity-lite.

What I did is just make and run ./server & ./client.

• On iotivity-constrained SDK, it still looks like work well now.
  

• On iotivity-lite SDK, it still looks like can not communicate with each other.
  

What should I do to make iotivity-lite works on linux?

What

When SO_REUSEADDR is set, then multiple process of device with small chance system can peak same port for coap, coaps, coap+tcp, coaps+tcp.

Note

For linux it is fixed by PR: #56
For other ports it's need to be implemented too.

Replication:

It is replicable with 1000 processes (one per device) via docker with network host - cca 20 ports are shared among devices.

Priority

Trivial - linux is used mainly for docker, so for other ports it is unusual to multiple processes of devices.

During large scale deployments, with 10000 iotivity-lite servers connected to a cloud application (plgd) a segv occurs in the message message transaction part of iotivity-lite. This only happens after many ours of uptime.

End of console output:
Cloud Manager Status:
-Registered
-Token Expiry: 3478
-Logged In

Cloud Manager Status:
-Registered
-Failure

Cloud Manager Status:
-Registered

Cloud Manager Status:
-Registered

Cloud Manager Status:
-Registered

Cloud Manager Status:
-Registered
malloc_consolidate(): invalid chunk size

We are in contact with the plgd team, will update this issue when more informations is available.

A patch file were made from the gerrit commits before gerrit went off line. Those commits can be found here.
https://github.com/gnash117/iotivity-lite/blob/gerrit-patches/gerrit-patches/master-branch/0001-Comparing-porting-layer-between-linux-and-webos.patch
https://github.com/gnash117/iotivity-lite/blob/gerrit-patches/gerrit-patches/master-branch/0001-LITE-51-Add-webOS-porting-layer.patch
use git am command to apply the patches.

TIMEOUT state and "timer" Property
Open

[Feature] TIMEOUT state and "timer" Property

Need to implement new TIMEOUT state similar to RESET Devices do not normally respond to network when in this state, and have to be manually reset and onboarded

Need to implement new /oic/sec/doxm:timeout Property The property is automatically set to 1800 at RFOTM, and starts counting down. If Device is not onboarded by the time it reaches 0, the Device shall enter the TIMEOUT state

Drop or upload designs to attach

Linked issues
0
Related merge requests
1
Resolve "[Feature] TIMEOUT state and "timer" Property"
!28
Avatar for Kishen Maloor

George Nash
George Nash @george · 1 year ago
Developer
Oleksandr,

Is this a new OCF secuirty requirement for a future release?

Oleksandr Andrieiev
Oleksandr Andrieiev @oleksandr · 1 year ago
Contributor
Yes. See https://bugzilla.openconnectivity.org/show_bug.cgi?id=2750 for details I think we should have a field somewhere for references to the BZ items, but for now I'll just add a link in the comments

Oleksandr Andrieiev @oleksandr assigned to @oleksandr 1 year ago
Oleksandr Andrieiev @oleksandr created merge request !28 to address this issue 1 year ago
Oleksandr Andrieiev @oleksandr mentioned in merge request !28 1 year ago
Oleksandr Andrieiev @oleksandr added
specification
label 1 year ago
Oleksandr Andrieiev @oleksandr mentioned in issue #123 (closed) 1 year ago
Oleksandr Andrieiev @oleksandr assigned to @KISHEN and unassigned @oleksandr 9 months ago
Oleksandr Andrieiev
Oleksandr Andrieiev @oleksandr · 9 months ago
Contributor
Unfortunately, I can no longer work on this feature. I think CableLabs had interest in the feature, so you can reassign it to Kyle, if he gets a profile here.

Kishen Maloor
Kishen Maloor @KISHEN · 8 months ago
Maintainer
@oleksandr Thanks, I will check with CableLabs about getting this done.

merge request on gitlab:
https://gitlab.iotivity.org/iotivity/iotivity-lite/-/tree/14-feature-timeout-1
branch on github:
https://github.com/iotivity/iotivity-lite/tree/14-feature-timeout-1

I'm running an IoTivity client that rediscovers available resources every 20 seconds. At the start it works fine. However, after around 2 and a half minutes the client doesn't discover the resource anymore. When I restart the client it still doesn't find it but when I restart the server the client rediscover it but for 2:30 min. Why is this happening and how can I fix it? I used IoTivity 1.2.1 and I'm running the server and the client on different embedded devices (connected to the same network but on different switch). I also tried IoTivity lite and I still got the same issue.

Implicit access policy and Device Onboarding connection
The CR clarifies the implicit permissions of SVR requests received over the Device Onboarding Connection (DOC) established during RFOTM in onboarding.

https://bugzilla.openconnectivity.org/show_bug.cgi?id=2335

JIRA migration meta data

JIRA Issue ID: LITE-62
Reporter: phawkes
Assignee: nathanheldtsheller
Creator: phawkes
Created at: 2019-07-31T00:53:34.000-0700
Found in Version: master
Fix in Version: None
Issue Severity: Normal
Reproducibility: Always (100%)
Operating System: None
Hardware/ OEM Platform: None
External URL: None
Bugzilla ID: 2335
Product: None
Status: To Do
Components: security
Priority: P1
Due Date: None
Issue Type: New Feature
END of JIRA migration meta data

Blockwise timeout notify 503 not working properly for GET requests
For some reason I'm not able to fork and create a pull request (it is disabled), but I've found that there is an error in engine.c.

In blockwise operations, the mid is updated for each new block, thus the response_buffer's mid needs to be updated on each block. For GET operations, the response_buffer mid is updated correctly but the client_cb mid is not see here.

If there is a timeout (see here) oc_ri_free_client_cbs_by_mid is called. This function is supposed to notify with 503 the response handler. However, since cb->mid hasn't been updated with the new blocks mid, the transaction id is diferent and thus it doesn't notify the handler.

The solution would be to simply add the following: if(client_cb) client_cb->mid = response_mid; right after/before this.

If someone can explain how I can fork and do a pull request (maybe I just need permissions) I'll gladly do a pull request :)

COAP message deduplication doesn't works properly
Summary: The problem is that history of MIDs is shared among another devices and device as self.

What happens for 2 devices(first with iotivity-lite, second with another implementation(https://github.com/go-ocf/sdk)):

the second device sends GET /oic/res request
the first device sends response with CON, MID=26199 (MID is generated by the first device), and first block for blockwise transfer
the second device send GET for next block with ACK, MID=26199
the first device stores MID 26199 to history for de-duplication
after few exchanges blockwise transfer ends and the second device has whole response for GET /oic/res request
the second device creates new GET /oic/res request with NON, MID=26199 (MID is generated by the second device).
the first device drop the GET /oic/res request because it is considered as duplicate from step 3.
Logs from first device: First occurs of message with mid: 26199

2020-08-18T09:49:06.919189008Z DEBUG: ../../messaging/coap/engine.c <coap_receive:137>: CoAP Engine: received datalen=25 from
2020-08-18T09:49:06.919191825Z DEBUG: ../../messaging/coap/engine.c <coap_receive:138>: coap://192.168.197.88:52405
2020-08-18T09:49:06.919194180Z DEBUG: ../../messaging/coap/engine.c <coap_receive:139>: 68 01 66 57 A7 FB 62 00 4A 6C B2 35 B3 6F 69 63 03 72 65 73 62 27 10 61 2E
2020-08-18T09:49:06.919199658Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:561>: Token (len 8)
2020-08-18T09:49:06.919203430Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:562>: A7 FB 62 00 4A 6C B2 35
2020-08-18T09:49:06.919206412Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:618>: OPTION 11 (delta 11, len 3):
2020-08-18T09:49:06.919208716Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:722>: Uri-Path [oic]
2020-08-18T09:49:06.919210958Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:618>: OPTION 11 (delta 0, len 3):
2020-08-18T09:49:06.919213197Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:722>: Uri-Path [oic/res]
2020-08-18T09:49:06.919215413Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:618>: OPTION 17 (delta 6, len 2):
2020-08-18T09:49:06.919217627Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:663>: Accept [10000]
2020-08-18T09:49:06.919219813Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:618>: OPTION 23 (delta 6, len 1):
2020-08-18T09:49:06.919226376Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:768>: Block2 [2+ (1024 B/blk)]
2020-08-18T09:49:06.919228757Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:814>: -Done parsing-------
2020-08-18T09:49:06.919230990Z DEBUG: ../../messaging/coap/engine.c <coap_receive:177>: Parsed: CoAP version: 1, token: 0xA7FB, mid: 26199
2020-08-18T09:49:06.919233365Z DEBUG: ../../messaging/coap/engine.c <coap_receive:188>: type: ACK
The dropped message with mid: 26199

2020-08-18T09:49:55.742884714Z DEBUG: ../../messaging/coap/engine.c <coap_receive:138>: coap://[fe80:0000:0000:0000:6262:3c03:5549:6ad6]:56220
2020-08-18T09:49:55.742897355Z DEBUG: ../../messaging/coap/engine.c <coap_receive:139>: 58 01 66 57 AF F1 52 AD 5C 24 C4 81 B3 6F 69 63 03 72 65 73 62 27 10 61 1E
2020-08-18T09:49:55.742901198Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:561>: Token (len 8)
2020-08-18T09:49:55.742903559Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:562>: AF F1 52 AD 5C 24 C4 81
2020-08-18T09:49:55.742906143Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:618>: OPTION 11 (delta 11, len 3):
2020-08-18T09:49:55.742909566Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:722>: Uri-Path [oic]
2020-08-18T09:49:55.742918028Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:618>: OPTION 11 (delta 0, len 3):
2020-08-18T09:49:55.742920629Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:722>: Uri-Path [oic/res]
2020-08-18T09:49:55.742936373Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:618>: OPTION 17 (delta 6, len 2):
2020-08-18T09:49:55.742942531Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:663>: Accept [10000]
2020-08-18T09:49:55.742945596Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:618>: OPTION 23 (delta 6, len 1):
2020-08-18T09:49:55.742948200Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:768>: Block2 [1+ (1024 B/blk)]
2020-08-18T09:49:55.742951107Z DEBUG: ../../messaging/coap/coap.c <coap_parse_token_option:814>: -Done parsing-------
2020-08-18T09:49:55.742973224Z DEBUG: ../../messaging/coap/engine.c <coap_receive:177>: Parsed: CoAP version: 1, token: 0xAFF1, mid: 26199
2020-08-18T09:49:55.742977218Z DEBUG: ../../messaging/coap/engine.c <coap_receive:185>: type: NON
2020-08-18T09:49:55.742979478Z DEBUG: ../../messaging/coap/engine.c <coap_receive:233>: method: GET
2020-08-18T09:49:55.742981686Z DEBUG: ../../messaging/coap/engine.c <coap_receive:245>: URL: oic/res
2020-08-18T09:49:55.742983896Z DEBUG: ../../messaging/coap/engine.c <coap_receive:246>: QUERY:
2020-08-18T09:49:55.742986081Z DEBUG: ../../messaging/coap/engine.c <coap_receive:247>: Payload:
2020-08-18T09:49:55.742988290Z DEBUG: ../../messaging/coap/engine.c <check_if_duplicate:97>: dropping duplicate request
Edited 8 months ago by Jozef Kralik

Drop or upload designs to attach

Linked issues
0
Related merge requests
1
introduce macro OC_REQUEST_HISTORY to turnoff deduplication
!175
Avatar for Kishen Maloor

Jozef Kralik @jkralik changed the description 8 months ago
Jozef Kralik @jkralik changed the description 8 months ago
Kishen Maloor
Kishen Maloor @KISHEN · 8 months ago
Maintainer
@jkralik

Firstly, the window of message IDs should be maintained only over incoming requests (code = {GET - DELETE}) and would not include mids from responses. You can see this in the code in messaging/coap/engine.c.

So, in your example, the first device shouldn't have recorded the mid 26199 from the ACK that it received. Instead, it may have been the case that the 2nd device actually reused 26199 over two requests close to each other, which a Client shouldn't do. Do you have the full logs for this run? That way we can verify what happened, and decide what to fix.

It is true that the engine.c maintains a common mid window for requests from different Clients. That was done mostly as an approximation as it seemed like maintaining a window that size for multiple Clients may have been overkill and costed a lot more resources (RAM).

The primary use case for dropping duplicates was during discoveries since at least the Lite stack as Client issues identical requests over both IPv4 and IPv6 and the deduplication would ensure that Servers would respond to only one of those.

For all other cases, it was simply assumed that Clients would usually randomize their choice of "mid" so the likelihood of collisions that you couldn't recover from would be low. This was the idea, but I'm open to further feedback and suggestions.

Edited by Kishen Maloor 8 months ago
Jozef Kralik
Jozef Kralik @jkralik · 8 months ago
Developer
@KISHEN

Do you have the full logs for this run?

No I don't have it. The iotivity-lite device must have have MID near(in range 255) to MID of the second device. But I reproduced the issue. For the attached devsim.zip, the problematic MID is 4426.

Suggestions:

When new MID occurs it stores MID with the current time to the cache and deduplication check if entry is not expired (10s ?). (From logs the dropping occurs after 49seconds).
When iotivity-lite device send a respond for any command GET, POST, CREATE, DELETE with CON, NONCON and mid = getMID() returns a near value of the request MID((req.mid - mid) < max(uint16)/4) then resp.mid = mid+max(uint16)/2
Edited by Jozef Kralik 8 months ago
Jozef Kralik @jkralik added
bug
label 8 months ago
Jozef Kralik
Jozef Kralik @jkralik · 6 months ago
Developer
@KISHEN What do you think ?

Kishen Maloor
Kishen Maloor @KISHEN · 5 months ago
Maintainer
@jkralik

When iotivity-lite device send a respond for any command GET, POST, CREATE, DELETE with CON, NONCON and mid = getMID() returns a near value of the request MID((req.mid - mid) < max(uint16)/4) then resp.mid = mid+max(uint16)/2

The deduplication logic applies only to mids in requests, so only request mids are stored in that sliding window in engine.c. mids that the Server includes in the response are separate and have no impact on further Server operation.

When new MID occurs it stores MID with the current time to the cache and deduplication check if entry is not expired (10s ?). (From logs the dropping occurs after 49seconds).

I'd prefer not to add any further state and/or expiry logic. Perhaps we could try simply lowering the window size. I think currently it's set to 250. So, maybe we could try values <50? That may be sufficient to satisfy the primary use case of dropping duplicate discoveries.

Jozef Kralik
Jozef Kralik @jkralik · 5 months ago
Developer
@KISHEN Ok so I want to suggest to allow set callback by user which handles deduplication. By default the callback will be set to current implementation.

Kishen Maloor
Kishen Maloor @KISHEN · 5 months ago
Maintainer
@jkralik Have you tried lowering the window size in engine.c to see if it mitigates whatever issues you've observed in your deployment?

Jozef Kralik
Jozef Kralik @jkralik · 3 months ago
Developer
@KISHEN It cause the issue with our devices(discover devices test fails 2/100) so I created !175 (merged) where user can disable de-duplication feature.

Hello,

I'm trying to build on ArchLinux and following the setup.sh script is quite easy. I got as far as this command:

make DEBUG=1 SECURE=1 IPV4=1 TCP=1 PKI=1 DYNAMIC=1 CLOUD=1 JAVA=1 IDD=1

But this one ends up with those of errors from ld:

/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:44: multiple definition of `jni_poll_event_thread'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:44: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:45: multiple definition of `jni_sync_lock'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:45: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:46: multiple definition of `jni_sync_lock_attr'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:46: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:47: multiple definition of `jni_cv'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:47: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:48: multiple definition of `jni_cs'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:48: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:50: multiple definition of `jni_quit'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:50: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:122: multiple definition of `cls_ArrayList'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:122: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:123: multiple definition of `cls_OCMainInitHandler'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:123: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:124: multiple definition of `cls_OCAddDeviceHandler'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:124: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:125: multiple definition of `cls_OCClientResponse'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:125: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:126: multiple definition of `cls_OCCloudContext'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:126: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:127: multiple definition of `cls_OCConWriteHandler'; ../port/linux/obj/swig/oc_api_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:127: first defined here
/usr/bin/ld: ../port/linux/obj/swig/oc_cloud_wrap.o:/files/download/Linux/iotivity/otgc-linux/iotivity-lite/swig/iotivity-lite-java/jni/oc_iotivity_lite_jni.h:1

I must have missed something, but I can't figure out what so any pointers are most welcome.

Hello,

I have a use case were I want to expose multiple bluetooth devices as OCF devices.
If I pair one device, I would like to add an ocf device, and if I remove the bluetooth device, to remove the associated device.

Today we only have oc_add_device but no oc_remove_device. I think it would be a nice addition.
I haven't looked at the code yet, but I may be able to add it if you want. (if the code does not require too much rework of course)

Thank you

Hi, I wanted to know if the CVE-2019-9750 was fixed?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9750
If so, in what commit?
thanks in advance :)

Applications simpleserver-TVAppAndAction.c and simpleserver-resourcedefaults.c use IDD file hosted on path c:/users/m.trayer/OCF which is not part of the repository.

Here are errors.
2021-06-03 15:49:01.450 19006-19195/org.openconnectivity.otgc W/System.err: Native code library failed to load. 2021-06-03 15:49:01.450 19006-19195/org.openconnectivity.otgc W/System.err: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "oc_resource_set_secure_mcast" referenced by"/data/app/org.openconnectivity.otgcZfcI22Et7mFTAd07egTxQA==/lib/arm/libiotivity-lite-jni.so"...
I did updated old iotivity stack to new one. But after apply it, it fails load Iotivity stack with these errors.

Any one can help? Thanks

[ branch: eps32 ] during own and onboard to the cloud, lot's of memory is consumed
Open

[ branch: eps32 ] during own and onboard to the cloud, lot's of memory is consumed

As I mentioned during own and onboard heap memory was very consumed. To produce logs I applied patch print_debug.patch

And heap size:xyz occurs every second and describe how many memory is available at the esp32.

Own and Onboard proceeded without crash or abort for memory.

Logs: esp32_just_works_1.log esp32_mfg_1.log

Drop or upload designs to attach

Linked issues
0

heunggu, ahn
heunggu, ahn @ansee7221 · 5 months ago
@jkralik, The log file does not contain IPV6 content in response to the client. I would like to ask if IPV6 response is not available.

DEBUG: C:/Users/admin/source/repos/iotivity-lite/messaging/coap/engine.c <coap_receive:166>: coap://10.112.112.36:59745 ~ Outgoing message of size 1059 bytes to coap://0.0.0.0:0-->coap://10.112.112.36:59745

Edited by heunggu, ahn 5 months ago
Jozef Kralik
Jozef Kralik @jkralik · 5 months ago
Developer
Here is logs from onboarding tool with actions:

Discover via realm IPv6
Own the device
Provision identity certificate
RETRIEVE /oic/sec/cred
RETRIEVE /oic/sec/acl2
Provision auth-crypt RW access to NCRs
RESET device
The previous logs comes from go-sdk which proceed more actions than OBT.

esp32_just_works_onboarding_tool_ipv6.log

Kishen Maloor
Kishen Maloor @KISHEN · 5 months ago
Maintainer
@jkralik

Granted that go-sdk Client may be doing more, but an attempt at an apples to apples comparison of the heap size at the end of onboarding suggests a ~130K free heap with go-sdk and ~160K free heap with the onboarding_tool. It may help to understand why that might be the case.

heunggu, ahn
heunggu, ahn @ansee7221 · 5 months ago
I'm trying to do "Discover" in the IPv6 scope, but there is not response from IUT.

=> This was a configuration issue.

Edited by heunggu, ahn 5 months ago
farid
farid @farid · 3 months ago
I see the same issue... one one the root cause are the number of tls sessions and in esp32 one tls session is 32K by default. This can be reduced but it depends on the server ability to handle tls fragment negociation (Amazon does not)

David Marquez
David Marquez @DavidMarquezUPC · 2 months ago
In my case I can't even onboard successfully, the app crashes with the following. I guess it has to do with esp32 running out of memory

A2 : 0x00000750 A3 : 0x00000750 A4 : 0xffffffff A5 : 0x00000000
A6 : 0x00000000 A7 : 0x00000000 A8 : 0x00000068 A9 : 0x00000750
A10 : 0x00000000 A11 : 0x3ffbc890 A12 : 0x3ffdabb9 A13 : 0x000000bf
A14 : 0x3ffdc7b8 A15 : 0x3ffdabb8 SAR : 0x0000000a EXCCAUSE: 0x0000001c
EXCVADDR: 0x0000075c LBEG : 0x4000c46c LEND : 0x4000c477 LCOUNT : 0x00000000

Backtrace:0x400ea88c:0x3ffb8c80 0x400f008a:0x3ffb8cc0 0x400e9ecd:0x3ffb9ce0 0x400ec641:0x00000000 |<-CORRUPTED
0x400ea88f: oc_process_baseline_interface at /home/david/iot-lite/iotivity-lite/api/oc_server_api.c:147

0x400ea88c: oc_process_baseline_interface at /home/david/iot-lite/iotivity-lite/api/oc_server_api.c:146

0x400f008a: get_csr at /home/david/iot-lite/iotivity-lite/security/oc_csr.c:42

0x400e9ecd: oc_ri_invoke_coap_entity_handler at /home/david/iot-lite/iotivity-lite/api/oc_ri.c:953

0x400ec641: coap_receive at /home/david/iot-lite/iotivity-lite/messaging/coap/engine.c:529
David Marquez
David Marquez @DavidMarquezUPC · 1 month ago
Nevermind I was using a newer version of esp-idf, which was probably causing the issue. I followed the installation steps in the README again (they were updated a few weeks ago) and now cloud works. It does use up a lot of memory though

In iotivity-lite/port/linux, when I run:
make all

it returns

gcc -o server ../../apps/server_linux.c libiotivity-constrained-server.a -DOC_SERVER -fPIC -fno-asynchronous-unwind-tables -fno-omit-frame-pointer -ffreestanding -Os -fno-stack-protector -ffunction-sections -fdata-sections -fno-reorder-functions -fno-defer-pop -fno-strict-overflow -I./ -I../../include/ -I../../ -std=gnu99 -Wall -Wextra -Werror -pedantic -Wl,--gc-sections -I../../deps/mbedtls/include -D__OC_RANDOM -DOC_PKI -DOC_DYNAMIC_ALLOCATION -DOC_SECURITY -lm -pthread -lrt

libiotivity-constrained-server.a(oc_tls.o): In function 'oc_tls_free_peer':

oc_tls.c:(.text.oc_tls_free_peer+0x1a): undefined reference to 'oc_session_end_event'

libiotivity-constrained-server.a(oc_tls.o): In function 'process_thread_oc_tls_handler':

oc_tls.c:(.text.process_thread_oc_tls_handler+0x521): undefined reference to 'oc_session_start_event'

collect2: error: ld returned 1 exit status

Makefile:234: recipe for target 'server' failed

make: *** [server] Error 1

When Cloud sends an error response, Lite cannot communicate with the Cloud again.
SECURE flag is set for the compilation.
Steps to reproduce
1.- Cloud server sample registers in the OCF Cloud using unsecure configuration.
2.- Cloud client sample registers in the OCF Cloud using unsecure configuration.
3.- Cloud client discovers resources.
4.- Cloud client sends a get request to the "/light/1" resource.
5.- Cloud server returns an Unauthorized response.
6.- Cloud tries to discover resources again and it cannot communicate with the OCF Cloud.

When compiling the project with gcc 7.5 and clang scan-build-3.9, line 327 in oc_rep.c indicates a possible null pointer dereference:

Compiling oc_rep.c...
<redacted>/oc/api/oc_rep.c:334:11: warning: Dereference of null pointer (loaded from variable 'prev')
          (*prev)->next = _alloc_rep();
          ^~~~~~~

First I have met unsatisfiedLinkError with symbol "oc_resource_set_secure_mcast".
After that my team researched about the error in code, and made it fixed by modifying make file options.
But as soon as fixing it, another error appeared.
java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "oc_oscore_handler" referenced by "/data/app/org.openconnectivity.otgc-SkEMhEmWOyF9YO2QZX48rQ==/lib/arm/libiotivity-lite-jni.so"...

These errors look like relating to oscore, could you help me please? Thanks.

Build from this document

Command in case of build error

make NDK_HOME=~/android-arm-23 ANDROID_API=23 ANDROID_ABI=armeabi

make NDK_HOME=~/android-arm-23 ANDROID_API=23 DEBUG=1 SECURE=1 IPV4=1 TCP=0 PKI=1 DYNAMIC=1 CLOUD=0 JAVA=1 IDD=1

Error message

ld: error: duplicate symbol: cls_ArrayList
defined at oc_iotivity_lite_jni.h:122 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:122)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_ArrayList)
defined at oc_iotivity_lite_jni.h:122 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:122)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_ArrayList+0x0)

ld: error: duplicate symbol: cls_OCAddDeviceHandler
defined at oc_iotivity_lite_jni.h:124 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:124)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCAddDeviceHandler)
defined at oc_iotivity_lite_jni.h:124 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:124)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCAddDeviceHandler+0x0)

ld: error: duplicate symbol: cls_OCClientResponse
defined at oc_iotivity_lite_jni.h:125 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:125)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCClientResponse)
defined at oc_iotivity_lite_jni.h:125 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:125)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCClientResponse+0x0)

ld: error: duplicate symbol: cls_OCCloudContext
defined at oc_iotivity_lite_jni.h:126 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:126)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCCloudContext)
defined at oc_iotivity_lite_jni.h:126 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:126)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCCloudContext+0x0)

ld: error: duplicate symbol: cls_OCCloudHandler
defined at oc_iotivity_lite_jni.h:155 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:155)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCCloudHandler)
defined at oc_iotivity_lite_jni.h:155 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:155)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCCloudHandler+0x0)

ld: error: duplicate symbol: cls_OCConWriteHandler
defined at oc_iotivity_lite_jni.h:127 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:127)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCConWriteHandler)
defined at oc_iotivity_lite_jni.h:127 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:127)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCConWriteHandler+0x0)

ld: error: duplicate symbol: cls_OCCoreAddDeviceHandler
defined at oc_iotivity_lite_jni.h:145 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:145)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCCoreAddDeviceHandler)
defined at oc_iotivity_lite_jni.h:145 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:145)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCCoreAddDeviceHandler+0x0)

ld: error: duplicate symbol: cls_OCCoreInitPlatformHandler
defined at oc_iotivity_lite_jni.h:146 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:146)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCCoreInitPlatformHandler)
defined at oc_iotivity_lite_jni.h:146 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:146)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCCoreInitPlatformHandler+0x0)

ld: error: duplicate symbol: cls_OCCreds
defined at oc_iotivity_lite_jni.h:147 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:147)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCCreds)
defined at oc_iotivity_lite_jni.h:147 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:147)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCCreds+0x0)

ld: error: duplicate symbol: cls_OCDiscoveryAllHandler
defined at oc_iotivity_lite_jni.h:129 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:129)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCDiscoveryAllHandler)
defined at oc_iotivity_lite_jni.h:129 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:129)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCDiscoveryAllHandler+0x0)

ld: error: duplicate symbol: cls_OCDiscoveryHandler
defined at oc_iotivity_lite_jni.h:128 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:128)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCDiscoveryHandler)
defined at oc_iotivity_lite_jni.h:128 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:128)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCDiscoveryHandler+0x0)

ld: error: duplicate symbol: cls_OCEndpoint
defined at oc_iotivity_lite_jni.h:148 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:148)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCEndpoint)
defined at oc_iotivity_lite_jni.h:148 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:148)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCEndpoint+0x0)

ld: error: duplicate symbol: cls_OCFactoryPresetsHandler
defined at oc_iotivity_lite_jni.h:130 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:130)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCFactoryPresetsHandler)
defined at oc_iotivity_lite_jni.h:130 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:130)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCFactoryPresetsHandler+0x0)

ld: error: duplicate symbol: cls_OCGetPropertiesHandler
defined at oc_iotivity_lite_jni.h:131 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:131)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCGetPropertiesHandler)
defined at oc_iotivity_lite_jni.h:131 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:131)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCGetPropertiesHandler+0x0)

ld: error: duplicate symbol: cls_OCInitPlatformHandler
defined at oc_iotivity_lite_jni.h:132 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:132)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCInitPlatformHandler)
defined at oc_iotivity_lite_jni.h:132 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:132)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCInitPlatformHandler+0x0)

ld: error: duplicate symbol: cls_OCMainInitHandler
defined at oc_iotivity_lite_jni.h:123 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:123)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCMainInitHandler)
defined at oc_iotivity_lite_jni.h:123 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:123)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCMainInitHandler+0x0)

ld: error: duplicate symbol: cls_OCObtAclHandler
defined at oc_iotivity_lite_jni.h:150 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:150)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCObtAclHandler)
defined at oc_iotivity_lite_jni.h:150 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:150)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCObtAclHandler+0x0)

ld: error: duplicate symbol: cls_OCObtCredsHandler
defined at oc_iotivity_lite_jni.h:151 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:151)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCObtCredsHandler)
defined at oc_iotivity_lite_jni.h:151 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:151)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCObtCredsHandler+0x0)

ld: error: duplicate symbol: cls_OCObtDeviceStatusHandler
defined at oc_iotivity_lite_jni.h:153 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:153)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCObtDeviceStatusHandler)
defined at oc_iotivity_lite_jni.h:153 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:153)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCObtDeviceStatusHandler+0x0)

ld: error: duplicate symbol: cls_OCObtDiscoveryHandler
defined at oc_iotivity_lite_jni.h:152 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:152)
../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCObtDiscoveryHandler)
defined at oc_iotivity_lite_jni.h:152 (iotivity-lite-java/jni/oc_iotivity_lite_jni.h:152)
../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCObtDiscoveryHandler+0x0)

ld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
clang110: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [Makefile:155：build_jni_so] error 1
make[1]: Leave directory “/home/ubuntu64/Word/project/iotivity-lite/swig”
make: *** [Makefile:368：swig] error 2

Hello,

When ocf server loss "Encrypted Alter" package, new "Client Hello" won't be replayed. "192.168.10.123" is client,"192.168.10.111" is server.

Update Android build to build without the deprecated standalone tools
Currently the Android build uses the standalone tool chain when the standalone tool chain is installed a warning is printed stating that the standalone tool chain is no longer necessary.

./android-sdk-linux/ndk-bundle/build/tools/make_standalone_toolchain.py --arch arm --api 23 --install-dir ~/android-arm-23
WARNING:main:make_standalone_toolchain.py is no longer necessary. The
$NDK/toolchains/llvm/prebuilt/linux-x86_64/bin directory contains target-specific scripts that perform
the same task. For example, instead of:

$ python $NDK/build/tools/make_standalone_toolchain.py \
    --arch arm --api 23 --install-dir toolchain
$ toolchain/bin/clang++ src.cpp

Instead use:

$ $NDK/toolchains/llvm/prebuilt/linux-x86_64/bin/armv7a-linux-androideabi23-clang++ src.cpp

We do not know how long the standalone tool chain will continue to be supported by Google so we should update the make files to move away from from the standalone tool chain.

new Interface for CREATE, DELETE & LINK_UPDATE operations
Open

new Interface for CREATE, DELETE & LINK_UPDATE operations

This is the implementation task corresponding to BZ 1229 & BZ 2716.
There is a branch in IoTivity for implementing this change:
"feat-linkupdate-and-collection-access-control"

JIRA migration meta data

JIRA Issue ID: LITE-29
Reporter: nathanheldtsheller
Assignee: kmaloor
Creator: nathanheldtsheller
Created at: 2018-12-12T21:50:52.000-0800
Found in Version: IoTivity 2.0.0
Fix in Version: None
Issue Severity: Major
Reproducibility: Always (100%)
Operating System: Ubuntu
Hardware/ OEM Platform: None
External URL: None
Bugzilla ID: 1229, 2716
Product: None
Status: To Do
Components: base stack
Priority: P2
Due Date: None
Issue Type: New Feature
END of JIRA migration meta data

Drop or upload designs to attach

Linked issues
0

Rami Alshafi
Rami Alshafi @rami · 1 year ago
Owner
user
I don't think the plan is to complete this IoTivity branch, but instead to create a similar feature branch on Lite and do the work there.
user
am I wrong about that? Is the plan to implement in main, or Lite?

Rami Alshafi
Rami Alshafi @rami · 1 year ago
Owner
Nathan, that is the intent that this will be done only in IoTivity Lite. Hence my update to the Jira ticket
LITE-29
with the referenced Bugzilla entries. Not familiar with Jira and thought the update was only affecting the
LITE-29
Jira ticket. Maybe there is a cross-reference to an equivalent IoTivity ticket which could get closed.

Rami Alshafi
Rami Alshafi @rami · 1 year ago
Owner
user
we're on the same page: this will be implemented in Lite only.
user
has told Mitch he'll implement. I assume Kishen will use a feature branch and have it passing the new CTT tests for this behavior, and then merge it back... as soon as the feature branch is passing CTT (but before it's merged back to master) you have your 3-pillar alignment for BZ1229!

Rami Alshafi
Rami Alshafi @rami · 1 year ago
Owner
Kishen, could you weigh in on the implementation impact of this requirement for the "oic.if.delete" OCF Interface? This was a review comments on BZ #2716 specification text.
In 7.6.3.10.2
When a Client performs a DELETE operation on a Resource, the Server shall remove the Link which was created in the Collection where the Resource was created.
In addition, the Server
shall
remove all Links to the deleted Resource that were added to any other Collections on the Server with the "oic.if.linkadd" OCF Interface.
This would seem to require that for each resource we keep a table of links that point to it, and maintain it when links are added or removed. Is this how iotivity lite is implemented?

Rami Alshafi
Rami Alshafi @rami · 1 year ago
Owner
Hi Richard,
Neither the "oic.if.linkadd" interface nor the DELETE operation (on created resources)

is yet implemented.
At the moment, a created resource only has a reference to the Collection that created it

so that both the resource and that link (in the Collection) may be removed upon a factory

reset.

(As a side note, created resources separately appear as links in /oic/res responses

if they're discoverable. When a resource is deleted during a RESET, that link in /oic/res

would automatically go away. In otherwise, nothing special need be done for /oic/res fyi)
When support for "oic.if.linkadd" is completed, I imagine we'd maintain a list

of Collections linking to created resources. That should facilitate the behavior you describe.

OCCred_credType_get returns 0 (Unknown), and OCCred_credId_get returns 0 for all credential types when used in Java/Linux. When used in Java/Android or C/Linux, however, they return proper codes and work as expected.

For Linux the compilation flags are:
DEBUG=1 SECURE=1 IPV4=1 TCP=1 PKI=1 DYNAMIC=1 CLOUD=1 JAVA=1 IDD=1

Make COLLECTIONS_IF_CREATE available in SWIG aka Java language bindings
This is a task to expose the API that were added to IoTivity-lite under the OC_COLLECTIONS_IF_CREATE macro to the Java language using the SWIG interfaces.

Build for Android Api 27 leads to "UnsatisfiedLinkError: dlopen failed: cannot locate symbol "oc_is_owned_device""
Open

Build for Android Api 27 leads to "UnsatisfiedLinkError: dlopen failed: cannot locate symbol "oc_is_owned_device""

Hello,

I have followed the step to build iotivity-lite for Android as explained here: https://iotivity.org/documentation/building-iotivity-android

The command used to generate it was: make NDK_HOME=~/android-build/android-arm64-27 ANDROID_API=27 ANDROID_ABI=arm64-v8a IPV4=1 DEBUG=1 SECURE=0

Then I added the iotivity-lite.jar to my libs folder and the libiotivity-lite-jni.so to the src/main/jniLibs/arm64-v8a.

When I run the app and try to init the stack (dummy code for now):

OcPlatform.getInstance().systemInit(object : OCMainInitHandler {
override fun initialize(): Int {
Log.d("AAAAA", "MyClass-initialize: ")
return 0
// TODO("Not yet implemented")
}

        override fun registerResources() {
            Log.d("AAAAA", "MyClass-registerResources: ")

// TODO("Not yet implemented")
}

        override fun requestEntry() {
            Log.d("AAAAA", "MyClass-requestEntry: ")

// TODO("Not yet implemented")
}

    })

I get the following error:

2020-09-11 22:22:50.787 23689-23689/my.app.package W/System.err: Native code library failed to load.
2020-09-11 22:22:50.787 23689-23689/my.app.package W/System.err: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "oc_is_owned_device" referenced by "/data/app/my.app.package-cinCjuUX7hShiEk9-VBcaw==/lib/arm64/libiotivity-lite-jni.so"...
Can anyone point me what I could be doing wrong?

Drop or upload designs to attach

Linked issues
0

Andre Peixoto
Andre Peixoto @ampeixoto · 7 months ago
After I removed the SECURE=0 from the make command, this error stopped but a new one raises:

2020-09-14 17:30:58.352 15950-16588/my.app.package W/System.err: Native code library failed to load.
2020-09-14 17:30:58.352 15950-16588/my.app.package W/System.err: java.lang.UnsatisfiedLinkError: dlopen failed: cannot locate symbol "coap_remove_observers_on_dos_change" referenced by "/data/app/my.app.package-20v-zis4z74eD6sngNv9yw==/base.apk!/lib/arm64-v8a/libiotivity-lite-jni.so"...
Edited by Andre Peixoto 7 months ago

merge
easysetup branch into master

[Improvement] Build option to remove JW OTM
Open

[Improvement] Build option to remove JW OTM

JW is optional OTM in Core Security, and some OCF verticals do not have plans to use/support it due to low security guarantees. Since IoTivity Lite should be a common codebase, an easy option is needed to remove JW OTM support.

JIRA migration meta data

JIRA Issue ID: LITE-101
Reporter: oleksandr
Assignee: avolkov
Creator: oleksandr
Created at: 2019-11-14T14:48:29.000-0800
Found in Version: latest
Fix in Version: None
Issue Severity: Normal
Reproducibility: Always (100%)
Operating System: None
Hardware/ OEM Platform: None
External URL: None
Bugzilla ID: None
Product: None
Status: Done
Components: security
Priority: Undecided
Due Date: None
Issue Type: Task
END of JIRA migration meta data
Edited 1 year ago by Oleksandr Andrieiev

Drop or upload designs to attach

Linked issues
0

Rami Alshafi
Rami Alshafi @rami · 1 year ago
Owner
Patch is ready for review in
29880
and
29895

Oleksandr Andrieiev @oleksandr assigned to @oleksandr 1 year ago
Oleksandr Andrieiev @oleksandr changed title from Build option to remove JW OTM to [Improvement] Build option to remove JW OTM 1 year ago
Oleksandr Andrieiev @oleksandr assigned to @KISHEN and unassigned @oleksandr 9 months ago

I'm struggling to get the library to build for arm64_v8a following the steps in the README due to the tool chain missing gcc.

Is there a specific version of the NDK that i need to use to get this to build?

make NDK_HOME=/opt/android-ndk/23/arm64 ANDROID_API=23 ANDROID_ABI=arm64
...
"/opt/android-ndk/23/arm64"/bin/arm-linux-androideabi-gcc -c -o  ../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o iotivity-lite-java/jni/oc_api_wrap.c -fPIC -fno-asynchronous-unwind-tables -fno-omit-frame-pointer -ffreestanding -Os -fno-stack-protector -ffunction-sections -fdata-sections -fno-strict-overflow -Wno-unused-function -I""/opt/android-ndk/23/arm64"/sysroot/usr/include/" -I../ -I../include -I../port -I../util/ -I../deps/tinycbor/src/ -I../security -I../cloud -I../port/android -std=gnu99 -Wall -DOC_CLIENT -DOC_SERVER -DOC_IPV4 -DOC_DYNAMIC_ALLOCATION -DLONG_BIT=64 -DOC_CLOUD -DOC_SECURITY -DOC_IDD_API -DOC_PKI -DOC_TCP -D__ANDROID_API__=23 -I../deps/mbedtls/include -D__OC_RANDOM
/bin/sh: 1: /opt/android-ndk/23/arm64/bin/arm-linux-androideabi-gcc: not found

This binary does however seem to exist when building for armeabi but this results in some duplicate duplicate symbol errors:

make NDK_HOME=/opt/android-ndk/23/arm ANDROID_API=23 ANDROID_ABI=armeabi
...
"/opt/android-ndk/23/arm"/bin/arm-linux-androideabi-gcc -shared  ../port/android/arm-linux-androideabi-obj/swig/*.o ../port/android/arm-linux-androideabi-obj/*.o ../port/android/arm-linux-androideabi-obj/client_server/*.o ../port/android/arm-linux-androideabi-obj/cloud/*.o -lm -llog -o iotivity-lite-java/libs/libiotivity-lite-jni.so
ld: error: duplicate symbol: cls_ArrayList
>>> defined at oc_api_wrap.c
>>>            ../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_ArrayList)
>>> defined at oc_cloud_wrap.c
>>>            ../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_ArrayList+0x0)

ld: error: duplicate symbol: cls_OCAddDeviceHandler
>>> defined at oc_api_wrap.c
>>>            ../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCAddDeviceHandler)
>>> defined at oc_cloud_wrap.c
>>>            ../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCAddDeviceHandler+0x0)

ld: error: duplicate symbol: cls_OCClientResponse
>>> defined at oc_api_wrap.c
>>>            ../port/android/arm-linux-androideabi-obj/swig/oc_api_wrap.o:(cls_OCClientResponse)
>>> defined at oc_cloud_wrap.c
>>>            ../port/android/arm-linux-androideabi-obj/swig/oc_cloud_wrap.o:(.bss.cls_OCClientResponse+0x0)