Wireshark · Ethereal-dev: Re: [Ethereal-dev] New FT type

[Ed Warnicke <hagbard@xxxxxxxxxxxxxxxxxxx>]

Comments inline...

On Thu, 25 Jan 2001, Glen Turner wrote:

> Ed Warnicke wrote:
> > 
> > Just my two sense worth, but my gut tendency is to avoid FT type bloat.
> > Do you really need a new type?  What does this new type accomplish
> > that cannot be accomplished by the existing FT types?  The more types
> > there are the more work has to be done whenever new features are
> > introduced that need to be type aware (like dranges).
> 
> The alternative point of view is that FT types are infrastructure
> that make dissectors easier to write (they become a line of code
> per field), allows novice programmers to write dissectors (and most
> Ethereal contributors are people doing another job, but need a dissector
> for the protocol that is troubling them in that job) and makes the user
> experience consistent.

I'll agree with you that FT types are there in part to make it easier 
to write dissectors.  I myself fall into the class of people you refer to,
those who do another job and need a dissector for a protocol that is 
troubling me at that job.  I don't see how an over proliferation of 
FT types makes it easier for a newbie to write a dissector.  It just
represents more overhead that they have to deal with as they try 
to learn the API.  I don't see how a proliferation of types makes the user 
experience more consistent.  In fact it will tend to do quite the
opposite.  

If you mean the end user (someone who just runs the program) I maintain
that it increases the likelihood that there will be some feature that 
works for some fields and not for others with for no reason that is clear 
to that user (as they don't know anything about our internal type system).

If you mean the casual developer (someone who is just writing one
dissector or trying to correct a problem with a dissector) it is likely 
to make their experience more inconsistent as different types will be 
used for the same sort of task in different pieces of code, thus leading
to either inconsistent examples to draw from as you try to write your 
new dissector or inconsistent use of types as you try to figure out 
how to fix a dissector.

> 
> It also allows one variable change to alter the behaviour of that
> FT type across all dissectors.  For example, consider someone in
> Australia doing a decode of stuff captured in the US.  There's
> currently no way to apply a consistent local time offset short
> of stuffing about with the operating system.

Why does the dissector need to know about time offsets?  This is a UI 
issue.  If you really want your Australian user to get the capture time 
displayed in the local time offset that sort of thing belongs in the UI 
code that presents information to the user, not in the dissector code. 

Dealing with filtering such a time field would be interesting however...
but that is an issue for the filtering code, not the dissector code.  
Simplicity and modularity is key.  

> 
> More precise FT types also help dissector authors from falling
> into traps.  Ethereal currently has one type for dotted-quad IPv4
> addresses.  This is bad: source addresses are different from
> destination addresses are different from route advertisment
> addresses are different from subnet masks.  At the moment Ethereal
> doesn't highlight impossible multicast source addresses, doesn't
> highlight a routing mask of 255.255.255.254 (/31), doesn't
> highlight a destination address of 0.0.0.0, doesn't highlight
> a route of 127.0.0.0/8-32.

Why does the type system need to distinguish these?  At present ethereal
doesn't do any consistent field validation except for some length issues.
This might be an interesting thing to consider adding as a feature, but 
it doesn't have any bearing on the current dissector structure.

Additionally issues of the validity of a packet as being a certain
protocol should be handled locally, in the dissector or its equivalent
used for validity checking, not in the global type system.  Local 
highly modular functions (like our current dissectors) should contain 
the protocol semantics, not global type definitions.

All of the examples you've given above have the same syntax, but carry 
different semantic meanings.  The dissector is where ethereal deals with 
such semantics, not the type system.

> 
> And these are the traps for one seemingly obvious field.
> 
> Notoriously complex fields like times and intervals are not
> handled well at all.  And worse, they are handled inconsistently
> between dissectors.

I conceed that time and intervals could use much improvement.  
You have clearly put some thought into what sorts of things would be 
useful here.  Could you spawn another thread outlining in more detail your 
thoughts on this subject?  I think it deserves to be considered as more 
than just a part of our current FT type discussion.

> 
> Protocols also deliberately include parts of other protocols.
> So far, fields like TCP port numbers are handled through global
> functions rather than being a type.  This will hurt in the longer
> term.  For example, when filtering on TCP ports the user needs to
> enter an integer, the IANA protocol name is not acceptable.
> Having the TCP port as a type is a generic solution to this.

A tcp port number is just that, a number.  An unsigned (16 bit ?)
integer.  The IANA protocol name is not acceptable because an IANA 
protocol name, while it may represent a protocol that may use a well known
port, is not in fact a tcp port.  If you want to filter by protocol 
you can use the existence tags for a protocol and the normal dissection
mechanism will take care of that.  

This is one of the dangers of abusing the type system.  A tendency to
write more into a type than is really there.   Semantics belong in 
the dissectors.  Only REALLY universal syntax ( ip numbers, ethernet
addresses, etc) belong in the type system.  When you start pushing 
semantics up into the type system you will inevidably wind up with 
semantic conflicts spawning even more specialty types.   It all goes to 
hell from there. 

Ed