Wireshark mailing list archives
Re: MATE, ip_addr and same source/est IP / loopback traffic
From: Harald Welte <laforge () gnumonks org>
Date: Sat, 24 Oct 2020 18:52:45 +0200
Hi Jaap, On Fri, Oct 23, 2020 at 11:41:35AM +0200, Jaap Keuter wrote:
This is a tough one. Our resident MATE developer hasn’t been active for a while now, and so far no one has really picked it up.
That's a real pity. To me, MATE is the most interesting/important development in wireshark I can think of in the last decade. I unfortunately only recently discovered it. It's a step into the "right" direction, and significantly improves protocol analysis of telecom protocols.
I did a quick test (after getting debugging working again) and found that the protocol fields are added to an ‘Address-Value-Pair-List’ (AVPL) on basis of uniqueness.
yes, that's what I figured from the MATE documentation.
I can see why that is, but I also see that this gives problems like this. It goes for the IP address, as in this case, but also for the port numbers.
Both of which are rather common patterns for virtually any identifier in packets you would want to extract using MATE. It's not just IP address and port, but also any other similar identifier such as e.g. SS7 SSN (sub system number). Basically any identifier which acts as a key to de-multiplex between different entities at either side of the connection. This leads to rather ugly failure modes, where you look at a protocol trace and you get proper MATE decoding for some flows/gops, but then not for others, depending on their addresses/identifiers.
I wonder if it would be possible to box this in per packet instead of per field. It would require more study to see how to go about this.
I'm not following you, sorry.
I was briefly thinking about a workaround using ip.src and ip.dst instead of ip.addr, but then you end up with again a localhost specific Gop definition, e.g., Gop tcp_ses On tcp_pdu Match (srcaddr, dstaddr, port, port). That makes it unidirectional when you have different host addresses, so that probably won’t work either.
Nope, and as you stated it would actually explode because you need the same for port numbers and virtually any other identifier - and since those are nested you basically very quickly get to a relatively large power-of-two number of MATE rulesets you have to write and maintain. And then, when you filter, you want to match on one unique gop name no matter what particular addresses the given packets were using. I'll file a bug for this one, then too :/ -- - 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
Current thread:
- MATE, ip_addr and same source/est IP / loopback traffic Harald Welte (Oct 17)
- Re: MATE, ip_addr and same source/est IP / loopback traffic Jaap Keuter (Oct 23)
- Re: MATE, ip_addr and same source/est IP / loopback traffic Harald Welte (Oct 24)
- Re: MATE, ip_addr and same source/est IP / loopback traffic Jaap Keuter (Oct 23)