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 <thiago.macie...@intel.com> 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 > Software Architect - Intel Open Source Technology Center > >
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
