[tcpdump-workers] 50% received packet are missing
Hello, I use Linux Mandriva 2006 and as I describe in subject with tcpdump 50% of received packet are missing! I provide many test and it's also the same I capture 1/2 of received packets. [user ~]$ uname -a Linux hostname 2.6.12-12mdksmp #1 SMP Fri Sep 9 17:43:23 CEST 2005 i686 Intel(R) Xeon(TM) CPU 3.00GHz unknown GNU/Linux [user ~]$ /usr/sbin/tcpdump --version tcpdump version 3.9.2 libpcap version 0.9.1 Usage: tcpdump [-aAdDeflLnNOpqRStuUvxX] [-c count] [ -C file_size ] [ -E algo:secret ] [ -F file ] [ -i interface ] [ -M secret ] [ -r file ] [ -s snaplen ] [ -T type ] [ -w file ] [ -W filecount ] [ -y datalinktype ] [ -Z user ] [ expression ] [user ~]$ /usr/sbin/tcpdump -i eth1 >test.dump tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes 923 packets captured 1846 packets received by filter 0 packets dropped by kernel Any idea? Thanks Cedric - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Difference between -xx and -XX option outputs
Hi all, Can any one explain me about the outputs of tcpdump -xx and -XX options. The outputs for these options looks like: tcpdump -xx: 15:56:04.440349 arp who-has 172.16.38.3 tell 172.16.16.110 0x: 0003 4724 f364 0806 0001 G$.d 0x0010: 0800 0604 0001 0003 4724 f364 ac10 106e G$.d...n 0x0020: ac10 2603 &... 0x0030: 15:56:04.440505 IP 172.16.16.38.32834 > dns3.nitk.intranet.domain: 12646+ PTR? 223.67.16.172.in-addr.arpa. (44) 0x: 0040 f420 37ea 000d 8845 ac0e 0800 4500 [EMAIL PROTECTED] 0x0010: 0048 1b20 4000 4011 ef3a ac10 1026 ac10 [EMAIL PROTECTED]@..:...&.. 0x0020: c803 8042 0035 0034 3090 3166 0100 0001 ...B.5.40.1f 0x0030: 0332 3233 0236 3702 3136 ...223.67.16 0x0040: 0331 3732 0769 6e2d 6164 6472 0461 7270 .172.in-addr.arp 0x0050: 6100 000c 0001 a. tcpdump -XX 15:57:09.832436 arp who-has 172.16.206.150 tell 172.16.20.10 0x: 0009 6b91 1894 0806 0001 k... 0x0010: 0800 0604 0001 0009 6b91 1894 ac10 140a k... 0x0020: ac10 ce96 0x0030: 15:57:09.839410 arp who-has 172.16.206.151 tell 172.16.20.10 0x: 0009 6b91 1894 0806 0001 k... 0x0010: 0800 0604 0001 0009 6b91 1894 ac10 140a k... 0x0020: ac10 ce97 0x0030: The -xx option prints each packet including its link level header in hex. And -XX option prints each packet including its link level header in hex and ASCII format. As i observed the dots at the end of each output line refers individual bytesSince there are 16 bytes and 16 dots in each line. Is the dots indicate ASCII format of the packet?? If it is like that,in the above o/p format -xx option was printing more ASCII information than the -XX option.(as -XX option has to print the packet both in hex and ASCII formats) tcpdump version : 3.8 libpcap version : 0.8.3 I am running my machine on (EN10MB)Ethernet. -- Thaks & Regards, Latha. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Difference between -xx and -XX option outputs
Latha G wrote: Hi all, Can any one explain me about the outputs of tcpdump -xx and -XX options. The outputs for these options looks like: tcpdump -xx: 15:56:04.440349 arp who-has 172.16.38.3 tell 172.16.16.110 0x: 0003 4724 f364 0806 0001 G$.d 0x0010: 0800 0604 0001 0003 4724 f364 ac10 106e G$.d...n 0x0020: ac10 2603 &... 0x0030: 15:56:04.440505 IP 172.16.16.38.32834 > dns3.nitk.intranet.domain: 12646+ PTR? 223.67.16.172.in-addr.arpa. (44) 0x: 0040 f420 37ea 000d 8845 ac0e 0800 4500 [EMAIL PROTECTED] 0x0010: 0048 1b20 4000 4011 ef3a ac10 1026 ac10 [EMAIL PROTECTED]@..:...&.. 0x0020: c803 8042 0035 0034 3090 3166 0100 0001 ...B.5.40.1f 0x0030: 0332 3233 0236 3702 3136 ...223.67.16 0x0040: 0331 3732 0769 6e2d 6164 6472 0461 7270 .172.in-addr.arp 0x0050: 6100 000c 0001 a. tcpdump -XX 15:57:09.832436 arp who-has 172.16.206.150 tell 172.16.20.10 0x: 0009 6b91 1894 0806 0001 k... 0x0010: 0800 0604 0001 0009 6b91 1894 ac10 140a k... 0x0020: ac10 ce96 0x0030: 15:57:09.839410 arp who-has 172.16.206.151 tell 172.16.20.10 0x: 0009 6b91 1894 0806 0001 k... 0x0010: 0800 0604 0001 0009 6b91 1894 ac10 140a k... 0x0020: ac10 ce97 0x0030: The -xx option prints each packet including its link level header in hex. It's *supposed* to do so, but there's a bug in tcpdump 3.8[.x] that causes it to print in hex and ASCII with "-xx". That bug is fixed in 3.9[.x], which only prints in hex with "-xx". And -XX option prints each packet including its link level header in hex and ASCII format. As i observed the dots at the end of each output line refers individual bytesSince there are 16 bytes and 16 dots in each line. Is the dots indicate ASCII format of the packet?? The dots indicate bytes in the packet that aren't printable ASCII characters. If it is like that,in the above o/p format -xx option was printing more ASCII information than the -XX option.(as -XX option has to print the packet both in hex and ASCII formats) It's printing more ASCII information because 1) the packets in your "-xx" example are DNS packets, with domain names in them, while the "-XX" packets are ARP packets, which don't have any text in them, so the "-xx" packets have more ASCII text in them to print and 2) tcpdump 3.8[.x] has a bug where "-xx" causes it to print in ASCII. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Network byte order in pcap-NG
Slightly off topic, but... On 11/23/05, Guy Harris <[EMAIL PROTECTED]> wrote: ... > For a future libpcap supporting pcap-NG, it might not be; that depends > on how the byte-order issue is handled. I can think of two > possibilities, but there might be others: > > 1) have an ntar_foff contain the byte order in effect at the offset, > as > well as the offset in the file; > > 2) have a data structure attached to a ntar_file_handle structure, > giving the byte order for offset ranges in the file, and look up the > byte order corresponding to a particular offset in that table when a > seek is done. Could the file not store everything in network byte order? I guess there would be a slight speed hit on read/write, but that would all be in processor (or at least in memory) work, but it would seemingly resolve the issue. e > > The former requires less memory and less data structure scanning on a > seek, but it makes an ntar_foff bigger. Ethereal would store an offset > for *every* packet in the file, so a bigger file offset structure might > significantly increase its memory requirements for a big capture. (I'm > worried just about making file offsets 64 bits; given that the structure > is currently a linked list of per-packet records, I might be tempted to > have it just store record length information and compute the offset as > it scans that list forward or backwards.) > > The latter requires that extra data structure, *and* might require that > file offsets be ordered, so that the data structure can be scanned for > the range in which an offset occurs. I'd have to check whether, on all > platforms where the "standard I/O library" routines can be used to > access files > 4GB, either fpos_t is integral or seek/tell APIs that > accept 64-bit file offsets are available. The data structure itself > shouldn't be large - one entry for region, and most files should have a > small number of regions (you're only likely to get more than one region > if you concatenate files from different platforms). > > - > This is the tcpdump-workers list. > Visit https://lists.sandelman.ca/ to unsubscribe. > - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 50% received packet are missing
dalmasso cedric wrote: I use Linux Mandriva 2006 and as I describe in subject with tcpdump 50% of received packet are missing! I provide many test and it's also the same I capture 1/2 of received packets. ... 923 packets captured 1846 packets received by filter There's a bug in libpcap 0.9[.x] (and maybe 0.8[.x]) that causes the count of packets "received by filter" to be twice (or approximately twice) the number of packets actually received, on systems with newer kernels (kernels supporting the PACKET_STATISTICS socket option on PF_PACKET sockets). So it's not that you're capturing 1/2 of the received packets; it's that the reported number of received packets is 2/1 the actual number of received packets. I've checked in a change that should fix this; if you can get the current CVS version of libpcap (and tcpdump) and build them together (unpack both into subdirectories of the same directory, configure and build libpcap, then configure and build tcpdump, so that tcpdump is built with the version of libpcap you just built), or get the next "current" tarball sfrom tcpdump.org (2005-11-25 or later) when it appears on the Web site and try those, see if that fixes the problem. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] segfault on fedora core 4
Guy Harris wrote: What happens if you compile libpcap with GCC's optimizer turned off? I suspect this is a bug in the version of GCC in FC4. And it appears there *is* a bug in the GCC 4.0 in FC4; Google for fc4 compiler bug gcc libvgahw for some reports of it. You might want to mention this to the Fedora maintainers. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] libpcap filter parsing bug
Guy Harris wrote: I'd advise you to talk to the Fedora team about this, and mention that this stuff *doesn't* crash on any other platform. ...and that there is already one known FC4 compiler bug - Google for fc4 compiler bug gcc libvgahw for some reports of it. That bug might also be causing problems with libpcap. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 17.11.2005 - 25.11.2005 GMT
CVS log entries from 17.11.2005 (Thu) 10:07:09 - 25.11.2005 (Fri) 05:04:13 GMT = Summary by authors = = Log entries = Description: date: 2005-11-24 19:27:42 +; author: guy; state: Exp; lines: +2 -1 Don't double-count received packets on Linux systems that support the PACKET_STATISTICS getsockopt() argument on PF_PACKET sockets. Modified files: File: libpcap/pcap-int.h; Revision: 1.76; Date: ; Author: ; --- Description: date: 2005-11-24 19:28:23 +; author: guy; state: Exp; lines: +2 -1 Don't double-count received packets on Linux systems that support the PACKET_STATISTICS getsockopt() argument on PF_PACKET sockets. Modified files: File: libpcap/pcap-int.h; Revision: 1.68.2.7; Date: ; Author: ; --- Description: date: 2005-11-24 19:27:42 +; author: guy; state: Exp; lines: +19 -3 Don't double-count received packets on Linux systems that support the PACKET_STATISTICS getsockopt() argument on PF_PACKET sockets. Modified files: File: libpcap/pcap-linux.c; Revision: 1.118; Date: ; Author: ; --- Description: date: 2005-11-24 19:28:23 +; author: guy; state: Exp; lines: +19 -3 Don't double-count received packets on Linux systems that support the PACKET_STATISTICS getsockopt() argument on PF_PACKET sockets. Modified files: File: libpcap/pcap-linux.c; Revision: 1.110.2.8; Date: ; Author: ; --- Description: date: 2005-11-24 07:42:53 +; author: hannes; state: Exp; lines: +3 -2 avoid double printing of "unknown proto" message Modified files: File: tcpdump/print-chdlc.c; Revision: 1.42; Date: ; Author: ; --- Description: date: 2005-11-24 07:43:57 +; author: hannes; state: Exp; lines: +3 -2 avoid double printing of "unknown proto" message Modified files: File: tcpdump/print-chdlc.c; Revision: 1.32.2.10; Date: ; Author: ; --- Description: date: 2005-11-24 08:15:09 +; author: guy; state: Exp; lines: +4 -3 Improve the description of the output of tcpdump. Modified files: File: tcpdump/tcpdump.1; Revision: 1.178; Date: ; Author: ; --- Description: date: 2005-11-23 05:16:15 +; author: guy; state: Exp; lines: +13 -5 Make it clearer that the hex or hex-and-ASCII dump for "-x", "-xx", "-X", and "-XX" doesn't *replace* the dissected dump, it *augments* it. Modified files: File: tcpdump/tcpdump.1; Revision: 1.177; Date: ; Author: ; --- Description: date: 2005-11-23 04:24:32 +; author: guy; state: Exp; lines: +5 -5 Fix up some formatting. Modified files: File: tcpdump/tcpdump.1; Revision: 1.176; Date: ; Author: ; --- Description: date: 2005-11-23 04:14:09 +; author: guy; state: Exp; lines: +11 -3 Clarify the syntax of a network number. Modified files: File: tcpdump/tcpdump.1; Revision: 1.175; Date: ; Author: ; --- Description: date: 2005-11-24 08:15:50 +; author: guy; state: Exp; lines: +4 -3 Improve the description of the output of tcpdump. Modified files: File: tcpdump/tcpdump.1; Revision: 1.167.2.9; Date: ; Author: ; --- Description: date: 2005-11-23 05:16:51 +; author: guy; state: Exp; lines: +13 -5 Make it clearer that the hex or hex-and-ASCII dump for "-x", "-xx", "-X", and "-XX" doesn't *replace* the dissected dump, it *augments* it. Modified files: File: tcpdump/tcpdump.1; Revision: 1.167.2.8; Date: ; Author: ; --- Description: date: 2005-11-23 04:15:40 +; author: guy; state: Exp; lines: +11 -3 Clarify the syntax of a network number. Modified files: File: tcpdump/tcpdump.1; Revision: 1.167.2.7; Date: ; Author: ; = Summary of modified files = File: libpcap/pcap-int.h Revisions: 1.76, 1.68.2.7 Authors: , --- File: libpcap/pcap-linux.c Revisions: 1.118, 1.110.2.8 Authors: , --- File: tcpdump/print-chdlc.c Revisions: 1.42, 1.32.2.10 Authors: , --- File: tcpdump/tcpdump.1 Revisions: 1.178, 1.177, 1.176, 1.175, 1.167.2.9, 1.167.2.8, 1.167.2.7 Authors: , , , , , , -- Automatic cron job from /tcpdump/bin/makelog - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
