Hi Khaled, Its quite simple - constrained OSes may be configured in different ways that are highly dependent on the application in question. You might set up nodes that take on one or the other role in an IPv6 mesh, for e.g., or set different names to advertise over BLE, etc., not to mention the memory allocation sizes. This is why the port/<OS>/* adaptations for constrained OSes are to strictly be taken as samples and the port/* interfaces have been (by design) made simple enough for anyone to understand.
As you noticed, this works differently for the rich OS (Linux, Windows, etc.) adaptations that can be generic as they’re able to consume higher-level APIs from those OSes. The Zephyr sample used to work as-is and its likely that its network stack has changed a bit since. IoTivity-Constrained is currently being updated for OCF 1.3 compliance (security, etc.) so if you have found a fix for this issue that works please just directly submit it to gerrit and I could merge it in. Thanks, -Kishen. - Kishen Maloor Intel Open Source Technology Center From: <[email protected]> on behalf of Khaled Elsayed <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Tuesday, September 19, 2017 at 1:45 AM To: "Macieira, Thiago" <[email protected]> Cc: iotivity-dev <[email protected]> Subject: Re: [dev] IoTivity constrained zephyr port connectivity issues Hi, Actually, in theory this is correct. However, as far as I understand the way the iotivity-constrained ports work is that this is done in the function oc_connectivity_init as a way to help developers call a single platform-independent function to initialize the interfaces. This is the case for RIOT and Contiki. For RIOT oc_connectivity_init does eventually call gnrc_ipv6_netif_init_by_dev which does initialization of the IP address. In Contiki, it starts the ip_adapter_process which also sets IP address. For zephyr it binds the multicast address and does not set a link local or global address for the interface and this is where the bug seems to be. The exception is the linux port which should of course starts with everything in place via the linux box setup. On Mon, Sep 18, 2017 at 4:38 PM, Thiago Macieira <[email protected]> wrote: On Monday, 18 September 2017 01:29:20 PDT Khaled Elsayed wrote: > es, but you closed it as invalid. This is part of the release code for > zephyr in the file port/zephyr/src/ipadpater.c. > > It was not in my code :-) > > It should be corrected in the iotivity-constrained zephyr port source >code. > I can file an issue or make a new pull request on github. > > Please advise Correct, because setting up the IP addresses is out of scope. You must do that in your application. -- Thiago Macieira - thiago.macieira (AT) intel.com <http://intel.com> Software Architect - Intel Open Source Technology Center _______________________________________________ iotivity-dev mailing list [email protected] https://lists.iotivity.org/mailman/listinfo/iotivity-dev
