Re: code available: netmap support for libpcap

[Guy Harris <guy () alum mit edu>]

On Feb 27, 2014, at 1:16 PM, Luigi Rizzo <rizzo () iet unipi it> wrote:

> On Thu, Feb 27, 2014 at 1:05 PM, Guy Harris <guy () alum mit edu> wrote:
>
> > On Feb 27, 2014, at 12:57 PM, Luigi Rizzo <rizzo () iet unipi it> 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