Wireshark-dev: [Wireshark-dev] MATE, ip_addr and same source/est IP / loopback traffic

From: Harald Welte <laforge@xxxxxxxxxxxx>
Date: Sat, 17 Oct 2020 17:09:43 +0200
Dear wireshark developers,

I'm a big fan of MATE, but I've run into a couple of problems that I've been
unable to resolve.  This mail is aabout the first problem:

It is customary to use 'Extract ip_addr From ip.adddr' in 'Pdu' definitions
in order to extract the source and destination IP addresses.  This can then
later be used in 'Gop' definitions like

	Gop rsl_lchan On rsl_pdu Match (ip_addr, ip_addr, port, port, ...)

In my experience, this works great for traffic that has different source and
destination IP addresses.  In this situation, MATE extracts the two IP addresses,
and the Pdu contains two related attributes.   That in turn allows two ip_addr
keys to be used like in the above-mentioned Gop example.

However, if the source IP address and destination IP address are identical
(such as most commonly seen by two local applications talking over loopback
with 127.0.0.1 on both ends), MATE is only adding a *single* ip_addr attribute
to the Pdu.

That in turn seems to be causing the 'Gop' definition no longer matching,
as it requires two ip_addr attributes :(  I can of course modify the Gop definition
to only uses ip_addr once, e.g. modify the above example to

	Gop rsl_lchan On rsl_pdu Match (ip_addr, port, port, ...)

And suddenly things will work.  But then they _only_ work for loopback traffic,
and not for other traffic with different source/dest IP addresses anymore.

I tried to add two Gop definitions, but then MATE also doesn't allow that,
apparently there can only be one Gop definition for each PDU, not multiple (alternative)
ones.

So my question is: How am I support to write the Pdu + Gop rule in a way to
work for both cases?

For a complete example, see the rsl_pdu and rsl_lchan definitions in
https://git.osmocom.org/wireshark-mate/tree/osmocom.mate
For tose MATE rules, you can find two pcap files attached; also two screenshots
from the working vs. non-working case.

[please ignore the wrong ip header checksum in the localhost example, i binary-patched
the loopback address in there to make sure the IP address is really the only difference
in those files]


Thanks in advance,
	Harald

p.s.: My tests were don with wireshark Version 3.3.0 (v3.3.0rc0-1701-g4bea0e7c2ebf),
but I've been seeing this problem in all my builds for at least 7 months now.

-- 
- Harald Welte <laforge@xxxxxxxxxxxx>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)

Attachment: rsl-nolocalhost.pcap
Description: application/vnd.tcpdump.pcap

Attachment: rsl-nolocalhost.png
Description: PNG image

Attachment: rsl-localhost.pcap
Description: application/vnd.tcpdump.pcap

Attachment: rsl-localhost.png
Description: PNG image