Updating MATE config

mate
DisplayFilters
retag add tags

Hi team - I'm trying to work out what's changed in Wireshark between version 2 and 2.6 with regard to MATE

Previously I was successfully matching sessions and PDUs based on the following - but now a new PDU is being created for every message refined question yesterday, with updated MATE filter

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

Now, I'm getting the PDU displayed, but I'm not able to filter on the request/reply Capture example

https://i.imgur.com/XVR06dR.png (image linked separately so it's easier to view)

I'm sure I'm missing something obvious, but I can't work out the syntax to ensure that I'm matching the right object in the reply

solved by Sindy below

Linked question that I asked yesterday after drilling down into it: https://ask.wireshark.org/question/54...

And the bug raised yesterday: https://bugs.wireshark.org/bugzilla/s...

Scott Harman

asked 2018-08-08 03:08:40 +0000, updated 2018-10-16 23:27:37 +0000

edit flag offensive 0 remove flag close merge delete

Comments

That image is really small and impossible to read. Do you have a capture file you can post instead? I'm no MATE expert but it might benefit someone else who could possibly provide some help. Paging @sindy ...

cmaynard (2018-10-16 16:12:32 +0000) edit

add a comment see more comments

2 Answers

Sort by

oldest

newest

most voted

A change that should fix this bug, bug 15208, has been checked in.

19.9k

Guy Harris

answered 2018-10-20 09:17:07 +0000

edit flag offensive 0 remove flag delete link

Comments

add a comment see more comments

My problem is that I don't speak C++ (and I haven't used MATE for at least two years), so I can only surf the surface, but what I could find is that in 2.6.4., MATE has problems to extract fields from protocols specified by the Transport clause of the Pdu definition. Don't give up reading - workaround inside.

For the following configuration,

Pdu sip_pdu Proto sip Transport udp/ip {
  Extract ipaddr From ip.addr;
  Extract udpport From udp.port;
  Extract user From sip.from.user;
  Extract user From sip.to.user;
  Extract user From sip.ppi.user;
  Extract callid From sip.Call-ID;
  Extract method From sip.Method;
  Extract cseq From sip.CSeq.seq;
  Extract resp_code From sip.Status-Code;
  Extract req_method From sip.CSeq.method;
  Transform start_stop_cond, xtract_rsp;
};

MATE log says (### comments added by me):

mate_analyze_frame: trying to extract: sip_pdu
mate_analyze_frame: found matching proto, extracting: sip_pdu
new_pdu: type=sip_pdu framenum=1
new_pdu: proto range 42-966
get_pdu_fields: found field 34-36
### this matches to udp.srcport
get_pdu_fields: found field 36-38
### this matches to udp.dstport
get_pdu_fields: found field 42-48
get_pdu_fields: got method=INVITE
get_pdu_fields: found field 261-266
get_pdu_fields: got user=10001
get_pdu_fields: found field 194-199
get_pdu_fields: got user=10003
get_pdu_fields: found field 298-344
get_pdu_fields: got [email protected]
get_pdu_fields: found field 350-351
get_pdu_fields: got cseq=1
get_pdu_fields: found field 352-358
get_pdu_fields: got req_method=INVITE
get_pdu_fields: found field 26-30
### this matches to ip.src
get_pdu_fields: found field 30-34
### this matches to ip.dst
mate_analyze_frame: trying to extract: sip_pdu
### this is the start of processing of next frame

So it does find both the ip.addr fields (ip.src and ip.dst) and both udp.port fields but it has some problem with their size and (therefore?) it doesn't extract them. It does not, however, have a problem with the SIP fields whose size it determines properly.

So in your case, giop_addr and giop_port don't get extracted, which means that the Gop doesn't build up as its Match requires both of them (twice).

But as I was trying to understand where the problem was (because I was suspecting the ip and tcp dissectors to report wrong field size to MATE), I have incidentally found a workaround for you.

If you add

Pdu ip_pdu Proto ip Transport eth {
  Extract ipaddr From ip.addr;
};

Pdu tcp_pdu Proto tcp Transport ip {
  Extract port From tcp.port;
};

before the Pdu giop_pdu in your MATE configuration file, some voodoo will make MATE identify the fields when it extracts them for the giop Pdu as they have been previously extraced for their native protocols when processing the same frame, despite the fact that the length is incorrect even when they are extracted from their native Proto:

mate_analyze_frame: trying to extract: udp_pdu
mate_analyze_frame: found matching proto, extracting: udp_pdu
new_pdu: type=udp_pdu framenum=1
new_pdu: proto range 34-42
get_pdu_fields: found field 34-36
get_pdu_fields: got port=5060
get_pdu_fields: found field 36-38
get_pdu_fields: got port=5060

So please file a bug, place a link to ... (more)

6.2k

sindy

answered 2018-10-16 19:40:17 +0000, updated 2018-10-16 19:43:04 +0000

edit flag offensive 0 remove flag delete link

Comments

Thanks Sindy - that solves it. I'd worked out that it was a bug yesterday, as I did some testing with the sample MATE filters. Bug that I logged yesterday is 15208.

Scott Harman (2018-10-16 23:22:55 +0000) edit

My problem is that I don't speak C++

Or C, presumably - the core Wireshark dissection code, the Wireshark dissectors, and MATE are all written in C, not C++.

Guy Harris (2018-10-19 02:11:32 +0000) edit

My excuse for this embarrasing mistake is that I've never managed to cross the barrier of installing the development environment and wrapping my head around having related pieces of code scattered over several files. A Lua dissector for a single protocol in a single file is the maximum of my competence as a programmer. So when updating the MATE manual to match the actual syntax, I had to read the code, but I didn't really care about the particular language it was written in.

sindy (2018-10-19 19:53:39 +0000) edit

OK, sorry, I wasn't sure whether "I don't speak C++" meant "I'm familiar with C, but not with the much-more-complicated C++" or not.

Guy Harris (2018-10-20 07:38:30 +0000) edit

So it does find both the ip.addr fields (ip.src and ip.dst) and both udp.port fields but it has some problem with their size

What's the problem with their sizes? 34-36 means that the first byte of the field is byte 34 and the byte after the last byte of the field is 36, so it's bytes 34 and 35, which is two bytes - the right size for a UDP port number.

Guy Harris (2018-10-20 07:40:34 +0000) edit

add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer

Updating MATE config edit

Comments

2 Answers

Comments

Comments