st regards.
Jean-Louis
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Yes, this is certainly the best solution.
Thank you.
Jean-Louis
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
p() calls.
This was intentional to avoid squashing errbuf if for some reason bpf_odmcleanup
also fails.
I wrote it that way because to my point of vue, errbuf is supposed to be set to
the first encountered error not a potential error in some cleanup code.
Jean-Louis.
-
This is the tcpdump-worker
BTW, does someone know why the number of BPF devices is limited to 4 (at least
on AIX)? Is there a technical reason for this ?
I've tried to add one more bpf device (/dev/bpf4) on an AIX 5.1 box. The device
configuration seems ok (i.e. the sysconfig() calls are successfull). I can
launch up to 4
Hi,
In the following piece of AIX specific code from pcap-bpf.c that creates
and configures the /dev/bpf*; I think a call to bpf_odmcleanup is
required in the cases where either genmajor() or genminor() fail (see
"FIX HERE" below). Otherwise, the bpf_load() function returns without
unlocking the
Guy Harris alum.mit.edu> writes:
>
> So I don't know who actually *used* an 802.2 header without a SNAP
> header when sending IP datagrams.
>
I agree that IP + LLC without SNAP is probably very unusual.
Michael Richardson suggested me that the extra byte could be there to make the
IP datagra
Hi,
Maybe the following question is pretty obvious but since I'm not an
802.2/LLC expert, I can't find a response for it.
I was reading print_llc.c code and in llc_print() function, I found
something that I don't really understand.
At lines 247 to 251, one has :
if (ssap == LLCSAP_IP && dsa
Guy Harris ha scritto:
On Nov 24, 2008, at 1:27 PM, Tyson Key wrote:
Hi, any chance that a "usbany" (or similar) pseudo-device could be
added in a future version to capture on all USB buses, similar to
the standard "any" device for non-USB interfaces?
The "any" device works in Linux because
Guy Harris ha scritto:
On Oct 29, 2008, at 7:38 PM, Jean-Louis wrote:
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 data...
s
Guy Harris ha scritto:
On Oct 29, 2008, at 7:32 PM, Jean-Louis wrote:
in "text mode" ther'is direction check, I don't know how I can use
this "filter", but the check is broken
It can only be used by calling pcap_setdirection() in an application.
Ok
I don
Ken Bantoft ha scritto:
On 23-Nov-08, at 4:03 PM, Guy Harris wrote:
At some point we should put out libpcap 1.0.1/tcpdump 4.0.1 releases.
No problem there... right now, I'm tempted to cut them from CVS instead
of git, since I don't believe mcr has pulled in all the history into the
git rep
Ken Bantoft ha scritto:
On 23-Nov-08, at 4:03 PM, Guy Harris wrote:
At some point we should put out libpcap 1.0.1/tcpdump 4.0.1 releases.
No problem there... right now, I'm tempted to cut them from CVS instead
of git, since I don't believe mcr has pulled in all the history into the
git rep
Jean-Louis ha scritto:
Tyson Key ha scritto:
Hi Jean-Louis, just applied the patches and it compiles and installs
successfully.
Still looks like certain packets are being truncated (mostly
URB_ISOCHRONOUS
ones from what I can tell).
Thanks.
now also the mmap mode have snaplen limitation
Tyson Key ha scritto:
Hi Jean-Louis, just applied the patches and it compiles and installs
successfully.
Still looks like certain packets are being truncated (mostly URB_ISOCHRONOUS
ones from what I can tell).
Thanks.
now also the mmap mode have snaplen limitation...
try to capture traffic
Tyson Key ha scritto:
Hi Jean-Louis, does libpcap compile with the supplied patch for you?
It applied cleanly here, although I can't complete the ./configure phase
(the error produced is below):
./pcap-usb-linux.c: In function 'usb_read_linux_mmap':
./pcap-usb-linux.c:70
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 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 the
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 w
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: /hom
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&
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
0 s a3 00 0001 0004 4 <
d641c3a0 3906920199 C Ci:001:00 0 4 = 0103
[CUT]
"text mode" capture only 7 packets
the "d641c3a0 3906920187 S Co:001:00 s 23 01 0010 0001 0" stop
capture of traffic.
Index: pcap-usb-linux.c
==
ce.
Hi, sorry for my bad english :)
in "mmap mode" ther isn't capability to use snaplen...
today I have found some bug on pcap-usb-linux.c
now i can try to tell you which are
--
Roberto Mariani aka Jean-Louis
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
22 matches
Mail list logo
