Hi, I found the bug. The zephyr network initialization did not add a unicast IPv6 address to the default interface.
Insert the following lines after line 228 in oc_connectivity_init in port/zephyr/src/ipadpater.c will solve the problem. Will update the JIRA ticket I filed for this https://jira.iotivity.org/browse/IOT-2708. /* Add unicast IPV6 address to interface so that node can communicate */ if (net_addr_pton(AF_INET6, CONFIG_NET_APP_MY_IPV6_ADDR, &in6addr_my) < 0) { NET_ERR("Invalid IPv6 address %s", CONFIG_NET_APP_MY_IPV6_ADDR); } struct net_if_addr *ifaddr = net_if_ipv6_addr_add(net_if_get_default(), &in6addr_my, NET_ADDR_MANUAL, 0); On Thu, Sep 14, 2017 at 6:26 PM, Thiago Macieira <thiago.macie...@intel.com> wrote: > On Thursday, 14 September 2017 06:36:44 PDT Khaled Elsayed wrote: > > > Why would it not? You seem to be confusing the source address of the > reply > > > to > > > the destination address. You've shown the addresses on the Linux > system, > > > which > > > would be the destination of any packet received. The > > > fe80::200:5eff:fe00:53d8 > > > address is the source. > > > > So this would be the link local address of the qemu on the other side of > > the tap0 link I guess. Correct? > > Yes. > > > > First of all, make sure the network is working. Ping the addresses and > > > ensure > > > that there's communication. > > > > The network is not fully working. If I ping6 -I tap0 > > fe80:0000:0000:0000:0200:5eff:fe00:53d8 > > Or ping6 -I tap0 2001:db8::1 > > The response is that the network is not reachable. Seems like problem in > > routing table is not aware that this address is reachable through the > tap0 > > (although it should) or that the iotivity code is not properly > initializing > > the network interface it is supposed to be working with. > > IoTivity does not initialise networking. That's out of scope. You must > initialise it and then allow the IoTivity stacks to start. > > > However, the iotivity endpoint responds properly to the multicast > discovery > > and responds with its global IPv6 address as shown in the logs. > > Interesting. I don't think this misconfiguration is possible on Linux, so > my > guess would be that your Zephyr side is not properly configured. > > > When I try other zephyr networking examples like samples/net/http_server > > samples/net/echo_server all pings and connections work perfectly. I am > > suspecting that there are some issues in properly binding network address > > with the qemu application in the case of iotivity constrained. RIOT is > > working fine. I will try to compare how network init is done in > http_server > > and then in the iotivity zephyr port to see if the bug can be solved. > > -- > 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
