Ethereal-dev: Re: [Ethereal-dev] RFC: add more flags to the protocol tree for a start of an ex

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <gharris@xxxxxxxxx>
Date: Sun, 21 Aug 2005 11:03:59 -0700
Ulf Lamping wrote:

Add some more optional flags to the protocol items, so more "special cases" can be marked in the protocol tree. What came to my mind:
/** The protocol field has a bad checksum */
FI_CHECKSUM_ERROR
/** The protocol field has an unusual sequence (e.g. TCP window is zero) */
FI_SEQUENCE_WARNING
/** The protocol field has a bad sequence (e.g. TCP segment is lost) */
FI_SEQUENCE_ERROR
If protocols are going to be able to tag fields with errors, should they 
be flags from a fixed set, or should there be a way to attach to a 
protocol tree item either a single error tag, or a set of error tags, 
from an extensible set, so that a protocol can add its own error types?
If so, the FI_ values could perhaps be "classes" of errors of which a 
tag could be made a member.
In either case, there should probably be FI_ values for retransmissions 
and perhaps for excessive delays between request and response, 
transmission and ACK, etc..
At several places we might need new preference settings, if this or that condition should be marked as a error/warning/nothing. E.g. the TCP checksum in some captures are completely broken, but won't indicate any problem so Ethereal shouldn't warn about it.
We already have an option to control whether to check TCP checksums, for 
the reason you describe (the lack of a valid checksum in packets 
transmitted on an interface doing TCP checksum offloading).  (If we can 
get from libpcap
	1) an indication of whether an interface does checksum offloading, 
which we probably can on at least some OSes
and

2) an indication of whether a packet was transmitted by the host running the application or not
we could automatically handle that issue.  With pcap-NG and some API 
changes I plan to make in the next libpcap release, that should be 
possible on some platforms, and with some changes to BPF that I'll look 
into implementing and try to get various BSDs to pick up, it might be 
possible on those BSDs.)