Date: Wed, 7 May 2003 11:47:58 -0400 From: Manikantan Ramadas <mramadas@cs.ohiou.edu> Subject: Re: tcptrace-bugs Problems to analyze captured files. Message-ID: <20030507154758.GA8220@irg.cs.ohiou.edu>
Hi Thomas,
I have received them. I shall get back to you soon.
- Mani.
On Wed, May 07, 2003 at 12:07:31PM +0200, Thomas Bohnert wrote:
> Hi Mani,
>
> i sent you some dumpfiles did you not get them? What about the patch i sent to
> you?
>
> Thomas
>
> On Sunday 04 May 2003 23:26, Manikantan Ramadas wrote:
> > 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/07/03 EDT