Hi,
just wanted to send a ping for this issue here. Any thoughts? Should I
use the sourceforge bug-tracker to submit it?
BTW, sourceforge: I just noticed that the most current libpcap version
of SF is 0.8.1 (and tcpdump is 3.8.1)
cu
gregor
Hi,
there seems to be
Hi,
there seems to be a bug when using the "ip6 protochain" filter on 64 bit
machines. When "ip6 protochain" is used on a 64 bit machine and a packet is
received that actually has a chain of headers, then libpcap crashes with a
SEGFAULT.
Protochain needs a loop (backwards jump) which is impl
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
Hi Luca,
Hi all,
I'm afraid, but I think your patch has a race condition under (at least
under Linux). In Linux two syscalls are required to read a packet. First
you read the packet, that you read the timestamp value with an ioctl. If
one thread gets scheduled just after the packet data is read, t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>
> The idea behind the snaplen [miss-]use is to permit legacy application
> to take advantage of the memory mapped access and permit new ones to
> control the ring behaviur. Such goal could be obtained even with other
> solution, but I was a bit 'sc
Hi,
the attached patch fixes a small inconsistency in pcap.3: The original
manpages reads: "NOTE: errbuf in ...".
pcap_open_dead() is listed in the 'list of cunction', however,
pcap_open_dead() doesn't take an errbuf argument.
cu
Gregor
diff -Naur libpcap-0.9.8.orig/pcap.3 libpcap-0.9.8/pcap.3
Guy Harris wrote:
> On May 18, 2007, at 7:09 AM, Alexandros Karypidis wrote:
>
>> [TCP Reassembly w/ TCP ACK/SEQ numbers]
>
> Perhaps I'm missing something, but I can't think of a better approach,
> other than "use a library that does that work for you, if it exists" (or
> steal code from an appl
> If you're willing to dive below the libpcap interface and generate a custom
> BPF program, you may be able to distinguish subrules, since the final result
> is actually not just "matches" or "doesn't match" but rather how many bytes
> to capture, from 0 to 64K.
bpf_filter() in userspace migh
>> And where can i get these instructions and their corresponding
>> opcodes.
>
>
> on BSD systems the header is in /usr/include/net/bpf.h
>
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/bpf.h
and for a general introduction to the bpf machine, have a look at the
original paper:
McC
Guy Harris wrote:
>
> On Feb 2, 2005, at 6:01 PM, Gregor Maier wrote:
>
>> We'd like to get two DLTs, namely DLT_ERF_ETH and DLT_ERF_POS. The DAG
>> range of network monitoring cards prepend an additional ERF header (see
>> http://www.endace.com/support/En
s for correct filtercode generation and for printing in tcpdump.
Thanks in advance
Gregor
--
Gregor Maier
[EMAIL PROTECTED]
Endace Technology Ltd., 12 Knox Street, Hamilton, New Zealand
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
uot;packet data" that uses a manifold instruction mix.
Regards,
Gregor
--
Gregor Maier
[EMAIL PROTECTED]
Endace Technology Ltd., 12 Knox Street, Hamilton, New Zealand
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
13 matches
Mail list logo
