Re: [tcpdump-workers] code available: netmap support for libpcap
On Feb 15, 2014, at 2:10 PM, Luigi Rizzo wrote: > Netmap works at least on any interface visible to the OS > (in native or emulated mode, the latter with some limitations > e.g not when the interface is bound to a switch), So if I want to capture on eth0 in netmap mode, what interface name do I use? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] code available: netmap support for libpcap
On Thu, Feb 27, 2014 at 11:24 AM, Guy Harris wrote: > > On Feb 15, 2014, at 2:10 PM, Luigi Rizzo wrote: > > > Netmap works at least on any interface visible to the OS > > (in native or emulated mode, the latter with some limitations > > e.g not when the interface is bound to a switch), > > So if I want to capture on eth0 in netmap mode, what interface name do I > use? > netmap:eth0 -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] code available: netmap support for libpcap
On Feb 15, 2014, at 2:10 PM, Luigi Rizzo wrote: > Netmap works at least on any interface visible to the OS > (in native or emulated mode, the latter with some limitations > e.g not when the interface is bound to a switch), > but ports of VALE switches and netmap pipes are dynamically created > so any name that starts with netmap: and vale results in a > valid netmap port. Is there any reason why dynamically creating a VALE switch or netmap port *as a result of opening a device in libpcap* would be useful? libpcap is generally used to capture and inject network traffic on already-existing interfaces; if you create a VALE switch or netmap port by opening netmap:helloworld in libpcap, what traffic will you see, and where will injected traffic go? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] code available: netmap support for libpcap
On Feb 27, 2014, at 12:57 PM, Luigi Rizzo wrote: > this can be used to plumb things together. If you want to plumb things together, do you need libpcap? > Say you want to interconnect two VMs, Why would I use libpcap for that? > or a traffic generator and a firewall/ids/monitor > that you want to test for performance, etc. But wouldn't I create a netmap pipe using something other than libpcap, and only use libpcap if I want to watch the traffic on that pipe? I.e., what would be lost if, for example, libpcap only supported capturing on existing netmap devices, and didn't support creating new ones on the fly? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] code available: netmap support for libpcap
On Thu, Feb 27, 2014 at 1:05 PM, Guy Harris wrote: > > On Feb 27, 2014, at 12:57 PM, Luigi Rizzo wrote: > > > this can be used to plumb things together. > > If you want to plumb things together, do you need libpcap? > the plumbing is done by netmap/vale/netmap pipes. libpcap is "only" a shim layer that can be used by tools that only speak libpcap so you do not need to recompile them. But it is a crucially important shim layer that gives you a lot of flexibility. > > Say you want to interconnect two VMs, > > Why would I use libpcap for that? > > > or a traffic generator and a firewall/ids/monitor > > that you want to test for performance, etc. > > But wouldn't I create a netmap pipe using something other than libpcap, > and only use libpcap if I want to watch the traffic on that pipe? > > I.e., what would be lost if, for example, libpcap only supported capturing > on existing netmap devices, and didn't support creating new ones on the fly? > Well you would lose the ability to connect to a VALE switch or a pipe (which only support dynamically created endpoints). Most importantly, you would need additional code to disable the functionality, because if you look at the pcap-netmap.c everything is handled in the nm_open() call. cheers luigi -- -+--- Prof. Luigi RIZZO, ri...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/. Universita` di Pisa TEL +39-050-2211611 . via Diotisalvi 2 Mobile +39-338-6809875 . 56122 PISA (Italy) -+--- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] code available: netmap support for libpcap
On Feb 27, 2014, at 1:16 PM, Luigi Rizzo wrote: > On Thu, Feb 27, 2014 at 1:05 PM, Guy Harris wrote: > >> On Feb 27, 2014, at 12:57 PM, Luigi Rizzo wrote: >> >>> this can be used to plumb things together. >> >> If you want to plumb things together, do you need libpcap? > > the plumbing is done by netmap/vale/netmap pipes. "By", or "with"? I.e., are there other APIs that would do the plumbing, and possibly tools that use those APIs? > libpcap is "only" a shim layer that can be used by > tools that only speak libpcap so you do not need > to recompile them. > > But it is a crucially important shim layer that > gives you a lot of flexibility. What flexibility do you have by having to go through libpcap that you don't have by going directly to a lower-level API? I'd expect code to be able to do *more* by bypassing libpcap than by using libpcap. >> I.e., what would be lost if, for example, libpcap only supported capturing >> on existing netmap devices, and didn't support creating new ones on the fly? > > Well you would lose the ability to connect to a > VALE switch or a pipe (which only support dynamically > created endpoints). "Connect to a VALE switch or a pipe" sounds as if it means "connect to a VALE switch or a pipe that already exists". If that's the case, I don't see why there's anything to dynamically create - the switch or pipe *already exists* and, if it has a name, you just use that name as the device name in the libpcap call, and it attaches to that already existing switch or pipe. If that's *not* the case, if you create the switch or pipe at the time you open it with libpcap, what traffic will there be on the switch or pipe to capture, and where will packets injected into the switch or pipe go? If there's no traffic to capture, and the injected packets don't go anywhere, unless further plumbing of some sort needs to be done, what's the point in creating the switch or pipe using tcpdump or Wireshark or snort or... rather than creating it, doing the other plumbing, and then starting a capture on the now-existing device? > Most importantly, you would need additional code to > disable the functionality, because if you look > at the pcap-netmap.c everything is handled in the > nm_open() call. OK, then, if it's possible to: 1) determine which regular network interfaces can be captured on using netmap and 2) get a list of names of existing VALE switches and netmap pipes add code to either the create or activate routine that checks against those names and rejects other names, so that, for example, if somebody's fingers slip and they try to capture on "eht0" rather than "eth0", they get an error rather than a capture on a newly-created device that might not be used by anything other than the capturing program and thus might not actually get any traffic. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
