[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

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

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.

These would potentially fall victim to the same problem.

Thanks,
Jaap


> On 23 Oct 2020, at 13:12, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
> 
> Hi,
> 
> Quick test shows that this is indeed the interaction between setting lengths after prototree item creation and post dissectors. In fact _all_ proto item modification functions need to be reviewed in this light.
> 
> Thanks,
> Jaap
> 
> 
>> On 23 Oct 2020, at 12:33, Jaap Keuter <jaap.keuter@xxxxxxxxx> wrote:
>> 
>> Hi,
>> 
>> Okay this is indeed weird. The MATE engine picks up the protocol but determines that the protocol fields are in a zero length part of the packet. It sees the fields, but these all fall outside of the zero length part of the packet (obviously). There is something specific about how the MGCP part of the packet dissection is set and that is that the protocol is added zero length to the protocol tree, and afterwards adjusted once its true length is found out. I can’t see why that makes a difference to MATE (being a post dissector, so running once all protocol dissection is done, so the MGCP protocol length is properly set), but we’ll have to see if this is somehow..
>> 
>> (Note to self: having the field length set _after_ adding field to tree, using proto_item_set_len() is subject to TRY_TO_FAKE_THIS_REPR_VOID. If that blocks length setting (because at first run tree=NULL) then all post dissectors, using this length are screwed).
>> 
>> Thanks,
>> Jaap
>> 
>>> On 17 Oct 2020, at 17:22, Harald Welte <laforge@xxxxxxxxxxxx> wrote:
>>> 
>>> Dear wireshark developers,
>>> 
>>> the other problem I have with MATE is that for some protocols/dissectors
>>> I don't seem to be able to extract wireshark fields into MATE attributes.
>>> 
>>> Like in the last e-mail, I'm again working with the following MATE config
>>> https://git.osmocom.org/wireshark-mate/tree/osmocom.mate
>>> 
>>> This time, I'm looking at MGCP traces.  The MATE config states:
>>> 
>>> ---
>>> Pdu mgcp_pdu Proto mgcp Transport udp/ip {
>>> Extract ip_addr From ip.addr;
>>> Extract port From udp.port;
>>> 
>>> Extract mgcp_rsp_code From mgcp.rsp.rspcode;
>>> Extract mgcp_verb From mgcp.req.verb;
>>> Extract mgcp_endpoint From mgcp.req.endpoint;
>>> Extract mgcp_conn_id From mgcp.param.connectionid;
>>> Extract mgcp_spec_endp_id From mgcp.param.specificendpointid;
>>> };
>>> ---
>>> 
>>> For some strnge reason, none of the mgcp.* fields are ever passed into MATE
>>> attributes.
>>> 
>>> Attached is again a pcap file for your reference.  In none of those
>>> packets, MATE extracts the named fields as attributes.  I've checked the
>>> field names several times, and they are correct.  Why are they not added
>>> to 'mgcp_pdu Attributes'?
>>> 
>>> Like the previous topic, I'm not reporting this as a bug as of yet, as
>>> I'm not sure it is a bug or I'm stimply not able to use MATE as
>>> expected.
>>> 
>>> Thanks in advance.
>>> 
>>> Regards,
>>> 	Harald
>>> 
>>> -- 
>>> - Harald Welte <laforge@xxxxxxxxxxxx>           http://laforge.gnumonks.org/
>>> ============================================================================
>>> "Privacy in residential applications is a desirable marketing option."
>>>                                                (ETSI EN 300 175-7 Ch. A6)

Attachment: mgcp.pcap
Description: application/vnd.tcpdump.pcap

>> 
>>> 
>>> ___________________________________________________________________________
>>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>>> Archives:    https://www.wireshark.org/lists/wireshark-dev
>>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>>           mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>> 
>