Re: tcptrace Feature Request

From: Kevin (kevin1m@aol.com)
Date: 10/14/02

  • Next message: Avinash Lakhiani: "Re: tcptrace Feature Request"

    Date: Mon, 14 Oct 2002 08:07:20 -0400
    Subject: Re: tcptrace Feature Request
    From: Kevin <kevin1m@aol.com>
    Message-Id: <7D9F5FA1-DF6D-11D6-BBFE-000393D5E998@aol.com>
    
    

    Actually, the header could be necessary. Instead of dropping it, lets
    mark it so we can discard it or use it as needed.
    Kevin

    On Monday, Oct 14, 2002, at 05:30 US/Eastern, cano@pc2072te.dte.uma.es
    wrote:

    > I think the same, its looks good. Thank you.
    >
    > I suggest the same modification, the same I suggested in a previous
    > email:
    > Please, redirect the header and some warnings messages to "stderr"
    > instead of
    > "stdout", so the header is not saved when output is redirected to a
    > file.
    >
    > Thanks again
    >
    > Jose Manuel Cano-Garcia
    >
    >
    >
    > El Lun 14 Oct 2002 01:59, Desem, Can escribiÛ:
    >> Thanks Avinash,
    >>
    >> This looks very good.
    >>
    >> The first few lines need to be deleted or ignored if you want to
    >> import it
    >> to a spreadsheed but this would be trivial. However, if these lines
    >> were
    >> not printed or if they were printed on a line with commas or with the
    >> serparator of choice one could directly import the output without this
    >> additional step.
    >>
    >> If the lines with text or empty lines started with a uniqe symbol
    >> such as
    >> '#' (indicating comment as in perl, gnuplot) it might be also be
    >> simpler to
    >> use. For example one can directly import it into gnuplot etc. But for
    >> other
    >> tools, programs this may not be the case.
    >>
    >> However, I am perfectly happy to use it as it stands.
    >>
    >> Thanks again,
    >>
    >> Can Desem
    >>
    >>
    >> -----Original Message-----
    >> From: Avinash Lakhiani [mailto:alakhian@masaka.cs.ohiou.edu]
    >> Sent: Sunday, 13 October 2002 10:57
    >> To: Desem, Can
    >> Cc: tcptrace-main-list
    >> Subject: Re: tcptrace Feature Request
    >>
    >>
    >> Can, Kevin, Mark,
    >>
    >> I would like to apologize for the extreme delay in completing the new
    >> feature
    >> for the comma separated values. I have it working fine (except for one
    >> small bug that I shall fix by the end of this weekend).
    >>
    >> What I have working are the following options:
    >>
    >> '-l --csv' /* Comma separated values */
    >> '-l --tsv' /* Tab separated values */
    >> '-l --sv=<SP>' /* <SP> separated values, where SP is a user defined
    >> string
    >> */
    >>
    >> Attached is a file that I generated using the '-l --csv' options. I
    >> request
    >> all those who were interested in this feature to please provide me
    >> with
    >> some feedback as to whether this is the way they wanted to see this
    >> feature
    >> work.
    >>
    >> I have tested the file using an office spread sheet program (after
    >> deleting
    >> the first few header lines).
    >>
    >> Thanking you in advance!
    >>
    >> --Avinash
    >> (tcptrace-maintainer)
    >>
    >> On Tue, Sep 17, 2002 at 08:38:10AM +1000, Desem, Can wrote:
    >>> Avinash,Kevin,
    >>>
    >>> I use tcptrace quite a lot and I have written a simple perl script to
    >>> convert the long format to a single comma separated line. I find it
    >>> more
    >>> useful if all the output is in one line rather than many lines as in
    >>> this
    >>> out.txt file and without the field names (I assume this is your
    >>
    >> intention).
    >>
    >>> It would be useful to have the field names as the first line and
    >>> just the
    >>> fields for the subsequent lines. I think it would also be essential
    >>> to
    >>> add the start and end times for the flow/trace. So the out.txt could
    >>> be
    >>> something like;
    >>>
    >>> host_a,hostb,port_a,port_b,totalpackets_a,.........,startTime,stopTim
    >>> e
    >>> 10.10.10.1,10.10.10.2,62953,23,52,.................,10311111,10322222
    >>> 10.10.20.2,10.10.10.3,6666,22,444,.................,10322222,10322122
    >>>
    >>>
    >>> Regards,
    >>> Can Desem
    >>> Telstra
    >>>
    >>>
    >>>
    >>> -----Original Message-----
    >>> From: Avinash Lakhiani [mailto:alakhian@masaka.cs.ohiou.edu]
    >>> Sent: Tuesday, 17 September 2002 05:56
    >>> To: Kevin
    >>> Cc: tcptrace-main-list
    >>> Subject: Re: tcptrace Feature Request
    >>>
    >>>
    >>> Kevin,
    >>>
    >>> I tried a small experiment with the long data hand-crafted for excel
    >>> and
    >>
    >> it
    >>
    >>> did indeed accept the data pretty well. I used commas to separate the
    >>> data with the first field being the field name and the second and
    >>> third
    >>> fields being for a->b and b->a. Please take a look at the attached
    >>> file
    >>> out.txt
    >>
    >> to
    >>
    >>> see if you think it would be nice to have the data that way.
    >>>
    >>> Thank you!
    >>>
    >>> --Avinash.
    >>>
    >>> On Mon, Sep 16, 2002 at 01:34:14PM -0400, Kevin wrote:
    >>>> In truth I can live with either. Given the choice, the 2nd option
    >>>> is
    >>>> what I am building my current awk/sed script to. It just seems
    >>>> simpler
    >>>> to hand off pairs of data to be counted. I also suggest the
    >>>> source/dest (a/b) as the 1st field of the line.
    >>>>
    >>>> Thanks for the chance to have input!
    >>>> Kevin Mason
    >>>>
    >>>>> -----Original Message-----
    >>>>> From: alakhian@masaka.cs.ohiou.edu
    >>>>> [mailto:alakhian@masaka.cs.ohiou.edu]
    >>>>> Sent: Monday, September 16, 2002 13:28
    >>>>> To: Kevin
    >>>>> Cc: tcptrace@tcptrace.org
    >>>>> Subject: Re: tcptrace Feature Request
    >>>>>
    >>>>>
    >>>>> Kevin,
    >>>>>
    >>>>> We discussed about your feature request and believe that it
    >>>>> would indeed be a good idea, and very flexible too as Mark
    >>>>> said. The changes to output.c would be very trivial and we
    >>>>> could add a --csv option. The question remains as to what
    >>>>> would be the best representation of the data fields so as to
    >>>>> make this option really useful. I gave this some thought but
    >>>>> I believe that since you and many other would be the ones to
    >>>>> actually use this feature, it would be better to get some
    >>>>> feedback first.
    >>>>>
    >>>>> Since you would want to use this data for some sort of
    >>>>> further processing, obviously the text would not be very
    >>>>> useful. So, would it be useful to output all the data in the
    >>>>> same order (as the long output) separated by commas with a->b
    >>>>> first followed by b->a. Or should the data be sorted based on
    >>>>> fields such as:
    >>>>>
    >>>>> total packets: 52 total packets: 38
    >>>>> ack pkts sent: 51 ack pkts sent: 38
    >>>>>
    >>>>> to look like 52,38,51,38
    >>>>>
    >>>>> where the data is ordered as total_packets_ab,
    >>>>> total_packets_ba, ack_pkts_sent_ab, ack_pkts_sent_ba ...
    >>>>>
    >>>>> Comments/Suggestions?
    >>>>>
    >>>>> Thanks!
    >>>>>
    >>>>> --Avinash
    >>>>> (tcptrace-maintainer)
    >>>>>
    >>>>> On Mon, Sep 09, 2002 at 11:36:43AM -0400, Kevin wrote:
    >>>>>> My apologies if this is being sent to the wrong list.
    >>>>>>
    >>>>>> When using tcptrace -l a lot of very useful information is output.
    >>>>>> When there are lots of sessions (>20) the output format is
    >>>>>
    >>>>> cumbersome
    >>>>>
    >>>>>> to compare the various sessions.
    >>>>>>
    >>>>>> Would it be possible to have to have an option to output in CSV
    >>>>>> format? That way the data can be sorted and sifted to
    >>>>>
    >>>>> compare various
    >>>>>
    >>>>>> errors or performance values.
    >>>>>>
    >>>>>> Thanks
    >>>>>> Kevin Mason
    >>>>>
    >>>>> --
    >>>>> Avinash Lakhiani (http://www.tcptrace.org/~alakhian)
    >>>>> --
    >>>>>
    >>>>> ---
    >>>>> Incoming mail is certified Virus Free.
    >>>>> Checked by AVG anti-virus system (http://www.grisoft.com).
    >>>>> Version: 6.0.386 / Virus Database: 218 - Release Date: 9/9/2002
    >>
    >> ----------------------------------------------------------------------
    >> -----
    >> -
    >>
    >>>> To unsubscribe, send a message with body containing "unsubscribe
    >>
    >> tcptrace"
    >>
    >>> to
    >>>
    >>>> majordomo@tcptrace.org.
    >>>
    >>> --
    >>> Avinash Lakhiani (http://www.tcptrace.org/~alakhian)
    >>> --
    >
    >
    > -----------------------------------------------------------------------
    > -----
    > To unsubscribe, send a message with body containing "unsubscribe
    > tcptrace" to
    > majordomo@tcptrace.org.

    ----------------------------------------------------------------------------
    To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
    majordomo@tcptrace.org.



    This archive was generated by hypermail 2b30 : 10/14/02 EDT