Problem decoding LAPB/X.25/FTAM after adding X.75 decoding
Summary
After adding X.75 decoding Wireshark fails to decode a capture containing LAPB/X.25/FTAM
Steps to reproduce
Try to decode the capture file at https://drive.google.com/file/d/1_oJ3QBJbmqjdRi4gy9Zfs6hQfRW25GId/view?usp=drive_link using the latest version of Wireshark. It does not recognize LAPB (and upper layers) and just shows the frames as X.75 Command and Responses
What is the current bug behavior?
Not much to add here. The behavior is the one explained in "Steps to Reproduce"
What is the expected correct behavior?
The expected behavior is the correct decode, as it was done with previous versions. We tried V4.0.12 and the FTAM decoding worked fine on this version. Please check frames 4023 to 4095 which contain a whole VC session (since the call is established until it is closed)
Sample capture file
Check "Steps to Reproduce"
Relevant logs and/or screenshots
None
Build information
Version 4.2.2 (v4.2.2-0-g40459284).
Compiled (64-bit) using Microsoft Visual Studio 2022 (VC++ 14.37, build 32822), with GLib 2.78.0, with Qt 6.5.3, with libpcap, with zlib 1.3.0, with PCRE2, with Lua 5.2.4 (with UfW patches), with GnuTLS 3.8.2 and PKCS #11 (closed) support, with Gcrypt 1.10.2-unknown, with Kerberos (MIT), with MaxMind, with nghttp2 1.57.0, with nghttp3 1.0.0, with brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.11.5, with libsmi 0.5.0, with QtMultimedia, with automatic updates using WinSparkle 0.8.0, with AirPcap, with Minizip, with binary plugins.
Running on 64-bit Windows 10 (22H2), build 19045, with Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz (with SSE4.2), with 16046 MB of physical memory, with GLib 2.78.0, with Qt 6.5.3, with Npcap version 1.78, based on libpcap version 1.10.4, with PCRE2 10.42 2022-12-11, with c-ares 1.19.0, with GnuTLS 3.8.2, with Gcrypt 1.10.2-unknown, with nghttp2 1.57.0, with nghttp3 1.0.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.5.2, without AirPcap, with light display mode, without HiDPI, with QPA plugin "windows", with LC_TYPE=English_United States.utf8, binary plugins supported.