On Feb 27, 2014, at 1:16 PM, Luigi Rizzo <ri...@iet.unipi.it> wrote:
> On Thu, Feb 27, 2014 at 1:05 PM, Guy Harris <g...@alum.mit.edu> wrote:
>
>> On Feb 27, 2014, at 12:57 PM, Luigi Rizzo <ri...@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
