Re: [tcpdump-workers] [Patch/Workaround?] pcap-usb-linux.c
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 ther'is 16Byte filled with 0 first to the real data...
so if i.e. I have caplen = 18Byte, in file.pcap I have 16Byte with
garbage (0x00) and only 2Byte with real data other 16Byte of real data
is lost.
the mmap mode is *default* with kernel = 2.6.25-rc8-mm1
I'm newbie with libpcap and I don't know how I can fix that without
degrading performance
I have patched this bug, but seems to be workaround-ish
so now pcap file is ok
Index: pcap-usb-linux.c
===
RCS file: /home/jean-louis/cvsroot/libpcap/pcap-usb-linux.c,v
retrieving revision 1.5
retrieving revision 1.6
diff -c -r1.5 -r1.6
*** pcap-usb-linux.c 29 Oct 2008 19:54:46 - 1.5
--- pcap-usb-linux.c 30 Oct 2008 11:35:54 - 1.6
***
*** 173,180
if (len 0)
return 0;
! handle-buffer = mmap(0, len, PROT_READ, MAP_SHARED, handle-fd, 0);
! return handle-buffer != MAP_FAILED;
}
pcap_t *
--- 173,180
if (len 0)
return 0;
! handle-bp = mmap(0, len, PROT_READ, MAP_SHARED, handle-fd, 0);
! return handle-bp != MAP_FAILED;
}
pcap_t *
***
*** 231,248
handle-stats_op = usb_stats_linux_bin;
handle-read_op = usb_read_linux_mmap;
handle-cleanup_op = usb_cleanup_linux_mmap;
-
- /*
- * handle-fd is a real file, so select() and
- * poll() work on it.
- */
- handle-selectable_fd = handle-fd;
- return 0;
}
!
! /* can't mmap, use plain binary interface access */
! handle-stats_op = usb_stats_linux_bin;
! handle-read_op = usb_read_linux_bin;
}
else {
/*Binary interface not available, try open text interface */
--- 231,242
handle-stats_op = usb_stats_linux_bin;
handle-read_op = usb_read_linux_mmap;
handle-cleanup_op = usb_cleanup_linux_mmap;
}
! else {
! /* can't mmap, use plain binary interface access */
! handle-stats_op = usb_stats_linux_bin;
! handle-read_op = usb_read_linux_bin;
! }
}
else {
/*Binary interface not available, try open text interface */
***
*** 267,278
--- 261,275
/* for plain binary access and text access we need to allocate the read
* buffer */
+ /* for mmap binary access we need to allocate the storing buffer for remove unneeded
+ * byte filled with 0 (workaround-ish)*/
handle-buffer = malloc(handle-bufsize);
if (!handle-buffer) {
snprintf(handle-errbuf, PCAP_ERRBUF_SIZE,
malloc: %s, pcap_strerror(errno));
return PCAP_ERROR;
}
+
return 0;
}
***
*** 679,685
nflush = fetch.nfetch;
for (i=0; ifetch.nfetch; ++i) {
/* discard filler */
! hdr = (pcap_usb_header*) handle-buffer[vec[i]];
if (hdr-event_type == '@')
continue;
--- 676,682
nflush = fetch.nfetch;
for (i=0; ifetch.nfetch; ++i) {
/* discard filler */
! hdr = (pcap_usb_header*) handle-bp[vec[i]];
if (hdr-event_type == '@')
continue;
***
*** 695,702
pkth.ts.tv_sec = hdr-ts_sec;
pkth.ts.tv_usec = hdr-ts_usec;
handle-md.packets_read++;
! callback(user, pkth, (u_char*) hdr);
packets++;
}
--- 692,704
pkth.ts.tv_sec = hdr-ts_sec;
pkth.ts.tv_usec = hdr-ts_usec;
+ /* copy header and data in buffer
+ * for remove byte filled with 0 (workaroud-ish) */
+ memcpy(handle-buffer, handle-bp[vec[i]], 48);
+ memcpy(handle-buffer + 48, handle-bp[vec[i]] + 64, clen);
+
handle-md.packets_read++;
! callback(user, pkth, (u_char*) handle-buffer);
packets++;
}
***
*** 713,720
static void
usb_cleanup_linux_mmap(pcap_t* handle)
{
! /* buffer must not be freed because it's memory mapped */
/* XXX - does it need to be unmapped? */
! handle-buffer = NULL;
pcap_cleanup_live_common(handle);
}
--- 715,726
static void
usb_cleanup_linux_mmap(pcap_t* handle)
{
! /* bp must not be freed because it's memory mapped */
/* XXX - does it need to be unmapped? */
! handle-bp = NULL;
pcap_cleanup_live_common(handle);
+
+ /* buffer must be freed, we have allocated this for store header and data
+ * without byte filled with 0 (workaround-ish) */
+ free(handle-buffer);
}
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump 4.0.0 + libpcap 1.0.0 Released
Bad form to reply to my own mail, I know, although the output of tcpdump -V is as follows if it helps: tcpdump version 3.9-PRE-CVS_2008_10_27 libpcap version 0.9-PRE-CVS Thanks. On Thu, Oct 30, 2008 at 12:33 PM, Tyson Key [EMAIL PROTECTED] wrote: Hi again, Guy. I've just been doing some strace-ing, and it appears to doing a open(/dev/usbmon2, O_RDONLY|O_LARGEFILE) = 3. Not sure if the script log will be of use to you, although I'll attach it anyway. Going to try the printf() kludge soon. Tyson. On Thu, Oct 30, 2008 at 12:27 AM, Guy Harris [EMAIL PROTECTED] wrote: 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? Could it be using the text interface rather than the binary interface? I think I remember you indicating that the text interface doesn't supply the full packet. Tyson, you said you were using the CVS version of libpcap (presumably meaning top-of-tree CVS, the pcap-usb-linux.c of which is identical to 1.0's pcap-usb-linux.c), so presumably you built it from source. You might want to stick some debugging printfs into usb_activate() to see whether it uses mmap access to the binary interface, non-mmap access to the binary interface, or the text interface. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. -- Fight Internet Censorship! http://www.eff.org ~ Open-Source Community, and Technology Testbed: http://www.house404.co.uk/ -- Fight Internet Censorship! http://www.eff.org ~ Open-Source Community, and Technology Testbed: http://www.house404.co.uk/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Patch/Workaround?] pcap-usb-linux.c
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:708: error: 'clen' undeclared (first use in this function) ./pcap-usb-linux.c:708: error: (Each undeclared identifier is reported only once ./pcap-usb-linux.c:708: error: for each function it appears in.) make: *** [pcap-usb-linux.o] Error 1 Thanks. On Thu, Oct 30, 2008 at 11:48 AM, Jean-Louis [EMAIL PROTECTED] wrote: 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 ther'is 16Byte filled with 0 first to the real data... so if i.e. I have caplen = 18Byte, in file.pcap I have 16Byte with garbage (0x00) and only 2Byte with real data other 16Byte of real data is lost. the mmap mode is *default* with kernel = 2.6.25-rc8-mm1 I'm newbie with libpcap and I don't know how I can fix that without degrading performance I have patched this bug, but seems to be workaround-ish so now pcap file is ok - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. -- Fight Internet Censorship! http://www.eff.org ~ Open-Source Community, and Technology Testbed: http://www.house404.co.uk/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Patch/Workaround?] pcap-usb-linux.c
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:708: error: 'clen' undeclared (first use in this function) ./pcap-usb-linux.c:708: error: (Each undeclared identifier is reported only once ./pcap-usb-linux.c:708: error: for each function it appears in.) make: *** [pcap-usb-linux.o] Error 1 Thanks. Hi Tyson, the clen definition is in patch 4_4 applied the patch in order: 1_4, 2_4, 3_4, 4_4, 1_1 - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump 4.0.0 + libpcap 1.0.0 Released
Hi again, Guy. I've just been doing some strace-ing, and it appears to doing a open(/dev/usbmon2, O_RDONLY|O_LARGEFILE) = 3. Not sure if the script log will be of use to you, although I'll attach it anyway. Going to try the printf() kludge soon. Tyson. On Thu, Oct 30, 2008 at 12:27 AM, Guy Harris [EMAIL PROTECTED] wrote: 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? Could it be using the text interface rather than the binary interface? I think I remember you indicating that the text interface doesn't supply the full packet. Tyson, you said you were using the CVS version of libpcap (presumably meaning top-of-tree CVS, the pcap-usb-linux.c of which is identical to 1.0's pcap-usb-linux.c), so presumably you built it from source. You might want to stick some debugging printfs into usb_activate() to see whether it uses mmap access to the binary interface, non-mmap access to the binary interface, or the text interface. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. -- Fight Internet Censorship! http://www.eff.org ~ Open-Source Community, and Technology Testbed: http://www.house404.co.uk/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Patch/Workaround?] pcap-usb-linux.c
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. On Thu, Oct 30, 2008 at 4:33 PM, Jean-Louis [EMAIL PROTECTED] wrote: 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:708: error: 'clen' undeclared (first use in this function) ./pcap-usb-linux.c:708: error: (Each undeclared identifier is reported only once ./pcap-usb-linux.c:708: error: for each function it appears in.) make: *** [pcap-usb-linux.o] Error 1 Thanks. Hi Tyson, the clen definition is in patch 4_4 applied the patch in order: 1_4, 2_4, 3_4, 4_4, 1_1 - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. -- Fight Internet Censorship! http://www.eff.org ~ Open-Source Community, and Technology Testbed: http://www.house404.co.uk/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Patch/Workaround?] pcap-usb-linux.c
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 with -s 0 tcpdump option. i.e. tcpdump -i2 -w file.pcap -s 0 if you would make default maximum, look #DEFINE of DEFAULT_SNAPLEN in tcpdump/interface.h and tcpdump/netdissect.h I have found this with find -name *.[ch] | xargs grep DEFAULT_SNAPLEN - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Patch/Workaround?] pcap-usb-linux.c
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... try to capture traffic with -s 0 tcpdump option. i.e. tcpdump -i2 -w file.pcap -s 0 if you would make default maximum, look #DEFINE of DEFAULT_SNAPLEN in tcpdump/interface.h and tcpdump/netdissect.h I have found this with find -name *.[ch] | xargs grep DEFAULT_SNAPLEN only one question: what you are using for dissect packets? If response is whireshark, in the dissector for usb raw traffic ther'is some workaround and misunderstood of usb specification... I don't know if truncate packet say in whireshark is attendible. If I have free time, this week, I would try to fix this dissector. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [Patch/Workaround?] pcap-usb-linux.c
Hi Jean-Louis, I'm currently using the patched version of tcpdump/libpcap to capture traffic, and Wireshark to dissect/view it. I do intend to do capturing with Wireshark though, when I've got round to recompiling it against the new libpcap. Thanks. On Thu, Oct 30, 2008 at 6:18 PM, Jean-Louis [EMAIL PROTECTED] wrote: 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... try to capture traffic with -s 0 tcpdump option. i.e. tcpdump -i2 -w file.pcap -s 0 if you would make default maximum, look #DEFINE of DEFAULT_SNAPLEN in tcpdump/interface.h and tcpdump/netdissect.h I have found this with find -name *.[ch] | xargs grep DEFAULT_SNAPLEN only one question: what you are using for dissect packets? If response is whireshark, in the dissector for usb raw traffic ther'is some workaround and misunderstood of usb specification... I don't know if truncate packet say in whireshark is attendible. If I have free time, this week, I would try to fix this dissector. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe. -- Fight Internet Censorship! http://www.eff.org ~ Open-Source Community, and Technology Testbed: http://www.house404.co.uk/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
