On Sun, Jan 06, 2008 at 04:27:34PM -0800, Guy Harris wrote:
> >-Multiple arguments are concatenated with spaces before being parsed.
> >+Multiple arguments are concatenated with spaces before being parsed,
> >+i.e. there is an implicit \fIand\fP between the arguments.
>
> I removed that, as it's n
Joerg Mayer wrote:
Hopefully I've managed to do that in the attached patch.
Checked in, although:
- Clarify the multiple arguments case.
...
-Multiple arguments are concatenated with spaces before being parsed.
+Multiple arguments are concatenated with spaces before being parsed,
On Sun, Jan 06, 2008 at 01:26:35PM -0800, Guy Harris wrote:
> Joerg Mayer wrote:
> >Sometimes I find patches that I was sure I had sent ages ago. This is
> >one of them - updated to current cvs.
> >
> >Move the pcap filter syntax into its own manpage.
>
> I've checked that into the main and 1.0 br
Fulko Hew wrote:
I'd still need a custom findalldevs() function that knew how to find
'local' devices as well as 'SITA remote' devices.
General support for remote capturing would need
1) a way to find hosts that support remote capturing (whether by
scanning the hosts file for SITA hosts, or
On Jan 6, 2008 4:46 PM, Guy Harris <[EMAIL PROTECTED]> wrote:
> Fulko Hew wrote:
>
> > On one hand, my version queries and interoperates with remote
> > devices to allow remote capture. What it does do (unfortunately
> > right now) is ignore any 'local' linux monitorable devices. It would
> > be
Max Laier wrote:
On Saturday 05 January 2008, lei wei wrote:
Max,
I don't quite understand "surrounding struct pflog_softc in #ifdef
_KERNEL.". Could you give me some more detailed instruction?
Thanks for the help.
See attached. Apply to either the installed version directly
(/usr/include/n
Fulko Hew wrote:
On one hand, my version queries and interoperates with remote
devices to allow remote capture. What it does do (unfortunately
right now) is ignore any 'local' linux monitorable devices. It would
be nice to be able to monitor/select either remote (SITA) or local
(Linux) devices
lei wei wrote:
When I was compiling libpcap0.9.8 with DAG-enabled, it gave me an error as
follows:
gcc -O2 -I. -I/usr/local/dag/include -DHAVE_CONFIG_H
-D_U_="__attribute__((unused))" -c ./pcap-dag.c
./pcap-dag.c: In function `dag_open_live':
./pcap-dag.c:721: error: `p' undeclared (first use
Joerg Mayer wrote:
Sometimes I find patches that I was sure I had sent ages ago. This is
one of them - updated to current cvs.
Move the pcap filter syntax into its own manpage.
I've checked that into the main and 1.0 branches, with some edits, along
with updates to:
FILES - list the
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
Luca Deri wrote:
your comments are very valuable: thanks. I have enclosed a new patch
that should address all of them.
It's still not a context or unified diff, and I've subsequently made
some changes to pcap-linux.c to move the SITA support code into
pcap-sita.c, so the patch didn't apply c
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 was compiled with SITA
support, very little of the regular Linux capture
Hello,
When I was compiling libpcap0.9.8 with DAG-enabled, it gave me an error as
follows:
gcc -O2 -I. -I/usr/local/dag/include -DHAVE_CONFIG_H
-D_U_="__attribute__((unused))" -c ./pcap-dag.c
./pcap-dag.c: In function `dag_open_live':
./pcap-dag.c:721: error: `p' undeclared (first use in this fu
On Fri, Dec 28, 2007 at 02:17:46AM +0100, Joerg Mayer wrote:
> Sometimes I find patches that I was sure I had sent ages ago. This is
> one of them - updated to current cvs.
>
> Move the pcap filter syntax into its own manpage. If that patch is
> acceptable, I'll send another patch that removes it
Guy
your comments are very valuable: thanks. I have enclosed a new patch
that should address all of them.
I have modified the configure so that the libpfring is included into
libpcap.a. This means that apps that will be linked against libpcap-
PF_RING won't also need to link against -lpfrin
Luca Deri wrote:
Yes it will work correctly as when the PF_RING socket is open, the call
will fail and the library will fall back to standard pcap.
...in which case it will
1) do getsockopt(handle->fd, 0, PACKET_STATISTICS, &kstats, &len) on
the PF_PACKET socket rather than doing getsockopt
On Jan 5, 2008, at 11:52 PM, Guy Harris wrote:
Luca Deri wrote:
On Dec 31, 2007, at 10:21 PM, Guy Harris wrote:
You might want to split the PF_RING support and the reentrancy
changes into two patches.
I have enclosed the patch for PF_RING.
I've checked in Paolo Abeni's patch for memory-m
17 matches
Mail list logo
