Re: MATE not extracting fields as requested

[Harald Welte <laforge () gnumonks org>]

Hi Jaap,

thanks for your insight into the matter.  As you confirm there is an actual bug, I will raise
it in gitlab, together with extracts of your findings here.

On Fri, Oct 23, 2020 at 05:39:29PM +0200, Jaap Keuter wrote:
> Looking at the proto item modification functions there were a series of changes involving the (very tricky) 
> optimisation considerations. Bug 10329 was the reason the latest optimisation was put in place.

As occasional contributor, I'm not too familiar with the wireshark
development process.  To me, it sounds like the kind of bug for which
one would want to have a unit test to make sure any changes of
optimization will not change the semantics for MATE users.

> Not wanting to mess with that there’s another way to address this.
> Adding the protocol tree root item is done with zero length and later
> extended, as described below. The better approach is to add the item
> with length -1, meaning until the end of the buffer. Then the protocol
> item does cover the fields MATE wants to extract. This has two
> possible issues though, first one is that it probably doesn’t cover
> reassembly well, another is that repeated protocols may cause problems
> extracting the desired value.

For MGCP this is luckily not an issue, as there's neither fragmentation
nor - to my knowledge - repeated MGCP messages in the same packet.

> Looking for protocol items added with zero length this list comes up after a casual search:
> gsm_um, netmon, cisco-erspan, isdn, wtp, atn-cm, hci-h1, slowprotocls,
> ieee80211-radio, pcomtcp, pktc, atalk, mgcp(!), epon, hci_h4,
> f5ethtrailer, aruba-erm, cisco-sm, pflog, clip, aruba-adp, mtp3.

I'm not familiar with most of those.  As for
* gsm_um: I'm not aware of encapsulations that would repeat multiple gsm_um payload in the one packet
* mtp3: Here it is indeed quite normal to have multiple MTP3 messages
  encapsulated in e.g. one IP/SCTP packet with multiple DATA chunks
  containing M2UA or M2PA, which then contains MTP3.

-- 
- Harald Welte <laforge () gnumonks org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
___________________________________________________________________________
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-request () wireshark org?subject=unsubscribe