Hi Thiago, Please find replies/queries below:
On Wed, Sep 13, 2017 at 9:21 PM, Thiago Macieira <thiago.macie...@intel.com> wrote: > On quarta-feira, 13 de setembro de 2017 05:00:10 PDT Khaled Elsayed wrote: > > 2- Zephyr is supposed to be working on tap0 interface with the following > > parameters: tap0 Link encap:Ethernet HWaddr 3e:c1:37:b6:fa:49 > > inet addr:192.0.2.2 Bcast:0.0.0.0 Mask:255.255.255.0 > > inet6 addr: 2001:db8::2/64 Scope:Global > > inet6 addr: fe80::3cc1:37ff:feb6:fa49/64 Scope:Link > > However, when reply to multicast discovery is received by linux client it > > arrives from address: DEBUG: ipadapter.c <network_event_thread:274>: > > Incoming message from [fe80:0000:0000:0000:0200:5eff:fe00:53d8] > > > > This address has nothing to do with tap0 or the other interface > > > > enp0s3 Link encap:Ethernet HWaddr 08:00:27:20:03:50 > > inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0 > > inet6 addr: fe80::dccc:db0a:2908:e6fb/64 Scope:Link > > > > So, why do the zephyr server response come from this address? > > 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? > > The client > > properly identifies the /light/1 resource endpoint properly Resource > > /light/1 hosted at endpoints: > > [2001:0db8:0000:0000:0000:0000:0000:0001]:53378 > > but when it sends requests to this global address, it does not seem to > reach > > server and therefore stops the observe and progress stops. > > > > Could someone help? > > 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. However, the iotivity endpoint responds properly to the multicast discovery and responds with its global IPv6 address as shown in the logs. 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. Best, Khaled > Second, if the query is sent to a link-local multicast, the source address > will be link-local and therefore any replies will use link-local too. So > the > "fe80" addresses are correct. > > -- > 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
