However, my tests show that select()ing bpf fd does not lead to
trigger packets
available to bpf filter; the process hangs in select state while
parallel
tcpdump process shows packets desired *and* is in bpf state.
See PR kern/22063 "bpf when used with the select system call with
timeout doesn't
> > Is it possible to use libpcap with pthreads?
> > (I want to use just pcap_dispatch() function)
>
> I very much doubt so. It's not possible to use it in any kind of
> multithreaded applications, even with select() scenarios.
That's a BPF problem, not a libpcap problem; see PR kern/22063 "bpf
The same question was asked by Ralf Knapp <[EMAIL PROTECTED]> - in fact,
the text of the question appears to be identical to the text of your
question - who sent his question to [EMAIL PROTECTED] and
[EMAIL PROTECTED]
The answer to that question was:
Date: Thu, 28 Jun 2001 11:34:10 -0500
On Thu, Dec 07, 2000 at 09:51:42PM -0800, Alfred Perlstein wrote:
> I'm very curious how they managed to run "windump" on FreeBSD.
Presumably they're referring to tcpdump there, as per the first
paragraph in "2. Tests":
This Section aims at giving some indications about the
perf
On Thu, Dec 07, 2000 at 11:39:58PM -0800, Guy Harris wrote:
> Or, as per my other mail, perhaps using, on Windows, a version of the
> standard I/O library that does bigger writes, hence fewer system calls.
Nope. According to "strace for NT":
http://www.secu
On Thu, Dec 07, 2000 at 11:38:09PM -0800, Matt Dillon wrote:
> It amounts to the same thing, since -w does nothing more then an
> fopen(..."w"). You get a pidly 8K buffer out of that, and it isn't
> even double buffered.
>
> But I think the last poster had it right... if the bpf
On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote:
> Looking at the data I would guess that they
> are appending to a file using write()'s on a packet-by-packet basis
Or, as per my other mail, perhaps using, on Windows, a version of the
standard I/O library that does bigger writ
On Thu, Dec 07, 2000 at 09:06:04PM -0800, Dragos Ruiu wrote:
> (Hurm Wintendo outperforming unix???!?? Something's
> improper about this, and it ought to be fixed... :-)
> Comments? Other OS numbers: more recent
> FreeBSD versions? Solaris? Tru64? Optimization
> patches?
As an experi
On Thu, Dec 07, 2000 at 09:47:20PM -0800, Matt Dillon wrote:
> Looking at the data I would guess that they
> are appending to a file using write()'s on a packet-by-packet basis
Unlikely, given that they're using "tcpdump", which, with the "-w" flag,
writes using standard I/O, and doesn't
On Fri, Sep 29, 2000 at 10:47:24AM +0300, Danny Braniss wrote:
> basicaly, if i understand your explanation, i will always have problems
> with mknod and v2/v3.
Yes, mknod done with V3 will, unless your server treats special file
major/minor device numbers the way FreeBSD does, probably create a
> } 1) NFS V2 having, as I remember, insufficient bits in the
> }major/minor device value used when creating special files to
> }support more than 8 bits of major and 8 bits of minor device;
> if i remember correctly,i copied the / over to the NetAPP via nfsv3
> either tar or
> You want accessx for X-windows. Solaris, Compaq/Digital, and SGI
> provide it, but I didn't see anything at www.xfree86.org
> Searching around the web found a version for Linux
> http://slappy.cs.uiuc.edu/fall98/Linux/download.html
AccessX appears to have been developed, at least in part, by t
12 matches
Mail list logo
