Wireshark · Ethereal-dev: Re: [ethereal-dev] Standards in decode routines

[Richard Sharpe <sharpe@xxxxxxxxxx>]

At 06:18 PM 4/2/99 -0800, Guy Harris wrote:
>> I have insinuated my way onto the team by contributing code and promising
>> to contribute more :-) At some stage I am going to have to add my name to
>> the list of contributors on the help screen :-) 
>
>So what exactly *are* the rules for addition to the AUTHORS file and
>help screen?  I didn't bother adding myself to the former, but Laurent
>Deniel included me when he put the author list in the latter. 
>(Presumably if you're in one list you should be in the other....)

Well, I don't know. I hope that the bar is just low enough that I qualify,
perhaps after adding the SMB decode stuff :-)

>> I am starting to wonder if we have any standards around information
>> presented by the various decode routines. I am looking for some guidelines,
>> and don't mind being part of the solution (ie, coming up with guidelines if
>> they are needed). Are there any guidelines? As I am looking more and more
>> at TCP level protocols (like SMTP, DNS Zone Transfers, SSH, Telnet, etc),
>> it may be that there is a need for such guidelines.
>
>Guidelines of what sort?  What stuff to display, how to display it, when
>to have a line that can be opened to show more details, and stuff such
>as that?

Yes, and I have noticed annoying stuff in NetMon. Spcifically, when
displaying requests and responses, they show the order of the IP addresses
in the info line. Eg,

    HTTP | HTTP Request  From node1 to   node 2
    HTTP | HTTP Response To   node1 from node 2

Now, I am expecting to see these swap around, and it makes more sense if
they swap around, I think, but am interested in other views.

I also wonder if we should format things so that node names or such like
line up? To do it properly requires keeping more state between packets ...

>> 1. It does not presently handle enough protocols.
>
>For any given protocol analyzer, at any time in its life, there probably
>exists at least one person who could say that about it.  :-)

I guess so.

>("snoop" is, not surprisingly, pretty good for looking at ONC RPC
>services, but it doesn't do DNS, nor does it do SMB, and it barely does
>HTTP; NetMon, not surprisingly, does a reasonable job at SMB, but only
>does those ONC RPC protocols with fixed port numbers, and doesn't do
>TFTP; I think Sniffers might do a reasonable job on most protocols, but,
>then again, you have to wait for a new release for a brand-new protocol,
>unless they let you write your own decoders.)

Yes, I guess so.

>I.e., that'll always be true for somebody, but at least we can, over
>time, reduce the number of people that would say that about Ethereal.

That is my hope/goal as well.

>> 2. It does not have an ADDRESS/NAME table as far as I can see. There are
>> many names in other protocols other than DNS names, and NetMon finds them
>> and places them in an ADDRESS/NAME table. I would like to see support for
>> this added.
>
>There's the table maintained by "resolv.c", but that's only for IP and
>Ethernet addresses, and we don't currently have NetMon's ability to
>have protocol parsers add names to the table.

Hmmm, yes, I think we need some address table object plus a bunch of calls
that allow protocol parsers/dissect routines to add types of
names/addresses to the table.

>> 3. At the moment it does not keep any stats, like number of packets in a
>> trace, number of IP packets, etc.
>
>When capturing a trace, it counts the packets of various types (to show
>it in the capture progress window), but it doesn't do that for a trace
>it reads.

Yes, what I was thinking of here is another table plus routines that allow
parsers to increment the count of packet type X (defined as a number).

Eg, 

  stats_incr(PACKET_SMB);

Then we could print out a stats page showing all the types of packets.
However, I have not thought this out well enough yet. It would also be nice
to be able to show max utilization, min utilization, and, as I said before,
graph both on simple screen style graphs and using GTK+ drawables, the
utilization and other stats over time, like 1 second intervals, perhaps
with the interval definable.
Be nice to be able to drill down to a packet range and graph in 10-ms
intervals between two packets :-)

>> 5. The GUI needs some improving. We need ways to set defaults so that
>> ethereal always starts up the way an individual like it. Maybe we need a
>> .etherealrc file that contains startup instructuons?
>
>Well, there *is* ~/.ethereal/preferences, although there are currently
>only 5 things it specifies.

OK, I will have a look at it ...


Regards
-------
Richard Sharpe, sharpe@xxxxxxxxxx, NIC-Handle:RJS96
NS Computer Software and Services P/L, 
Ph: +61-8-8281-0063, FAX: +61-8-8250-2080, 
Samba (Team member), Linux, Apache, Digital UNIX, AIX, C, ...