[John Thacker <johnthacker@xxxxxxxxx>]

On Thu, Sep 21, 2023, 4:20 PM Martin Mathieson via Wireshark-dev <wireshark-dev@xxxxxxxxxxxxx> wrote:

After https://gitlab.com/wireshark/wireshark/-/merge_requests/12195, I'm finding the warnings below.  I think these are valid, based upon editing a mask value and watching how the value was masked/shifted before being looked up in the value_string.

I understand the RoHC example, where a newer version of the protocol supports the new values in a wider field, but the old one still uses the updated value_string, despite some of the values being impossible to match.

A common mistake seems to be to add to the value_string the byte values in the frame, rather than the masked + shifted value of the field as calculated in the item before looking up the value_string.

I can hopefully try to look at these as time permits, but if you are familiar with any of the protocols below, I'd appreciate any fixes/feedback you can give!

Best regards,

Martin

Warning: epan/dissectors/packet-bittorrent.c hf_bittorrent_msg_type filter= bittorrent.msg.type VALS(bittorrent_messages) has max value 261 (0x105) which doesn't fit into 8 bits ( mask is 0x0 )

This one is somewhat odd but intended. There's an 8 bit message type field in the standard Bittorrent protocol, and then the dissector handles the Azureus variant protocol (where messages are identified with a string) by assigning Wireshark internal numbers outside 8 bit range.

John