I've checked netmap support into the master branch of libpcap. The configure
script checks for netmap support and compiles pcap-netmap.c iff the header
files for netmap are present, as we do with other modules.
In order to allow capturing with Wireshark from the GUI (Wireshark *can* be
told to
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
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 l
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 wa
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
> s
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
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
On Sat, Feb 15, 2014 at 01:59:48PM -0800, Guy Harris wrote:
>
> On Feb 15, 2014, at 1:44 PM, Michael Richardson wrote:
>
> > where do those headers come from? Would it make sense to just include
> > those headers with libpcap? That way netmap would always be available.
>
> There's "netmap", w
On Sat, Feb 15, 2014 at 11:24:28PM +0100, Luigi Rizzo wrote:
...
> I think what Michael means is that if we include net/netmap.h and
> net/netmap_user.h in the libpcap distribution, we can have the support
> always compiled in and postpone the decision at compile time.
Luigi Rizzo wrote:
> Also, when a port is in netmap mode is temporarily disconnected from
> the host stack, so you want to be careful on where you use it.
> The monitoring folks (bro, suricata...) will probably love this
> feature but for others it might be more problematic.
yes,
On Sat, Feb 15, 2014 at 01:41:41PM -0800, Guy Harris wrote:
>
> On Feb 15, 2014, at 12:17 PM, Luigi Rizzo wrote:
>
> > + p->linktype = DLT_EN10MB;
>
> So this either
>
> 1) only works on Ethernet devices and devices that supply Ethernet
> headers
>
> or
>
> 2) generates Ethern
On Feb 15, 2014, at 1:44 PM, Michael Richardson wrote:
> where do those headers come from? Would it make sense to just include
> those headers with libpcap? That way netmap would always be available.
There's "netmap", which is available only if the kernel includes netmap
support; as long as
Luigi Rizzo wrote:
mcr> So, basically if we use a device name like "netmap:" or "vale",
mcr> then we would get support for it. Are there dependancies that would
mcr> piss off distros that we should worry about? You say that we need
mcr> netmap,
mcr> but I don't see where in
On Feb 15, 2014, at 12:17 PM, Luigi Rizzo wrote:
> + p->linktype = DLT_EN10MB;
So this either
1) only works on Ethernet devices and devices that supply Ethernet
headers
or
2) generates Ethernet headers that replace the native link-layer
headers for devices that don't su
On Sat, Feb 15, 2014 at 1:37 PM, Guy Harris wrote:
>
> On Feb 15, 2014, at 1:24 PM, Luigi Rizzo wrote:
>
> > At runtime, netmap only uses open(), ioctl(), mmap() and poll().
>
> ...and nm_dispatch(). Is that an inline function defined in the headers?
>
yes, same as nm_open() and a few others:
On Feb 15, 2014, at 1:24 PM, Luigi Rizzo wrote:
> At runtime, netmap only uses open(), ioctl(), mmap() and poll().
...and nm_dispatch(). Is that an inline function defined in the headers?
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdum
On Sat, Feb 15, 2014 at 1:15 PM, Michael Richardson wrote:
>
> So, basically if we use a device name like "netmap:" or "vale",
> then we would get support for it. Are there dependancies that would
> piss off distros that we should worry about? You say that we need netmap,
> but I don't see where
So, basically if we use a device name like "netmap:" or "vale",
then we would get support for it. Are there dependancies that would
piss off distros that we should worry about? You say that we need netmap,
but I don't see where in the build it references some new library.
Fork, and push your br
I have created a repo with a cloned copy of the pcap repository
with netmap support:
https://code.google.com/p/netmap-libpcap
With that, you can easily have tcpdump (and any libpcap application)
process 10-15Mpps with a single thread through NICs in netmap mode
(see http://info.iet.unipi
19 matches
Mail list logo
