Ethereal-dev: Re: [Ethereal-dev] RFC: add more flags to the protocol tree for a start of an ex
And what about an FI_ for protocol violations like invalid fields and
so on?
Best regards
Michael
On Aug 21, 2005, at 20:03 Uhr, Guy Harris wrote:
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.)
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
