Compiled (64-bit) with Qt 5.12.5, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with GLib 2.64.2, with zlib 1.2.11, with SMI 0.4.8, with c-ares
1.16.1, with Lua 5.2.4, with GnuTLS 3.6.13 and PKCS #11 support, with Gcrypt
1.8.5, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.40.0, with
brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.9.10, with
QtMultimedia, without automatic updates, with SpeexDSP (using system library),
with SBC, with SpanDSP, without bcg729.
Running on Linux 5.6.0-1-amd64, with Intel(R) Core(TM) i7-8665U CPU @ 1.90GHz
(with SSE4.2), with 7965 MB of physical memory, with locale en_US.UTF-8, with
light display mode, without HiDPI, with libpcap version 1.9.1 (with TPACKET_V3),
with GnuTLS 3.6.13, with Gcrypt 1.8.5, with brotli 1.0.7, with zlib 1.2.11,
binary plugins supported (18 loaded).
Built using gcc 9.3.0.
Greetings,
I would like to submit an enhancement to the L2TP dissector. Improvements:
Detection of cookie length is now also based on Cisco vendor-specific AVPs (before this patch, the cookie length was only detected based on IETF AVP type 65; if the cookie was advertised in Cisco vendor-specific AVP, it was not autodetected)
Storing session IDs and pseudowire type data is now also based on Cisco vendor-specific AVPs (before this patch, the SID and PW type detection have been only based on IETF AVPs; if the SID and PW type were advertised in Cisco vendor-specific AVPs, they were not stored as a session, and the L2TP data message payloads have not been dissected properly)
Fixed storing and looking up conversations for UDP-based L2TP encapsulation (before this patch, UDP-encapsulated data messages were possibly not dissected properly since their SIDs, PW type and cookies have not been looked up properly in Wireshark conversation->tunnel session cache)
Fixed occasional reports of "malformed packet" when dissecting ZLB messages
Changes to output formatting
Removed bogus whitespaces in output strings
Removed redundant printouts of the same value under l2tp_tree
Printing out 32-bit values of SIDs and CCIDs in hex for better readability
Corrected the use of "ccid" vs. "tid" strings in labels
Properly accounting for the cookie length in the l2tp_item total length
Renamed the "Packet Type" ctrl_tree item into "Flags" which better corresponds to its contents
Providing quick summary for the set flag bits in the "Flags:" ctrl_tree
Removed l2tp.session_id key with the related hf_l2tp_session_id item since this item duplicated the already existing l2tp.sid/hf_l2tp_sid key/item but was only populated for IP-based L2TPv3 data messages which would produce inconsistent search/filter results
The UDP encapsulation conversation issue is the same issue as the TFTP dissector had, because the UDP port selection as detailed in RFC 3931 is that of TFTP:
The initiator of an L2TP control connection picks an
available source UDP port (which may or may not be 1701) and sends to
the desired destination address at port 1701. The recipient picks a
free port on its own system (which may or may not be 1701) and sends
its reply to the initiator's UDP port and address, setting its own
source port to the free port it found.
It has been suggested that having the recipient choose an arbitrary
source port (as opposed to using the destination port in the packet
initiating the control connection, i.e., 1701) may make it more
difficult for L2TP to traverse some NAT devices. Implementations
should consider the potential implication of this capability before
choosing an arbitrary source port. A NAT device that can pass TFTP
traffic with variant UDP ports should be able to pass L2TP UDP
traffic since both protocols employ similar policies with regard to
UDP port selection.
In practice, since L2TP is typically used where NAT is a consideration, symmetric ports are used and both sides use 1701 for the entire connection. This is different to TFTP, where using the assigned port is a fairly rare feature of some implementations (but useful for containers, etc.)
The nature of Wireshark conversations make it a little tricky to support both the switching ports method as well as the symmetric ports method, and the current implementation only really does the former, even though the latter is more common.