Hello Stephen,
I am not sure to understand your comments. What is worth with this patch ?
Is it to use the network datalink as a linktype and an extension ?
Or is it to indicate the presence of FCS on 1 bit in the extension ?
I did choose to indicate the presence of the FCS on 1 bit, beca
Jon Steel wrote:
I did some more digging and I think Ive narrowed the problem down a bit
more. It does appear to be a kernel issue. pcaps off the hook for today.
For those interested, the problem occurs for the following reasons: When
you call open() on OpenBSD it does not lock the file unless y
I did some more digging and I think Ive narrowed the problem down a bit
more. It does appear to be a kernel issue. pcaps off the hook for today.
For those interested, the problem occurs for the following reasons: When
you call open() on OpenBSD it does not lock the file unless you tell it
to. This
It seems that if it is worth making the change, it is also worth using a
couple of bits to indicate whether a 16 or 32-bit CRC/FCS is present as
Guy suggested. This could then be used on linktypes such as PPP_SERIAL
which can have either length.
Stephen.
On Mon, 2007-02-19 at 19:59 +0100, [EMAIL
Adelmo Silva wrote:
But, if I wrote:
strcat(string1, &ips1[i]);
Another error happen:
teste1.c:294: error: incompatible types in assignment
So, on line 294 of testel.c, did you write
strcat(string1, &ips1[i]);
or did you write
string1 = strcat(string1, &ips1[i]);
I suspect
Guy Harris wrote:
I can't reproduce this on OS X 10.4 - I get
$ sudo ./bpfMaker.pl en1
BPF's at startup:0
BPF's upon ending:0
...with a version of bpftest.c fixed so that, if pcap_open_live() fails,
it returns before calling pcap_loop() (otherwise, it dumps core,
Jon Steel wrote:
I have found a potential bug in libpcap on OpenBSD and likely FreeBSD as
well. If you simultaneously open several programs that open pcap
connections, you can cause the system to lose track of some of its
BPF's. When you close all the pcap connections some of the BPF's may
repor
