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?
Well, but how to *display* these "user error types" then?
We might split into a general error level enum (2-3 bits) and some
predefined causes which can be added later.
As this should be an interface between the protocol dissection and the
display of the tree it might not even be desirable to have a *lot* of
different id's, or do I miss something here?
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..
Sounds reasonable, but I would think these id's could be added on demand.
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.)
After all, this was only meant as an example and being able to switch
TCP checksum check off might be sufficient for now, but adding some
automatism might be a good idea anyway...
Regards, ULFL