From: Mario Rugiero
> Sent: 07 October 2019 19:07
...
> > If we were to drop TPACKET_V1 and TPACKET_V2 support, that'd mean we'd be
> > dropping 2.x kernels and older 3.x kernels as
> > targets, and would require that the headers with which libpcap is being
> > built be new enough to support TPAC
From: Guy Harris
> On Jan 9, 2015, at 8:30 AM, Michael Richardson wrote:
>
> > Guy Harris wrote:
> >> The longer timeout can reduce capturing overhead, and if you're
> >> capturing a high volume of traffic to a file, it's probably the right
> >> timeout to have.
If you are capturing a high volu
From: Rick Jones
> On 01/28/2015 06:57 AM, Giray Simsek wrote:
> > Hi,
> > We are currently working on testing Linux network performance. We
> > have two Linux machines in our test setup. Machine1 is the attacker
> > machine from which we are sending SYN packets to Machine2 at a rate
> > of 3millio
From: Denis Ovsienko
> >Eventually, we'll be using this format to debug multi-path TCP, in which case
> >the IP addresses (and maybe even the IP4/IP6-ness of it) might change.
>
> Also there exists SCTP, which implements the concept of variable (0..65535)
> number of "streams" for each direction o
> I'd prefer to also have a flag to say if this segment was received or
> transmitted - I've never liked inferring that information from the
> identity of the source/dest. addresses. It then makes it impossible to
> sensibly analyse the file if you don't know the underlying networking
> configurati
From: Guy Harris
> On Jan 9, 2015, at 2:09 AM, Michal Sekletar wrote:
>
> > Can't we use new default timeout value (lower) if we detect TPACKET_V3,
>
> The first sentence of my original mail was "With TPACKET_V3 support, Linux
> users are discovering what
> those of us using BSD-flavored OSes h
> from
> https://github.com/the-tcpdump-group/tcpdump/issues/333
>
> details an issue where differences in arch and compiler result in different
> extractions of floating point objects in LMP packets. Guy discovers it has
> something to do with assumptions about x86 SSE.
>
> and I think we might
> currently we are expierencing bad network performance. And in the log of a
> linux-server i have a lot
> of these messages:
>
> Sep 2 10:16:08 pc60181 kernel: [4286760.823563] br0: received packet on eth0
> with own address as
> source address
Since you know your own MAC address, you can jus
> > "Gisle" == Gisle Vanem writes:
> Gisle> I compile using MingW (gcc 4.7.2) and normally I use
> Gisle> -Wall -W.
>
> sure, I'd like to get to -Wall -Werror at some point, but for the
> moment, I want to know how to include -Wgcc-things when we are using
> gcc, and omit when we aren
> I agree. Honestly I think a perfectly reasonable stance to take is
> requesting that the filters get packets *as seen on the wire/nic*. I
> think that's the mental model everyone uses, and any deviation from
> that model is prone to bugs in the kernel, libpcap, and for the enduser.
TX and RX seg
> > I do agree that instead of a /proc entry, we should check for a kenrel
> > version >= X where X is the upstream version that first started
> > supporting all the features needed by libpcap for vlan filtering. This
> > is not a compile time check but a run time one. Does anyone see any
> > issue
> hi,
> I just checked the two mechanism :
> (1) Using mmap to fetch packets from kernel to userspace
> (2) Using recvfrom() call to fetch packets
>
> I see top reports
> (1) 34% memory 20% cpu usage
> (2) 21% memory 7% cpu usage !
It is worth remembering that the cpu usage reported by top isn'
> > What about the other OS - eg all the BSDs?
> > I had a vague idea that BPF was supposed to be reasonable portable.
>
> Yes, does it mean BPF is frozen ?
>
> Or is BSD so hard to update these days ?
Not really - but it some other places that need updating in order
to make this useful for cros
> On Fri, Sep 07, 2012 at 07:49:10AM +, George Bakos wrote:
> > Gents,
> > Any fundamental reason why the following (, etc.) shouldn't be
> > included in net/core/filter.c?
> >
> > case BPF_S_ALU_MOD_X:
> > if (X == 0)
> >
> > On windows you can't pass 'FILE *' into shared libraries,
> > they are likely to have their own copies of the stdio
> > libraries - with different FILE structures.
> > (eg if one part is compiled with debug enabled).
>
> In this patch, the library into which VFile is being passed is called
> "
> On Sep 3, 2012, at 7:13 PM, Michael Richardson wrote:
>
> > Wesley, is fopen("/dev/stdin") really the most portal
>
> (Presumably "portable".)
>
> > way to get a reference to stein?
>
> Definitely not - it will probably work on most modern UN*Xes (Linux,
> *BSD/OS X, and Solaris; I don't know
> Can I know how to build tcpdump with static libraries rather than with
> shared libraries ?
Why are you trying to do this.
As Guy says in his recent posts you can't (and shouldn't) try to link
statically to all the system libraries.
If you are trying to link with a specific version of libpcap
> As I have to deal with asymm. paths and perform flow analysis, I must
> ensure that the packets of a flow are analyzed in temporal order, no
> matter from which interface they came through.
You'll probably only manage that if the underlying low level
device driver (or preferably the hardware
There is a report on one of the netbsd lists (might have
been a developer-only list) that tcpdump (etc) aren't
working on 64bit netbsd platforms.
IIRC it had something to do with 'struct timeval' and friends.
I'm not sure of the full details but it might be related to:
1) NetBSD recently changing
> Do you have any references for this, so I can see exactly
> what it means?
>
> If it just means that if you build an executable image (or
> shared library), linking it with library A, and library A is
> a shared that is linked with library B, and if the executable
> image is *not* linked w
> On all modern UN*Xes, as far as I know, a dynamic library can
> be linked with another dynamic library, and if a program is
> explicitly linked with the first of those libraries, but
> *not* explicitly linked with the second of those libraries,
> the program will still work - the run-time l
Chris Maynard wrote:
> Tyson Key gmail.com> writes:
>
> > As far as I'm aware, TCPDump is released under the terms of the BSD
Licence
> > - meaning that Nokia haven't got any obligations regarding releasing
their
> > modifications; and whilst it's not the most reliable information
source on
> >
> > That poll() is unnecessary in non-blocking mode only if the
> > application isn't expecting libpcap to return errors, and is
> > itself checking for those errors after the poll() call. That
> > would be the case only if the application knew it had to do
> > that special Linux-specific st
> On Dec 12, 2011, at 1:41 PM, Guy Harris wrote:
>
> > On Dec 12, 2011, at 3:59 AM, David Laight wrote:
> >
> >> I also think that interface could defer freeing the last
> >> rx buffer until the request to read another packet.
> >> That would
>
> On Dec 12, 2011, at 3:59 AM, David Laight wrote:
>
> > The linux libpcap has a poll() in the 'memory mapped'
> > kernel interface (in order to check for errors).
> > If the application is using poll() this is an unnecessary
> > system call.
&
> Is poll() better than select ?
poll() and select() use the same basic kernel code.
poll() is generally better since it doesn't have problems
with high numbered fds, and doesn't require a sparse
fd map to be scanned.
The linux libpcap has a poll() in the 'memory mapped'
kernel interface (in or
> On Nov 30, 2011, at 9:55 AM, David Laight wrote:
>
> > That doesn't preclude the use of variable sized buffers.
> > There are several schemes that could have been used that
> > have much the same logic, but allow variable sized buffers.
>
> At least wit
> I didn't see any of the discussions about it, but my guess is
> that the intent was to have a fixed set of slots in the
> buffer, each one associated with a fixed header, so that most
> of the packet-receive loop can just look at the headers and
> process all "owned by userland" headers and
28 matches
Mail list logo
