Hi Kishen Thanks for the follow-up. Yes, I will submit it although I would like to have a more generic fix. This fix uses the hard-wired address in the prj.conf file. Would like to have an option of using auto-address generation if the network has a router (e.g. radvd) distributing prefixes.
Khaled On Tue, Sep 19, 2017 at 4:22 PM, Maloor, Kishen <kishen.mal...@intel.com> wrote: > 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: <iotivity-dev-boun...@lists.iotivity.org> on behalf of Khaled > Elsayed <khaledi...@gmail.com> > Reply-To: "khaledi...@gmail.com" <khaledi...@gmail.com> > Date: Tuesday, September 19, 2017 at 1:45 AM > To: "Macieira, Thiago" <thiago.macie...@intel.com> > Cc: iotivity-dev <iotivity-dev@lists.iotivity.org> > 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 > <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 <http://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
