[tcpdump-workers] Missing IPv6 ICMPv6 Neighbor Solicitation with promiscuous mode turned off
Hi there, With promiscuous mode turned off, libpcap successfully captures ARP requests (since they are sent to hw address ff:ff:ff:ff:ff:ff). However I would expect the same behavior with IPv6 ICMPv6 Neighbor Solicitation requests. These requests have the destination HW address of 33:33:xx:xx:xx:xx (a multicast address). I.e. I would not have thought that it be necessary to use promiscuous mode to see the Neighbor Solicitations. Note that we are using libpcap in a long-running application and would prefer not to use promiscuous mode. Is this a known problem? Does anyone know of a fix? I am using: tcpdump version 3.9.4 libpcap version 0.9.4 Linux 2.6.18 Kind regards -paul - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Missing IPv6 ICMPv6 Neighbor Solicitation with
There is a need. Actually I found the answer to this, as below. Would anyone consider adding this support to libpcap: i.e. a new member within pcap_opt ? Under Linux you have to explicitly enable support for "all multicast" packets. libpcap does not have an option for this, but it can be done as follows by using the ethernet file descriptor: older kernels: ... ifr.ifr_flags |= IFF_ALLMULTI; ioctl(handle->fd, SIOCSIFFLAGS, &ifr) ... new kernels mr.mr_type= PACKET_MR_ALLMULTI; setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP, &mr ... I assume the reason one has to do this is because multicast support happens within the driver (and IPv6's intention to make use of such existing hardware support for its neighbor disc). *shrug* -paul On Thu, Feb 23, 2012 at 12:32 PM, Aaron Turner wrote: > On Thu, Feb 23, 2012 at 10:20 AM, Paul Sheer wrote: >> Hi there, >> >> With promiscuous mode turned off, libpcap successfully captures >> ARP requests (since they are sent to hw address ff:ff:ff:ff:ff:ff). >> >> However I would expect the same behavior with IPv6 ICMPv6 >> Neighbor Solicitation requests. These requests have the >> destination HW address of 33:33:xx:xx:xx:xx (a multicast >> address). I.e. I would not have thought that it be necessary >> to use promiscuous mode to see the Neighbor Solicitations. > > Is an IPv6 address configured on that interface? If not, there > wouldn't be a need to listen to Neighbor Solicitations. > > -- > Aaron Turner > http://synfin.net/ Twitter: @synfinatic > http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & > Windows > Those who would give up essential Liberty, to purchase a little temporary > Safety, deserve neither Liberty nor Safety. > -- Benjamin Franklin > "carpe diem quam minimum credula postero" > - > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Missing IPv6 ICMPv6 Neighbor Solicitation with
>> >> Paul> Would anyone consider adding this support to libpcap: i.e. a >> Paul> new member within pcap_opt ? >> >> I think that it should probably just be on. >> Principal of least surprise. > > Here's why PACKET_MR_ALLMULTI is currently *not* turned on: > > > https://sourceforge.net/tracker/?func=detail&aid=599857&group_id=53067&atid=469577 > Well I personally would like it to be an extra option then. It is certainly an important and useful option for the following use case: libpcap/libdnet are used to implement a lot of special networking features not supported by the kernel. Now with the advent of IPv6, multicast is the default way of resolving addresses (i.e. solicitation). Anyone trying to implement something to do with IPv6 solicitation is going to get stuck unless they use promiscuous mode. On the other hand IPv4 address resolution does not require a promiscuous mode setting. I suspect there will "soon" be a lot more requests for this as people start to do the weird things with IPv6 that they are used to being able to do with IPv4. -paul - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Fwd: scan_sys_class_net bug in pcap-linux.c
forwarding to list -paul -- Forwarded message -- From: Paul Sheer Date: Tue, Oct 30, 2012 at 7:40 PM Subject: scan_sys_class_net bug in pcap-linux.c To: Bill Fenner , Fulvio Risso , Guy Harris , Hannes Gredler , Michael Richardson Hi there! I notice you guys have in scan_sys_class_net() - if (ent->d_type == DT_DIR) continue; I believe this should be - if (!strcmp(ent->d_name, ".") || !strcmp(ent->d_name, "..") || !strcmp(ent->d_name, "bonding_masters")) continue; Take for instance this system (all directories): [root@machine1 /tmp]# ls -la /sys/class/net total 0 drwxr-xr-x 6 root root 0 Oct 10 18:44 . drwxr-xr-x 31 root root 0 Oct 25 16:11 .. drwxr-xr-x 3 root root 0 Oct 10 18:44 eth0 drwxr-xr-x 3 root root 0 Oct 10 18:44 eth1 drwxr-xr-x 3 root root 0 Oct 10 18:44 lo drwxr-xr-x 3 root root 0 Oct 30 18:32 sit0 compared to another system (all links): [root@machine2 /tmp]# ls -la /sys/class/net total 0 drwxr-xr-x 2 root root 0 Oct 30 17:34 . drwxr-xr-x 42 root root 0 Oct 30 16:01 .. lrwxrwxrwx 1 root root 0 Oct 30 17:34 eth0 -> ../../devices/pci:00/:00:11.0/:02:01.0/net/eth0 lrwxrwxrwx 1 root root 0 Oct 30 17:34 lo -> ../../devices/virtual/net/lo BUT note also a third system: [root@machine3 /tmp]# ls -la /sys/class/net total 0 drwxr-xr-x 2 root root0 Oct 25 18:34 . drwxr-xr-x 43 root root0 Oct 25 18:35 .. lrwxrwxrwx 1 root root0 Oct 25 18:34 bond0 -> ../../devices/virtual/net/bond0 lrwxrwxrwx 1 root root0 Oct 25 18:34 bond0.3 -> ../../devices/virtual/net/bond0.3 lrwxrwxrwx 1 root root0 Oct 25 18:34 bond0.4 -> ../../devices/virtual/net/bond0.4 lrwxrwxrwx 1 root root0 Oct 25 18:34 bond1 -> ../../devices/virtual/net/bond1 lrwxrwxrwx 1 root root0 Oct 25 18:34 bond2 -> ../../devices/virtual/net/bond2 lrwxrwxrwx 1 root root0 Oct 25 18:34 bond3 -> ../../devices/virtual/net/bond3 -rw-r--r-- 1 root root 4096 Oct 25 19:32 *bonding_masters* lrwxrwxrwx 1 root root0 Oct 25 18:34 eth01 -> ../../devices/pci:00/:00:01.0/:02:00.0/net/eth01 lrwxrwxrwx 1 root root0 Oct 25 18:34 eth02 -> ../../devices/pci:00/:00:01.0/:02:00.1/net/eth02 lrwxrwxrwx 1 root root0 Oct 25 18:34 eth21 -> ../../devices/pci:00/:00:09.0/:09:00.0/net/eth21 lrwxrwxrwx 1 root root0 Oct 25 18:34 eth21.9 -> ../../devices/virtual/net/eth21.9 lrwxrwxrwx 1 root root0 Oct 25 18:34 eth22 -> ../../devices/pci:00/:00:09.0/:09:00.1/net/eth22 lrwxrwxrwx 1 root root0 Oct 25 18:34 lo -> ../../devices/virtual/net/lo See how you have to avoid "bonding_masters" in this list? Hope this helps. Best wishes. -paul ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] scan_sys_class_net bug in pcap-linux.c
> > !strcmp(ent->d_name, "bonding_masters")) continue; > > No. > > That wires in a particular name, and when the *next* weird file gets added > by some future kernel revision, we won't handle it, and would end up wiring > in another name, lather, rinse, repeat. > > Instead, it should ignore "." and "..", ignore all *plain files* (rather > than directories), and check whether there's a "subsystem" item underneath > the item (just in case there are directories, or symlinks that point to > directories, in there that *don't* correspond to devices, either now or in > the future). > > Hmmm i recall on some systems they are symlinks not directories what about if they don't contain "subsystem" in the future? or older kernel versions that don't contain "subsystem" (do they?) ? or future versions that add subsystem to bonding_masters? i agree with the impetus of what you are saying, I just don't know where one would draw the line as to what CAN change and what CANNOT change and your line seems just as arbitrary actually i've had these very similar arguments a few times before -- do you see a general principle? -paul ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] scan_sys_class_net bug in pcap-linux.c
works for me -paul On Mon, Dec 3, 2012 at 3:43 AM, Guy Harris wrote: > > [...] > > Well: > > [...] ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] scan_sys_class_net bug in pcap-linux.c
Thanks, There are two other problems I am having: Firstly, I would like to capture on all interfaces, but I would also like to know, with each packet, what interface it arrived on and left out of. This information is contained within the Linux kernel skbuff. But pcap does not see it. I also want to see both source and destination hardware addresses of the Ethernet packet (if it is Ethernet). I guess this feature requires kernel changes. The second problem is that tcpdump seems to have no way of listening on all interfaces. So if you are trying to track SCTP packets that use two separate interfaces, it seems you have to use wireshark instead. Best wishes. -paul On Wed, Dec 5, 2012 at 4:46 PM, Guy Harris wrote: > > On Dec 3, 2012, at 10:33 AM, Paul Sheer wrote: > > > works for me > > Ok, good. > > Thanks for noting the "subsystem in older kernels" issue - looking for > ifindex is a better idea; in addition to dating back to 2.6.0, it's also > more strongly associated with being a network interface. > > (What we really want is a way to ask for everything on which you can do > SIOCGIFINDEX and use the result of that ioctl in a bind() call on a > PF_PACKET socket, i.e. everything that you can capture on using a PF_PACKET > socket. I guess asking for everything under /sys/class/net that has an > ifindex property is one way of doing that; perhaps there's another way to > do that with netlink sockets.) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] scan_sys_class_net bug in pcap-linux.c
cool i would encourage tcpdump-workers to try to eventually support opening up multiple devices and listening on all of them for instance, the command, tcpdump -e -i any that would show output like: 11:42:25.170257 >eth100:24:bf:5b:d4:d6 > 00:0c:29:f7:7f:e9, ethertype IPv4 (0x0800), length 11:42:25.171312 00:22:54:7b:41:06, ethertype IPv4 (0x0800), length (where ">eth1" means "arrived at eth1", and " wrote: > > On Dec 5, 2012, at 2:56 PM, Paul Sheer wrote: > > > I would like to capture on all interfaces, but I would also like to > know, with each packet, what interface it arrived on and left out of. > > > > This information is contained within the Linux kernel skbuff. > > > > But pcap does not see it. > > What's really wanted there is a new API and pcap-ng support, so that the > interface ID and interface information can be present in the capture file. > You could capture with multiple pcap_t's, one for each interface, but not > with the "any" device, as that doesn't supply the interface index. > > > I also want to see both source and destination hardware addresses of the > Ethernet packet (if it is Ethernet). > > > > I guess this feature requires kernel changes. > > If the kernel allows an unbound PF_PACKET/SOCK_RAW socket, you could get > that, but filtering would be difficult unless all interfaces have the same > ARPHRD_ type - in-kernel filtering might apply to the socket, in which case > it might be difficult or impossible to do it (the BPF program would have to > determine the link-layer header type for the packet and jump to the > appropriate filtering code), and userland filtering might be tricky as well > (it would have to determine the link-layer header type for each interface > and apply the appropriate filter). > > If you do this by capturing on multiple pcap_t's, that's easier. > > > The second problem is that tcpdump seems to have no way of listening on > all interfaces. So if you are trying to track SCTP packets that use two > separate interfaces, it seems you have to use wireshark instead. > > The only way tcpdump currently supports for listening on all interfaces is > the "any" device. If it could write pcap-ng files, it could do the same > thing Wireshark does - open multiple pcap_t's and capture on all of them. > ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
