Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 8859] Apply consistent naming convention to checksum display filter fields and

[bugzilla-daemon@xxxxxxxxxxxxx]

Peter Wu changed bug 8859

What	Removed	Added
CC		peter@lekensteyn.nl

Comment # 2 on bug 8859 from Peter Wu

Creating a proto_tree_add_checksum seems a good idea, but it may get hairy.
First some semantics, right now we have some fields:

PROTO.checksum
PROTO.checksum_bad
PROTO.checksum_good

And recently I have been adding:

PROTO.checksum_calculated.

checksum_bad and checksum_good are oddballs. I would expect them to act as a
boolean for existence, but you actually have to check ip.checksum_bad==1 for
example. If checksumming is enabled, then PROTO.checksum_bad==1 implies
PROTO.checksum_good==1 (and vice versa). Why do we have two fields for this?

Some dissectors add expert info for bad checksums (shouldn't this also be
included in the generic function?), such as tcp.checksum_bad.expert.

Initial prototype I thought of before considering other problems:

proto_tree *
proto_tree_add_checksum_tree(proto_tree *tree, int hfindex, tvbuff_t *tvb,
gint start, gint length, const char *cksum_expected);

The char ptr is an easy way to shoot yourself in the foot (ensure that the
length is sane), an alternative is different functions for 16-bit and 32-bit
cksums. This functions is quite unique in the sense that it returns a tree.

Next problem... how to register the multiple hf's for PROTO.checksum,
PROTO.checksum_calculated (and optionally PROTO.checksum_bad?).

(off-topic) Btw, I see a "fp.header.bad_checksum." field with a trailing dot.
Shouldn't that be disallowed? (dissector assert / checkAPI.pl?)

---

      You are receiving this mail because:

• You are watching all bug changes.