Jean-Louis ha scritto:
today I have found some bug on pcap-usb-linux.c
now i can try to tell you which are
in accordance with usbmon.txt in "mmap mode" the data is at
&mmap_area[vec[i]] + 64;
rather than
&mmap_area[vec[i]] + 48;
with mmap ther'is 16Byte filled with 0 first to the real dat
Jean-Louis ha scritto:
today I have found some bug on pcap-usb-linux.c
now i can try to tell you which are
Added possibility to set "snaplen" also in "mmap mode"
Index: pcap-usb-linux.c
===
RCS file: /home/jean-louis/cvsroot/libp
Jean-Louis ha scritto:
Jean-Louis ha scritto:
today I have found some bug on pcap-usb-linux.c
now i can try to tell you which are
in "text mode" ther'is direction check, I don't know how I can use this
"filter", but the check is broken
If this "filter" is usable, should be added similar c
Jean-Louis ha scritto:
today I have found some bug on pcap-usb-linux.c
now i can try to tell you which are
removed unneeded code
Index: pcap-usb-linux.c
===
RCS file: /home/jean-louis/cvsroot/libpcap/pcap-usb-linux.c,v
retrieving
today I have found some bug on pcap-usb-linux.c
now i can try to tell you which are
transfer direction in "text mode" is broken...
in accordance with usbmon.txt transfer direction is in endpoint_number
rather than transfer type
ther'is premature stop when capture traffic on linux with "text
Guy Harris ha scritto:
On Oct 29, 2008, at 1:16 PM, Tyson Key wrote:
Also, is it considered normal for Linux 2.6.25 and above (or libpcap,
although I'm not sure exactly what to blame) to truncate large numbers of
USB packets? (I assume this has been hashed to death on the list in the
past, tho
On Oct 29, 2008, at 1:16 PM, Tyson Key wrote:
Also, is it considered normal for Linux 2.6.25 and above (or libpcap,
although I'm not sure exactly what to blame) to truncate large
numbers of
USB packets? (I assume this has been hashed to death on the list in
the
past, though).
Paolo? Cou
Hi Guy. Yes, that (defaulting to the maximum allowed by the protocol/system)
was what I'm referring to.
Also, is it considered normal for Linux 2.6.25 and above (or libpcap,
although I'm not sure exactly what to blame) to truncate large numbers of
USB packets? (I assume this has been hashed to deat
On Oct 29, 2008, at 10:48 AM, Tyson Key wrote:
It seems to work fine now, although I could probably do with
automatically
setting the "snaplen" somehow.
I.e., defaulting to the maximum (65535) rather than the current
default of 64 (without IPv6) or 96 (with IPv6)?
At least one OS that d
Hi, thanks for the tip (it was probably an oversight on my part, since I
didn't know about that limitation).
It seems to work fine now, although I could probably do with automatically
setting the "snaplen" somehow.
Thanks.
On Tue, Oct 28, 2008 at 11:54 PM, Guy Harris <[EMAIL PROTECTED]> wrote:
>
On Oct 29, 2008, at 8:49 AM, [EMAIL PROTECTED] wrote:
Is there a pcap function that will allow me to view the ip addresses
(sending and receiving) of a packet
No. Libpcap doesn't interpret the packet contents; you will have to
do the same thing that tcpdump, Wireshark, Snort, etc. do, and
I'm working with some C code using pcap.h and I have an infinite loop running
pcap_dispatch. The packet handler function then takes the packet header it
received from pcap_dispatch and sends a message to a synthesizer currently
based on the packet length which is stored in the packet header it
12 matches
Mail list logo
