Vijay, Please examine CAAdapterIsSameSubnet, used in caipserver.c, defined in caadapterutils. It uses the output of CAIPGetInterfaceSubnetMask, defined in caipnwmonitor.c, and the interface list maintained. I suspect all this code is so innocuous that it won't interfere with remote access, but I can't be sure. It certainly doesn't help anything.
John From: Kesavan, Vijay S Sent: Wednesday, June 17, 2015 3:39 PM To: Light, John J; iotivity-dev at lists.iotivity.org Subject: RE: Proposal for IP Adapter and request for feedback John, Please can you elaborate on the need for "After each message is received, the source address of the message is tested for being on the same subnet as the interface on which the message was received." - asking since this test will fail on the adaptor supporting remote access. --Vijay From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Light, John J Sent: Wednesday, June 17, 2015 11:20 AM To: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: [dev] Proposal for IP Adapter and request for feedback All, I recently completed the patch titled "IP address plumbing changes to support IPv6". Now I am preparing to provide the IPv6 capability itself. This work will primarily affect the IP Adapter since the data paths it requires were handled in the previous patch. There are two ways to approach the remaining IPv6 work, and I want a feedback on how this work should be accomplished. I can * Make a minimal change to the existing IP Adapter code, or * Simplify the existing code so that adding IPv6 doesn't make it more complicated. Here I will spell out the technical issues involved with the two approaches. Here is a quick summary of the existing IP Adapter code issues that might change. 1. Create two sockets for every interface that can support IP addressing, one each for secure and non-secure connections. These sockets come and go as network interfaces appear and disappear. 2. A thread dedicated to continually scanning the network interfaces to maintain a separate list of interfaces for use by the IP Adapter. This happens every two seconds. 3. The IP Adapter currently allocates non-multicast ports from the range 6298-6307, using a loop to test them for availability. 4. After each message is received, the source address of the message is tested for being on the same subnet as the interface on which the message was received. This test involves determining the subnet mask of the associated subnet and comparing the source and destination addresses in the subnet mask bits. Here is how I would simplify the IP Adapter, relating to the above issues issues. 1. A total of six sockets will be created at IoTivity startup. They will remain unchanged until shutdown. a. These are the sockets. i. Socket A: non-secure, multicast listen for IPv6 and IPv4. ii. Socket B: secure, multicast listen for IPv6 and IPv4. iii. Socket C: non-secure, unicast send/recv, multicast send for IPv6. iv. Socket D: secure, unicast send/recv, multicast send for IPv6. v. Socket E: non-secure, unicast send/recv, multicast send for IPv4. vi. Socket F: secure, unicast send/recv, multicast send for IPv4. b. If the application asks only for IPv6 communication, only Sockets ABCD are needed. c. If the application asks only for secure communications, only Sockets ABDF are needed. d. Sockets CDEF would be bound to INADDR_ANY so they can handle IP traffic from any interface, even as interfaces come and go. 2. The network monitor will no longer run on its own thread, and it will be called only when an multicast is requested. a. When a multicast is sent, the network monitor will fetch a list of IP interfaces, and the multicast will be sent to that list. b. This eliminates the 1-2 second latency between enabling an interface and being able to use it. This will become more important as 6LoWPAN is adopted. As soon as the interface is created, it can be used by IoTivity. c. The use of INADDR_ANY in Sockets CDEF eliminates any further need for the network monitor. d. The network monitor no longer needs to call back into the IP Adapter to update a list, so all the code related to that callback can be eliminated. 3. The IP Adapter will no longer allocate ports other than the CoAP multicast ports. a. The ports 6298-6207 are in the range assigned by IANA, and we have no right to use them. While ports 6298 and 6299 are currently unassigned by IANA, ports 6300, 6301, and 6306 are assigned, and our use of them is a violation of network standards. b. The socket mechanism provides a simple method of assigning ports, and it's much simpler. Simply request port 0, and the network will supply a port which is not used by anyone else. c. The proposal will implement that simple method, providing standards compliance and simplifying the code. 4. The testing of subnet masks after receiving messages will be eliminated. a. This test accomplishes nothing. Reception of a packet by recvfrom is ensured by the network layer to include all and only messages to that port. b. This test consumes considerable resources, involving finding and using the subnet mask, and requires considerable code. c. In any case, there is no equivalent code for IPv6, so nothing equivalent will be provided. After these changes, the IP Adapter will be much smaller and easier to maintain. I will say a few words about why I am qualified to make such drastic changes. I have been programming sockets in both Linux and Windows since about 1990. I wrote a connectivity abstraction for a commercial product (PC-Xware) in the early 90s, and contributed to the first two WinSockathons at about that time. Since then I have used sockets for research projects at Intel. Please indicate your preference for the direction I should go on the IoTivity-Dev mailing list by Monday. I will push a patch for IPv6 next week. If the consensus is for my proposal, I will deliver a patch for it next week. If not, I will do the obvious patch to the current IP Adapter. If I don't make these changes as part of IPv6. I will submit the remainder of the changes in this proposal as a series of patches over the next few months. John Light Intel OTC OIC Development -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150618/7746c0f5/attachment.html>
