Abishek, Thank you for checking that. I believe only RTMGRP_LINK is needed, and I think doing so will reduce the number of events. John
From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Abhishek Sharma Sent: Monday, June 22, 2015 8:10 AM To: Macieira, Thiago Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Proposal for IP Adapter and request for feedback I verified using AF_NETLINK sockets today, looks like we can use them for network monitoring on Linux. In my testing though they were generating lot of events (duplicates) even when idle. I was listening for "RTMGRP_LINK" and "RTMGRP_IPV4_IFADDR. ------- Original Message ------- Sender : Thiago Macieira<thiago.macieira at intel.com> Date : Jun 20, 2015 04:14 (GMT+05:30) Title : Re: [dev] Proposal for IP Adapter and request for feedback On Friday 19 June 2015 16:20:00 Abhishek Sharma wrote: > In both 2) and 3) approach however, membership request has to be repeated > when interface went down and came up again. So unless there is an > alternative way of achieving it, we are going to need network monitor so > that multicast group can be joined over newly available interfaces. Hello Abishek You're quite right. I've done some additional testing here. My machine has two network interfaces and I told it to join: ff02::1ff interface 2 ff02::1fe interface 13 ip maddr shows (trimmed): 2: wlp2s0 link 33:33:00:00:01:ff users 2 inet6 ff02::1ff 13: usb0 link 33:33:00:00:01:fe inet6 ff02::1fe As you can see, the problem is even lower than you hinted at: unless we tell the OS to join the multicast group in the exact interface we want to receive packets on, we won't receive anything at all. This is confirmed by having another machine on the same network as interface 13 (usb0) try to ping ff02::1ff or try to send a packet to the listening socket. In both cases, tcpdump shows that the packet is not received at all. So, conclusion: we need to find out if an interface was brought up so we can join the multicast group in it. Without that, we won't receive the discovery packets. However, John is quite right that the polling *needs* *to* *go.* It needs to be replaced by AF_NETLINK to save power and to avoid the 2-second delay. In fact, ALL polling needs to go away. Any and all sleep/msleep/usleep/nanosleep calls on Linux MUST BE REMOVED. I'm using capitals to show how important this is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center [cid:image001.gif at 01D0ACC8.03F0BE10] [Image removed by sender.] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150622/a8bc10ad/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: ~WRD000.jpg Type: image/jpeg Size: 823 bytes Desc: ~WRD000.jpg URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150622/a8bc10ad/attachment.jpg> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13168 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150622/a8bc10ad/attachment.gif>
