IPv6 discovery problems with OTGC and iotvity-constrained

[nmeum]

I am currently unable to discovery iotivity-constrained sample
applications, e.g. port/linux/simpleserver with OTGC.

I built iotivity-constrained using:

make DEBUG=1 SECURE=1

and started port/linux/simpleserver and the OTGC application on the
same machine.

OTGC didn't give many any useful error reports, it only stated that
discovery failed. I therefore observed the communication between OTGC
and iotivity-constrained with wireshark and made the following
observations:

1. iotivity-constrained seems to use CoAP block (RFC 7959) for the
   /oic/res resource.
2. The initial discovery request is sent by OTGC from the link local
   IPv6 address of my interface to the OCF multicast group.
3. iotivity-constrained response with the first of two Block 2
   responses.
4. OTGC requests the second block from the global IPv6 address of the
   interface.
5. iotivity-constrained is not able to map this IPv6 address to an
   initiated block transfer, prints a initiating block-wise transfer with request for block_num > 0 error message and sends a RST
   response to OTGC.

I consider this a bug in OTGC as it should use the same IPv6 source
address for the request to the multicast group and the request for
receiving additional CoAP block2 blocks.

In the meantime a dirty workaround is to disable the source address
check in iotivity constrained. For instance using the following patch:

diff --git a/api/oc_blockwise.c b/api/oc_blockwise.c
index 6e92e8a..3dcd289 100644
--- a/api/oc_blockwise.c
+++ b/api/oc_blockwise.c
@@ -267,10 +267,11 @@ oc_blockwise_find_buffer(oc_list_t list, const char *href, size_t href_len,
                          const char *query, size_t query_len,
                          oc_blockwise_role_t role)
 {
+  (void)endpoint;
+
   oc_blockwise_state_t *buffer = oc_list_head(list);
   while (buffer) {
     if (strncmp(href, oc_string(buffer->href), href_len) == 0 &&
-        oc_endpoint_compare(&buffer->endpoint, endpoint) == 0 &&
         buffer->method == method && buffer->role == role &&
         query_len == oc_string_len(buffer->uri_query) &&
         memcmp(query, oc_string(buffer->uri_query), query_len) == 0) {

With this workaround I was able to discovery the iotivity-constrained
server. I was, however, not able to use the generic client
functionality and pressing the RFNOP button in the GUI still causes an
error to be emitted by OTGC. If you any hints on how to fix that I would
be very glad to hear them.

[dbartolomea]

Dear @nmeum ,
OCF plans to upload to this public repo a new OTGC version shortly. Please, try to test again once this happens. This version includes logs at IoTivity level (note that OTGC is based on IoTivity and not on IoTivity-Constrained or -Lite).
Thanks!
Regards,
Diego B.