MATE stands for Meta Analysis and Tracing Engine. It is a Wireshark plugin that enables the user to define the relationships between various frames. To accomplish this, MATE collects data from the frames’ tree and then attempts to organize the frames by how MATE is set up. When the PDUs are connected, MATE will build a “protocol” tree with filterable fields. Since the fields are nearly identical for all connected frames, it is possible to filter a session that spans several frames and many protocols based on a property that appears in a related frame. In addition, MATE enables the filtering of frames depending on reaction timings, the amount of pdus in a group, and many other factors. The major goal of MATE is to use different protocols, and filter every packet of a call while only knowing the calling number. The other thing is using different protocols, filtering all packets from all calls based on the reason one of their “segments” was released. It also extends particularly “dense” captures to sluggish transactions (Finding asks for a timeout). It allows finding pending transactions (no responses). If there is any such requirement for rerouting of requests then it is carried out via additional gateways and proxies.
Examples of MATE Configuration:
The examples of different configurations for MATE are listed below. Since the “conversations” facility does a better job, many of them are useless. In any case, they are intended to aid users in understanding MATE configuration.
- TCP session: The example that follows turns each TCP session into a GoP.
Pdu tcp_pdu Proto tcp Transport ip {
Extract addr From ip.addr;
Extract port From tcp.port;
Extract tcp_start From tcp.flags.syn;
Extract tcp_stop From tcp.flags.reset;
Extract tcp_stop From tcp.flags.fin;
};
Gop tcp_ses On tcp_pdu Match (addr, addr, port, port) {
Start (tcp_start=1);
Stop (tcp_stop=1);
};
Done;In 99.9% of circumstances, this should work just fine, however, if they happen to overlap in time, 10.0.0.1:20–10.0.0.2:22 and 10.0.0.1:22–10.0.0.2:20 would both fall into the same GOP.
--When filtering with mate.tcp ses.Time > 1, all sessions lasting less than one second are returned. --When filtering with mate.tcp ses.NumOfPdus 5, all tcp sessions with fewer than five packets are displayed. --All the packets for the third TCP session MATE has discovered will be displayed if the filter is set to mate. tcp ses.Id == 3.
- Gog for a complete FTP session: With this configuration, a full passive FTP session—including data transfer—can be tied to a single Gog. Notably, this configuration creates one GOP for each FTP-data packet rather than for each transfer because there is nothing to discriminate between FTP data packets.
- Using RADIUS to filter SMTP traffic of a specific user: In many nations, spying on people is prohibited because it is immoral. When there is a legitimate cause, the police should handle this type of work. Radius packets and SMTP traffic for “the user” will be filtered if the capture file is filtered with the expression mate.user_mail.username == “theuser”.
- H323 Calls: With this setting, each call will result in a Gog. This allows us to:
--filter all signaling for a specific caller : mate.call.caller == "123456789" --filter all signaling for calls with a specific release cause: mate.call.q931_cause == 31 --filter all signaling for brief calls : mate.q931_leg.Time < 5
- MMS: In this, every element of an MMS transmit or receive will be connected to a single Gog. Because MMS distribution utilizes MMSE via either HTTP or WSP. A GOP is formed of HTTP Pdus, but MMSE data must be removed from the bodies because it is impossible to connect the retrieve request and answer using only MMSE (the request is simply an HTTP GET without any MMSE).