MATE Protocol weirdness [closed]

edit

Hi team - I've finally gotten around to looking at my MATE dissector issues in 2.6 code

I have worked out a MATE dissector which works(ish) but I'm able to match only on the request_id

Pdu giop_pdu Proto giop Transport tcp/ip {
        Extract giop_addr From ip.addr;
        Extract giop_port From tcp.port;
        Extract giop_request_id From giop.request_id;
        Extract giop_request_op From giop-q_quentin.Request_Operation;
        Extract giop_type From giop.type;
};

Gop giop_req On giop_pdu Match (giop_request_id) {
        Start (giop_type=0);
        Stop (giop_type=1);

};

Done;

Only about 3% of all the GIOP packets in my test capture have a value stored for the extracted field giop_addr

I could use the regular ip.src or ip.addr values, but I'd really like to know why - in many (if not most) cases it's only one half of the conversation that has the giop_addr and giop_port fields populated.

It does appear to have changed since 2.2, and that could be why my previously working MATE dissector is now broken.

Sample file: https://www.dropbox.com/s/fg015gu4wlg...

New dissector: https://www.dropbox.com/s/7s47datxxtq...

Old dissector: https://www.dropbox.com/s/brvfq2wilm0...