[bugzilla-daemon@xxxxxxxxxxxxx]

Bug ID	12184
Summary	MATE AVPL match modes "Loose" and "Every" do not work correctly
Product	Wireshark
Version	2.0.1
Hardware	x86
OS	Windows 7
Status	UNCONFIRMED
Severity	Major
Priority	Low
Component	Dissection engine (libwireshark)
Assignee	bugzilla-admin@wireshark.org
Reporter	sindelka@marconi.ttc.cz

Created attachment 14371 [details]
a sample capture of a SUBSCRIBE-initiated SIP dialog

Build Information:
Version 2.0.1 (v2.0.1-0-g59ea380 from master-2.0)

Copyright 1998-2015 Gerald Combs <gerald@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with Qt 5.3.2, with WinPcap (4_1_3), with libz 1.2.8, with
GLib 2.42.0, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,
with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale C, with
WinPcap version 4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version
1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2, without
AirPcap.
       Intel(R) Core(TM) i5-3210M CPU @ 2.50GHz (with SSE4.2), with 8141MB of
physical memory.


Built using Microsoft Visual C++ 12.0 build 31101
--
In the progress of making MATE Wiki more up to date, I've discovered that the
"Loose" and "Every" AVPL match modes work different from how they are described
on the Wiki. As the description makes sense while the actual behaviour does
not, I've concluded it was a bug rather than my misunderstanding of the
description.

An AVPL match normally returns two results: a logical value (succeeded/failed)
and an AVP list.

According to the Wiki:

"A loose match between AVPLs succeeds if at least one of the data AVPs matches
at least one of the configuration AVPs. Its result AVPL contains all the data
AVPs that matched."

The current reality is such that it reports success always, while the result
AVPL is populated correctly. To check that, I use

Match Loose (attr1=value1[,attr2=value2]) Replace (loose=1) ;

in a Transform{} invoked from a Pdu{}, so I can see the success/failure by the
presence/absence of "loose=1" among the PDU's attributes, and I can indirectly
see the result AVPL by what AVPs have been removed from the PDU's attributes
due to the execution of the Replace.

So the complete MATE config looks as follows:

Transform show_every {
    Match Every (method="OPTIONS",con_type) Replace (every=1);
};

Transform show_loose {
    Match Loose (rsp_code!100,con_type) Replace (loose=1);
};

Pdu sip_pdu Proto sip Transport ip {
    Extract call_id From sip.Call-ID;
    Extract method From sip.Method;
    Extract con_type From sip.Content-Type;
    Extract rsp_code From sip.Status-Code;
    Transform show_loose;
};

Gop sip On sip_pdu Match (call_id) {
    Start(method="SUBSCRIBE");
    Stop (method="NOTIFY");
};

Done;

If applied on the attached sample pcap, all PDU's AVPLs contain "loose=1". The
rsp_code is removed from all responses except the 100 Trying (correct) and the
con_type is removed from the NOTIFY (also correct). If I keep only
(rsp_code!100) in the match AVPL, the result is the same except that the
con_type is not removed (also correct).



"Every" behaves more ghostly, because its behaviour even depends on the order
of the AVPs in the match AVPL.

According to the Wiki:

"An 'every' match between AVPLs succeeds if none of the configuration's AVPs
that have a counterpart of the same name in the data AVPL fails to match. Its
result AVPL contains all the data AVPs that matched."

If we replace "Transform show_loose" by "Transform show_every" in the MATE
config given above, "every=1" is added to AVPLs of all messages except the
NOTIFY, as if the success would be (mis)declared whenever the data AVPL and the
configuration AVPL have no AVPs of the same name in common, while if they do,
another branch would be taken and the match would report a failure because only
one of the configuration AVPs has matched. However, if we change the order of
"method" and "con_type" elements in
Match Every (method="OPTIONS",con_type) Replace (every=1);
the "every=1" is added to all messages except the SUBSCRIBE, here I lack even
an idea how that could happen. On top of that, the "con_type" is removed from
NOTIFY's AVPL, but that's not surprising as I guess the result AVPL is always
built from the matching AVPs while evaluating the match.

If we change the match AVPL to plain (method="NOTIFY"), all messages' AVPLs
contain "every=1" and the method field is removed from the NOTIFY message.

The expected behaviour in both former cases is a match failure (making eventual
non-empty result AVPL insignificant as the failure prevents it from being used)
for all messages (i.e. "every=1" should not be added to any of them) and in the
latter case, match success only for the NOTIFY message, visualised as presence
of "every=1" and absence of "method=NOTIFY".

---

      You are receiving this mail because:

• You are watching all bug changes.