Hello,
I'm looking for benchmark information for NICs that work well for data
capture with libpcap. My primary focus is Linux / Solaris.
If such a list does not exist, I'd be happy to collate whatever
information available.
Regards,
Andy
-
This is the tcpdump-workers list.
Vis
Abeni Paolo wrote:
hello,
In the current cvs, at least the bpf, the win32 and the linux (memory
mapped) platforms use an internal buffer to perform the capture. The
buffer size is currently user-configurable only for the win32
platform, and it would be nice to be able to do the same also on
othe
On Jan 6, 2008 3:40 PM, Guy Harris <[EMAIL PROTECTED]> wrote:
> Fulko Hew wrote:
>
> > I think the code is better when its more
> > obvious, segregated and less intrusive.
>
> I've checked into the main and 1.0 branches changes to make it even more
> segregated and less intrusive. If pcap-linux.c
On Jan 6, 2008 3:40 PM, Guy Harris <[EMAIL PROTECTED]> wrote:
... snip ...
There are still some warnings:
>
> ./pcap-sita.c: In function 'acn_findalldevs':
> ./pcap-sita.c:415: warning: 'port' may be used uninitialized in this
> function
> ./pcap-sita.c :414: warning: 'proto' may be used uninitia
hello,
In the current cvs, at least the bpf, the win32 and the linux (memory mapped)
platforms use an internal buffer to perform the capture. The buffer size is
currently user-configurable only for the win32 platform, and it would be nice
to be able to do the same also on other platform, but th
On 7 Jan 2008, at 16:37, Joerg Mayer wrote:
On Mon, Jan 07, 2008 at 03:13:32PM +0100, Arien Vijn wrote:
Attached is a small patch which makes libpcap filter expressions a
bit
more tolerant towards ethernet (MAC) address notations.
Did you use invisible ink^H^H^Hpixels in the attached patch
Hi,
IMHO if reentrancy support is desired for libpcap, then it must be done
properly. For me this means, that:
* the semantics must be clarified. I.e., if two threads read from the
same handle, then which thread gets which packet? Currently the packets
are distributed over the threads randomly.
Luca Deri wrote:
> that basically return the time of the day either of the packet when
> captured, or when ioctl is called.
>
> As libpcap is not calling this ioctl immediately (e.g. it might be that
> the BPF filter is evaluated), I suppose that even if the ioctl call is
> not in sync (e.g. anot
On Mon, Jan 07, 2008 at 03:13:32PM +0100, Arien Vijn wrote:
> Attached is a small patch which makes libpcap filter expressions a bit
> more tolerant towards ethernet (MAC) address notations.
Did you use invisible ink^H^H^Hpixels in the attached patch?
> \3 seems preferred by the IEEE and in man
Greetings,
Attached is a small patch which makes libpcap filter expressions a bit
more tolerant towards ethernet (MAC) address notations.
When troubleshooting network problems, me and my colleagues often want
to cut-and-paste MAC addresses as displayed by network equipment.
However, moder
10 matches
Mail list logo
