Re: [tcpdump-workers] Research on tcpdump
> "Raymond" == Raymond Borges writes: Raymond> I'm doing research on tcpdump and I've been trying to Raymond> locate the source code for versions previous to 3.5.0 but Raymond> haven't had much luck. Do you know where I might find Raymond> these? Thank you. hi, 3.5 was released in 2000. That was the first release by the tcpdump.org group. Prior to that it would have been done by the LBL folks... the 3.4 release was probably 3-4 years earlier.We have the CVS tree back to the beginning, and it was imported into git, so there maybe some evidence of what it looked like. What specific questions were you trying to answer in your research? -- Michael Richardson -on the road- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] why the ethernet and ip header of packets, which are captured by libpcap function, are distorted
I used libpcap function pcap_next() to capture some tcp packets I checked the bytes of the captured packets and notice that the ethernet and ip header of packets are distorted, in a mess with a lot 0's but the TCP header is fine what are potential reasons for this? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] why the ethernet and ip header of packets, which are captured by libpcap function, are distorted
On Mar 15, 2013, at 9:07 AM, wen lui wrote: > I used libpcap function pcap_next() to capture some tcp packets I checked > the bytes of the captured packets and notice that the ethernet and ip > header of packets are distorted, in a mess with a lot 0's but the TCP > header is fine > > what are potential reasons for this? One potential reason could be that the program calls pcap_next(), then calls pcap_close(), and then tries to use the data pointed to by the pointer returned by pcap_next(), which isn't going to work: http://stackoverflow.com/questions/15436969/why-the-ethernet-and-ip-header-of-packets-which-are-captured-by-libpcap-functio/ If that's the reason, only call pcap_close() when you're finished processing all packets. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Research on tcpdump
On Mar 15, 2013, at 5:45 AM, Michael Richardson wrote: > Prior to that it would have been done by the LBL folks... the 3.4 > release was probably 3-4 years earlier.We have the CVS tree back to > the beginning, and it was imported into git, so there maybe some > evidence of what it looked like. There are also tarballs for older versions of libpcap and tcpdump at ftp://ftp.ee.lbl.gov/old -r--r--r-- 1 ftp ftp117021 Apr 28 1995 libpcap-0.0.5.tar.Z -r--r--r-- 1 ftp ftp117021 Apr 28 1995 libpcap-0.0.6.tar.Z -r--r--r-- 1 ftp ftp 2805 Sep 21 1994 libpcap-0.0.patch1 -r--r--r-- 1 ftp ftp 5250 Oct 12 1994 libpcap-0.0.patch2 -r--r--r-- 1 ftp ftp 1285 Oct 18 1994 libpcap-0.0.patch3 -r--r--r-- 1 ftp ftp113737 Jun 20 1994 libpcap-0.0.tar.Z -r--r--r-- 1 ftp ftp175849 Jun 18 1996 libpcap-0.1a3.tar.Z -r--r--r-- 1 ftp ftp186409 Jul 23 1996 libpcap-0.2.1.tar.Z -r--r--r-- 1 ftp ftp182488 Jun 24 1996 libpcap-0.2.tar.Z -r--r--r-- 1 ftp ftp202715 Dec 22 1996 libpcap-0.3.1a2.tar.Z -r--r--r-- 1 ftp ftp200073 Dec 12 1996 libpcap-0.3.tar.Z -r--r--r-- 1 ftp ftp209551 Jul 25 1998 libpcap-0.4.tar.Z -r--r--r-- 1 ftp ftp208823 Jun 12 1997 libpcap-0.4a1.tar.Z -r--r--r-- 1 ftp ftp209375 Jan 30 1998 libpcap-0.4a6.tar.Z -r--r--r-- 1 ftp ftp209609 Jul 12 1998 libpcap-0.4a7.tar.Z ... -r--r--r-- 1 ftp ftp 2071 Jan 26 1991 tcpdump-2.0.patch-1 -r--r--r-- 1 ftp ftp243087 Jan 15 1991 tcpdump-2.0.tar.Z -r--r--r-- 1 ftp ftp 10200 Jun 2 1992 tcpdump-2.2-2.2.1.diff -r--r--r-- 1 ftp ftp313705 Jun 2 1992 tcpdump-2.2.1.tar.Z -r--r--r-- 1 ftp ftp313517 Jun 2 1992 tcpdump-2.2.old.tar.Z -r--r--r-- 1 ftp ftp205713 Apr 27 1995 tcpdump-3.0.2.tar.Z -r--r--r-- 1 ftp ftp205767 Feb 16 1996 tcpdump-3.0.4.tar.Z -r--r--r-- 1 ftp ftp 1347 Oct 7 1994 tcpdump-3.0.patch1 -r--r--r-- 1 ftp ftp204317 Jun 20 1994 tcpdump-3.0.tar.Z -r--r--r-- 1 ftp ftp262856 Jun 18 1996 tcpdump-3.1a3.tar.Z -r--r--r-- 1 ftp ftp279409 Jul 23 1996 tcpdump-3.2.1.tar.Z -r--r--r-- 1 ftp ftp269953 Jun 24 1996 tcpdump-3.2.tar.Z -r--r--r-- 1 ftp ftp314160 Dec 12 1996 tcpdump-3.3.tar.Z -r--r--r-- 1 ftp ftp330311 Jul 25 1998 tcpdump-3.4.tar.Z -r--r--r-- 1 ftp ftp329931 Jun 13 1997 tcpdump-3.4a3.tar.Z -r--r--r-- 1 ftp ftp329443 Jan 30 1998 tcpdump-3.4a6.tar.Z -r--r--r-- 1 ftp ftp329427 Jul 12 1998 tcpdump-3.4a7.tar.Z -r--r--r-- 1 ftp ftp 81415 Apr 3 1990 tcpdump.sun2.Z -r--r--r-- 1 ftp ftp110727 Apr 3 1990 tcpdump.tar.Z (I don't see any tcpdump-1.x or -0.x there). ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] why the ethernet and ip header of packets, which are captured by libpcap function, are distorted
> "wen" == wen lui writes: wen> I used libpcap function pcap_next() to capture some tcp packets wen> I checked the bytes of the captured packets and notice that the wen> ethernet and ip header of packets are distorted, in a mess with wen> a lot 0's but the TCP header is fine wen> what are potential reasons for this? if you capture on Linux with the cooked mode interface. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] why the ethernet and ip header of packets, which are captured by libpcap function, are distorted
On Mar 15, 2013, at 2:45 PM, Michael Richardson wrote: > >> "wen" == wen lui writes: >wen> I used libpcap function pcap_next() to capture some tcp packets >wen> I checked the bytes of the captured packets and notice that the >wen> ethernet and ip header of packets are distorted, in a mess with >wen> a lot 0's but the TCP header is fine > >wen> what are potential reasons for this? > > if you capture on Linux with the cooked mode interface. That probably won't happen if you're capturing on an Ethernet device, but it *will* happen if you capture on the "any" device. However, yes, *NO* program using libpcap/WinPcap should simply *assume* it's getting Ethernet packets; if it's looking at the packets, not just blindly writing them to a file without examining the contents, then, if it doesn't need to handle 802.11 and PPP and so on, just Ethernet, it should at least call pcap_datalink() and fail if the return value isn't DLT_EN10MB. (If it's writing them to a pcap file, pcap_dump_open() will call pcap_datalink() for you, to put the right link-layer header type in the file header.) (Should we change libpcap so that if pcap_datalink() isn't called at least once before calling pcap_next(), pcap_next_ex(), pcap_dispatch(), or pcap_loop(), it prints a message to the standard error saying "you're probably assuming all the world is Ethernet, aren't you?" and calls abort(). :-)) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
