On Thu, Sep 21, 2023, 4:20 PM Martin Mathieson via Wireshark-dev < wireshark-dev@wireshark.org> 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 >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
