https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16787

            Bug ID: 16787
           Summary: Changing preferences via Decode As does not call
                    callback
           Product: Wireshark
           Version: Git
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: Normal
          Priority: Low
         Component: Qt UI
          Assignee: bugzilla-ad...@wireshark.org
          Reporter: johnthac...@gmail.com
  Target Milestone: ---

Build Information:
Wireshark 3.3.0 (v3.3.0rc0-1860-g952e46fb567c)

Copyright 1998-2020 Gerald Combs <ger...@wireshark.org> and contributors.
License GPLv2+: GNU GPL version 2 or later
<https://www.gnu.org/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.14.2, with libpcap, with POSIX capabilities
(Linux),
with libnl 3, with GLib 2.64.4, with zlib 1.2.11, with SMI 0.4.8, with c-ares
1.15.0, without Lua, with GnuTLS 3.6.14 and PKCS #11 support, with Gcrypt
1.8.5,
with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.41.0, with brotli,
with LZ4, with Zstandard, with Snappy, with libxml2 2.9.10, with QtMultimedia,
without automatic updates, with SpeexDSP (using system library).

Running on Linux 5.7.14-200.fc32.x86_64, with Intel(R) Core(TM) i5-4670K CPU @
3.40GHz (with SSE4.2), with 15944 MB of physical memory, with locale
en_US.utf8,
with libpcap version 1.9.1 (with TPACKET_V3), with GnuTLS 3.6.14, with Gcrypt
1.8.5, with brotli 1.0.7, with zlib 1.2.11, binary plugins supported (0
loaded).

Built using gcc 10.2.1 20200723 (Red Hat 10.2.1-1).
--
I've been looking at the TFTP dissector, seeing if the recent changes fixed bug
10305 and I noticed some oddities about preferences and decode as.

There's a few dissectors (HTTP, VNC, TFTP, etc.) that have patterns like this:
static void
apply_tftp_prefs(void) {
  global_tftp_port_range = prefs_get_range_value("tftp", "udp.port");
}

void
proto_register_tftp(void)
{
...tftp_module = prefs_register_protocol(proto_tftp, apply_tftp_prefs);
...}
void
proto_reg_handoff_tftp(void)
{
...
  dissector_add_uint_range_with_preference("udp.port", UDP_PORT_TFTP_RANGE,
tftp_handle);
  apply_tftp_prefs();
}

But when a new value is added or removed via the Decode As menu, that doesn't
call the callback. (Unlike when changing the preference directly.)
What makes matters worse is that if the range has a single value (such as is
the default in TFTP), it frees the existing range:
/* If range has single value, replace it */
if (((*pref->varp.range)->nranges == 1) &&
    ((*pref->varp.range)->ranges[0].low ==
(*pref->varp.range)->ranges[0].high)) {
    wmem_free(wmem_epan_scope(), *pref->varp.range);
    *pref->varp.range = range_empty(wmem_epan_scope());
}

and thus global_tftp_port_range now points to memory that has already been
freed. (This has somewhat unpredictable effects on the value_is_in_range()
call, but it seems to usually just return TRUE for all values when the range_t
is nonsense.
If the Decode As entries are saved to a file, then it does do the callback when
reading the preference when restarting Wireshark. It also does the callback if
the preference in changed in other ways, such as through
Edit->Preferences->Protocols->TFTP, changing the range, and then applying the
value without restarting.

>From what I can tell, DecodeAsModel::applyChanges() in
ui/qt/models/decode_as_model.cpp looks pretty similar to
read_set_decode_as_entries() in epan/decode_as.c, and using gdb confirms that
module->prefs_changed_flags is getting set to 1 in both instances.
However, the callback is never getting called in the case where Decode As is
changed, so the range_t has nonsense large negative values for nranges, etc.
The changed UDP port preference *does* take effect, and the TFTP dissector is
called, but because value_is_in_range doesn't work properly the conversation
setting code doesn't work properly, and the generated filenames and Export
Objects doesn't work.

-- 
You are receiving this mail because:
You are watching all bug changes.
___________________________________________________________________________
Sent via:    Wireshark-bugs mailing list <wireshark-bugs@wireshark.org>
Archives:    https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
             mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

Reply via email to