Date: Sat, 26 Apr 2003 19:36:57 -0400 From: Manikantan Ramadas <mramadas@cs.ohiou.edu> Subject: Re: tcptrace-bugs Problems to analyze captured files. Message-ID: <20030426233657.GA14198@irg.cs.ohiou.edu>
Hi Thomas,
tcptrace had a bug in processing IPv6 headers, which I have fixed.
You can get current tcptrace with this fix from the CVS tree at
http://www.tcptrace.org/download.html
Well, this lets tcptrace read dumpfiles captured with tcpdump.
However, it still has some issues with ethereal capture files. I shall look
into it.
Thanks for pointing us to this bug. Lemme know if it worked for you.
- Mani.
On Wed, Apr 23, 2003 at 04:53:04PM +0200, Thomas Bohnert wrote:
> Hi Mani,
>
> now im back from vacations, and here are our new cognitions:
>
> First of all, i installed the latest version of tcpdump, ethereal and libcap
> as well as the latest tcptrace and xplot. Further, to avoid problems and
> ambiguousness, we skiped using our own tool, the trafficgenerator, and use
> ssh connections for tracing. The link is physically a wlan connection and
> over that we deploy ipv6 mobile-ip (mipl). The traces attached on this file
> are simple connections without handover and all the other mobile-ip related
> stuff. The traces are captured with tcpdump or ethereal, the name of the
> files are (hopefully) selfexplaining.
>
> The problem which arose is, that we are not able to analyze the traces made by
> tcpdump or ethereal. The output of tcptrace is still the same with no
> distinction between tcpdump capturing or ethereal. ( Could there be a
> difference? Both are using libcap.. )
>
> Our goal is to write a publication about the behavior of different tcp
> implementations like Tahoe, Reno, new Reno etc. In this way we would
> appreciate to have a tool which allows us to analyze and to display the
> various effects like packet loss, throughput and many others. Tcptrace seems
> to be exactly the right tool for that purpose so your help would be highly
> appreciated.
>
> Additionally i asked for the permission to send you our trafficgenerator. If
> it would be helpful for you and it is possible i will send them as soon as
> possible, although i assume that there is no difference between a ssh
> conection and the traffic generated by our self.
>
> As a last comment, there is a obviously a bug in Ethereal:
> If you are going to open the captures with that tool, you will instantaneously
> perceive that the tcp checksum is wrong. But actually it is not. Ethereal is
> prooving the checksum but in a wrong way. If IPv6 is used and the home
> address option is present, the checksum has to be calculated with the
> home-address, anytime. Ethereal seems to use the care-of-address....
>
>
> Thanks a lot for your help!
> Thomas, Germany
>
> ========================================================
> Thomas Bohnert, Student
> Network Laboratories Heidelberg
> NEC Europe Ltd.
> Kurfürsten-Anlage 36, 69115 Heidelberg, Germany
> phone: +49 6221 90511-53
> fax: +49 6221 90511-55
> e-mail: thomas.bohnert@ccrle.nec.de
> ========================================================
>
>
> File: ssh_ip6_mn2cn_tcpd_wlan_ip4conf_prom_snaplen0.cap
> ssh session over ipv6 mobilenode -> correspondend node captured with tcpdump
> over wlan0 in promiscous mode and snaplen 0 ( parameter for tcpdump)
>
> File : ssh_ip6_mn2cn_ethereal_0_9_11.cap
> ssh session over ipv6 mobilenode -> correspondend node captured with ethereal
> over wlan0 in promiscous mode
>
> File: test_ipv4.cap
> next to some random traffic there is one connection with our traffic generator
> over ipv4, destination port is 7001.
>
>
> Here is some sample output of tcptrace:
> ####
> [root@mira traces]# tcptrace ssh_ip6_mn2cn_tcpd_wlan_ip4conf_prom_snaplen0.cap
> 1 arg remaining, starting with
> 'ssh_ip6_mn2cn_tcpd_wlan_ip4conf_prom_snaplen0.cap'
> Ostermann's tcptrace -- version 6.4.0 -- Thu Apr 3, 2003
>
> 80 packets seen, 0 TCP packets traced
> elapsed wallclock time: 0:00:00.022224, 3599 pkts/sec analyzed
> trace file elapsed time: 0:00:16.538180
> no traced TCP packets
> ####
>
> ####
> [root@mira traces]# tcptrace test_ipv4.cap
> 1 arg remaining, starting with 'test_ipv4.cap'
> Ostermann's tcptrace -- version 6.4.0 -- Thu Apr 3, 2003
>
> 2026 packets seen, 2010 TCP packets traced
> elapsed wallclock time: 0:00:00.069052, 29340 pkts/sec analyzed
> trace file elapsed time: 0:01:03.283814
> TCP connection info:
> 1: 10.10.254.249:1077 - 10.13.20.4:7001 (a2b) 2> 1< (reset)
> ** Warning, a2b: detected 1 hardware duplicate(s) (same seq # and IP ID)
> 2: 10.10.254.249:1078 - 10.13.20.4:7001 (c2d) 1005> 1002< (complete)
> ** Warning, c2d: detected 1 hardware duplicate(s) (same seq # and IP ID)
> ####
>
>
>
>
>
>
>
>
>
> On Friday 18 April 2003 04:08, you wrote:
> > Hi Thomas,
> >
> > I guess the header you have given me is the link layer header, right?
> > This header structure is new to me (Why does the header of each packet have
> > the total# of packets in a field?)
> >
> > Could you please give us a sample dumpfile containing this traffic, so I
> > can parallely see how ethereal understands it, to figure out what can
> > be done for tcptrace?
> >
> > Thanks!
> > Mani.
> >
> > On Thu, Apr 17, 2003 at 03:13:23PM +0200, Thomas Bohnert wrote:
> > > Hi Mani,
> > >
> > > of course, here is the information.
> > >
> > > /* the fixed header of each packet */
> > > struct packethdr_t{
> > > int number; //packet number (starts with 1)
> > > int size; // size of this packet (in bytes)
> > > int interval; // packet interval (in ms)
> > > int total; // total # of packets
> > > };
> > >
> > > all data behind the header are is random.
> > >
> > > thanks for your help,
> > > Thomas
> > >
> > > On Thursday 17 April 2003 14:47, you wrote:
> > > > Hi Thomas,
> > > >
> > > > It seems to me that tcptrace does not understand the packet format in
> > > > the traffic you collect. Could you please give us a sample dumpfile
> > > > with this packet format?
> > > >
> > > > - Mani.
> > > >
> > > > On Thu, Apr 17, 2003 at 01:34:17PM +0200, Thomas Bohnert wrote:
> > > > > Hi,
> > > > >
> > > > > We do some investigations in mobile IPv6 and fast handovers. The goal
> > > > > is to find out the packet loss and the impact for the tcp/ip stack.
> > > > > To analyze the trafffic i choose tcptrace as recommended in RFCxxx.
> > > > > In this way, i caputred some random traffic over a wlan link with
> > > > > tcpdump. This traffic is generated by a small selfwritten generator.
> > > > > Ethereal is able to open the produced file and to decode all headers
> > > > > including tcp. The payload of the packets is shown as TCP short frame
> > > > > of course; the generator uses a proprietary protocol.
> > > > > The problem now is that i can't decode the packets with tcptrace.
> > > > > After opening the trace the following message is printed:
> > > > >
> > > > > [bothom@mira capture_11.36]# tcptrace 11.36.cap
> > > > > 1 arg remaining, starting with '11.36.cap'
> > > > > Ostermann's tcptrace -- version 6.4.0 -- Thu Apr 3, 2003
> > > > >
> > > > > 1009 packets seen, 0 TCP packets traced
> > > > > elapsed wallclock time: 0:00:00.007539, 133837 pkts/sec analyzed
> > > > > trace file elapsed time: 0:00:21.643035
> > > > > no traced TCP packets
> > > > >
> > > > > The files are captured as followed:
> > > > > tcpdump -q -i any -w 11.36.cap
> > > > >
> > > > >
> > > > > thanks for your help;
> > > > >
> > > > > Thomas Bohnert
>
> --
> ========================================================
> Thomas Bohnert, Student
> Network Laboratories Heidelberg
> NEC Europe Ltd.
> Kurfürsten-Anlage 36, 69115 Heidelberg, Germany
> phone: +49 6221 90511-53
> fax: +49 6221 90511-55
> e-mail: thomas.bohnert@ccrle.nec.de
> ========================================================
--
"A man is but a product of his thoughts; what he thinks, that he becomes."
- Mahatma Gandhi
____________________________________________________________________________
* Manikantan Ramadas * IRG, Ohio Univ. * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________________
This archive was generated by hypermail 2b30 : 04/27/03 EDT