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

[Jaap Keuter <jaap.keuter@xxxxxxxxx>]

Hi,

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. 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. 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. 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 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. Not sure where the solution is for this problem.

Regards,
Jaap


> On 17 Oct 2020, at 17:09, Harald Welte <laforge@xxxxxxxxxxxx> wrote:
> 
> 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-localhost.pcap
Description: application/vnd.tcpdump.pcap

> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe