On quarta-feira, 22 de junho de 2016 10:33:18 PDT ??? wrote: > Dear developers, > > I'm trying to run IoTivity on three IP devices. > - Device 1 : WiFi > - Device 2 : Both WiFi and Thread > - Device 3 : Thread > > Each device has IPv6 address and IP connections are established each other. > I confirmed using ping6 between Device 1 and Device 3 through Device 2.
Hello Joonghong If you can ping6 from one device to another, that means you've got Layer 3 (IP) connectivity between those two devices. That leads me to the conclusion that Device 2 must be working as a Layer 1, Layer 2 or Layer 3 connection (respectively, hub, switch or router). Layer 1 is extremely unlikely. So which one is it: Layer 2 or Layer 3? Or asked differently: are Device 1 and Device 3 in the same network segment? Do they have the same IPv6 prefix? > I would like to route IoTivity packets from Device 1(client) to Device > 3(server) through Device 2(gateway). > Let me give you more information. I need more information on your network to be able to give a better reply. See above. If it's a Layer 2 connection, then all three devices are in the same network segment and they all have the same IPv6 prefix. Same network segment implies "same multicast domain", so anything that Device 2 needs to do falls outside of IoTivity's responsibility. We couldn't help you. Doing it as a Layer 2 is also a violation of Thread recommendations on how to set up your network. If it is a Layer 3 connection, then we have separate network segments, separate multicast domains and different IPv6 prefixes. That means a discovery from either Device 1 or 3 the way we're doing will never reach the other device. But both devices should reach[1] Device 2. To support a network of this manner, you need to make Device 2 behave as a Resource Directory. That is, it needs to act as an intermediary and answer any queries received in one network segment with the information received in the other. It should NOT simply relay queries, as that would be a violation of the Thread recommendations on forwarding of packets, but should instead cache discoveries from the Thread side, at least. Implementing a Resource Directory is not IoTivity's job (not yet, anyway). Your application is the RD, which means you need to write the code for that. [1] modulo bugs. The Thread side requires a realm-local multicast discovery but I don't think we're doing realm-local. > Devices are ARM-based devices, and I'm using SimpleClientServer > applications. (/resources/csdk/stack/samples/linux/) Between two devices, I > tested ocserverbasicops and occlientbasicops then succeeded. For testing > three devices, I used ocrouting between ocserverbasicops and > occlientbasicops. I saw some packets are transferred between ocrouting and > ocserverbasicops through tcpdump, but I'm not sure the packet types or > process. As you can imagine, once occlientbasicops runs I could not get any > discovery result from ocserverbasicops. I'm not sure but I can see some > discovery messages in occlientbasicops device, and these seem to be from > ocrouting device. Routing as currently implemented in IoTivity is a misfeature and will not be standardised. Resource Directory and Bridging are the correct, long-term solutions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
