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.)