Wireshark-dev: Re: [Wireshark-dev] MATE, ip_addr and same source/est IP / loopback traffic
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@xxxxxxxxxxxx> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
