Date: Sun, 4 May 2003 17:26:59 -0400 From: Manikantan Ramadas <mramadas@cs.ohiou.edu> Subject: Re: tcptrace-bugs Problems to analyze captured files. Message-ID: <20030504212659.GC27589@irg.cs.ohiou.edu>
Hi Thomas,
Thanks for sending this patch to us. We may not have a dumpfile to verify
this before checking in the code with your changes. If you could please send
us a dumpfile with IPv6 encapsulated in IPv6 and any other IPv6 option covered
by your fix, I would be glad to verify and check it into tcptrace CVS tree.
Thanks a lot!
- Mani.
On Wed, Apr 30, 2003 at 05:33:14PM +0200, Thomas Bohnert wrote:
> 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
> > > ========================================================
--
"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 : 05/05/03 EDT