On Feb 15, 2014, at 1:21 PM, Michael Richardson wrote:
> The ESP tests are failing because you haven't got libssl-dev.
Yes - some tests fail if the full set of support libraries weren't available
when tcpdump was built.
Perhaps we want to suppress some tests if we don't have the appropriate
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,
> From: Michael Richardson
> The ESP tests are failing because you haven't got libssl-dev
Right, thanks !
remain :
dccp_partial_csum_v4_simple : TEST FAILED
dccp_partial_csum_v4_longer : TEST FAILED
___
tcpdump-workers mailing list
tcpdump
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
The ESP tests are failing because you haven't got libssl-dev.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
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
> From: Michael Richardson
> so, you are saying we should install a qemu mips emulator inside travis to do
> the testing... wow.. fork the tree, enable travis, and try it out...
FYI, digging more, I used this link:
http://people.debian.org/~aurel32/qemu/powerpc/
with the file: debian_wheezy_powe
François-Xavier Le Bail wrote:
>> Do you?
> I did not test, but it seems promising :
> http://www.aurel32.net/info/debian_mips_qemu.php
so, you are saying we should install a qemu mips emulator inside travis to do
the testing... wow.. fork the tree, enable travis, and try it out...
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
15.02.2014, 18:44, "Daniel H. Bahr" :
> Hello everyone,
>
> I'm in need of accessing the tsval value of the options field in the
> tcp header... i've been checking the tcp.h and did not find anything
> that helped me.
>
> Does any body know how to do it?
Greetings.
TCP options are a particular ca
> From: Michael Richardson
> François-Xavier Le Bail wrote:
> > At present, the Travis test do a x86_64 build and a 'make
> check'.
>
> > So the checks are done on a little-endian system.
>
> > He could be useful to add a build and check on a big-endian system.
>
> > What do
François-Xavier Le Bail wrote:
> At present, the Travis test do a x86_64 build and a 'make check'.
> So the checks are done on a little-endian system.
> He could be useful to add a build and check on a big-endian system.
> What do you think about it?
I would love it.
As far as
Hello everyone,
I'm in need of accessing the tsval value of the options field in the
tcp header... i've been checking the tcp.h and did not find anything
that helped me.
Does any body know how to do it?
Best regards
___
tcpdump-workers mailing list
tcp
Hi,
At present, the Travis test do a x86_64 build and a 'make check'.
So the checks are done on a little-endian system.
He could be useful to add a build and check on a big-endian system.
What do you think about it?
Greetings,
Francois-Xavier
___
tc
22 matches
Mail list logo
