From: Thomas Bohnert <bohnert@ccrle.nec.de> Subject: Re: tcptrace-bugs Problems to analyze captured files. Date: Wed, 30 Apr 2003 17:33:14 +0200 Message-Id: <200304301733.14360.bohnert@ccrle.nec.de>
Hi Mani,
we downloaded the latest version but our tests discloses two new bugs in the
IPv6 support. Here are my fixes.
First of all i added support for IPv6 in IPv6 tunneld packets, which is used
in the presence of fasthandovers/bicasting.
Additionally i found that the headerlength was computed in a wrong way if
there are destination option headers.
For detailed information see iint gethdrlength() in ipv6.c attached to this
mail.
Now it seems to work properly, but further scrunity is needed and will
performed next days.
plaese tell me your opinion,
Thomas
On Sunday 27 April 2003 01:36, Manikantan Ramadas wrote:
> 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
> > ========================================================
This archive was generated by hypermail 2b30 : 04/30/03 EDT