The optional Authorized UE-AMBR for Uplink and Downlink
fields in UE-AMBR were never getting dissected.
Also, the trees and tree description for the UE-AMBR and
APN-AMBR with NSAPI IEs were swapped.
When the ability to dispatch GSMTAP E1/T1 frames to the LAPD dissector
was merged in August 2020, a recent July 2020 change earlier has
restructured and renamed the lapd dissector. So at the time the GSMTAP
support for LAPD was added, the dissector was no longer called 'lapd'
and hence it never worked.
commit 75c739e4b7
Author: Guy Harris <gharris@sonic.net>
Date: Sat Jul 25 02:20:10 2020 -0700
ISDN, LAPD: clean up the way they connect to other dissectors.
commit 132d6ec70b
Author: Harald Welte <laforge@osmocom.org>
Date: Thu Aug 20 19:11:58 2020 +0200
Let's fix this by properly dispatching the LAPD frames from GSMTAP.
Change anything that matches
grep -Eir '(signal|slot) *\( *on_action' ui
to new-style connections so that we can catch any future direct
connection conversion issues at compile time.
Change a connection from on_actionCaptureOptions_triggered to
showCaptureOptionsDialog and make showCaptureOptionsDialog public. Fixes
an issue introduced in fcdb77dc.
wmem_strbuf_grow should set the correct size with regard to max_size,
if set. In any case passing the actual free "raw" size to g_strlcpy is
always the correct thing to do.
Use length and size consistently. strbuf->len does not
include the terminating nul. strbuf->alloc_len includes
the terminating nul.
Use consistent language and use "length" to mean size without
nul byte and "size" to mean size with all bytes, including nul.
Some older dissectors that predate Unicode and parse text protocols
are prone to generate invalid UTF-8 strings. This is a bug and can have
safety implications.
For example passing invalid UTF-8 to proto_tree_add_string() is a
common bug. There are safeguards in format_text() but this should
not be relied on as a general solution to the problem.
For one, as the name implies, it is only used with representation of a
field value, which is not the same as the value itself of an FT_STRING field.
Issue #18317 shows another reason why.
For now this compile flag only enables extra checks for string ftypes,
which covers a subset of proto.h APIs including
proto_tree_append_string(). Later is should be extended to other
interfaces.
This is also not expected to be disabled for release builds because
there are still many dissectors that do not correctly handle strings.
More work is needed to 1) identify them and 2) fix them.
Ping #18317
The remote-capture-command option does not work when selecting
remote capture command selection 'other' from the extcap capture
options dialog. Fix strcmp statement to actually check for 'other'.
Fixes: #18381
Osmux protocol [1] has historically been used as a replacement of RTP in
the SCCPLite or AoIP interfaces over satellite links, since usually the
satellite link is placed between the BSS (BSC) and the CN (MSC.
However, some network operators found need for Osmux in the Abis
interface, that is, between BTS and BSC. Hence, an Osmocom extension IE
"Osmux CID" was added to the IPAC CRCX/MDCX ip.access Abis
implementation, which is understood by osmo-bts and osmo-bsc. This new
extension IE is similar to the already existing extension IE in the
BSSMAP protocol spoken in AoIP (see BE_OSMOCOM_OSMUX_CID in wireshark
code).
More information on how this IE is used can be found in OsmoBTs and
OsmoBSC user manuals [2][3] (search for "Osmux" keyword).
This patch adds the new IE to the RSL dissector and avoids informing the
RTP subsystem to follow this conversation if the IE is found, since
marking it as an RTP conversation overrides the default or user
configured osmux dissector (UDO port 1984).
[1] https://ftp.osmocom.org/docs/latest/osmux-reference.pdf
[2] https://ftp.osmocom.org/docs/latest/osmobts-usermanual.pdf
[3] https://ftp.osmocom.org/docs/latest/osmobsc-usermanual.pdf
SMB can have two types of string encodings: Little Endian UTF-16, and
Extended ASCII OEM code page (DOS code pages, like CP 437, 850, 866, etc.)
The strings can either have an exact length, or be null terminated
inside a larger buffer that may contain other fields.
Currently the dissector returns strings in the original encoding for
the Extended ASCII strings, and returns ISO-8859-1 strings, not UTF-8,
for Unicode strings. Neither are correctly handled internally when non
ASCII values are used.
We should always produce UTF-8 strings for internal use.
For the OEM strings, we can't tell what code page it is, so use ENC_ASCII
to be safe. (A preference could be added here and in packet-smb-browser.c for
the default code page.)
For the UTF-16 strings, also produce UTF-8. Continue to handle an odd
case where some Windows 2000 servers terminated UTF-16 strings with only
a single NUL and then provided an odd byte count of the string length
plus the one NUL byte.
Fix#18369
MS-CIFS indicates that the deprecated commands SMB_COM_SEARCH (0x81),
SMB_COM_FIND (0x82), and SMB_COM_FIND_UNIQUE (0x83) never use
Unicode, and "names are returned in the extended ASCII (OEM)
character set only." That makes sense, as the size in the return
is listed as a fixed 13 bytes. Honor that.
RFCs 9110 5.5 is explicit about allowed characters in field values:
"Specification for newly defined fields SHOULD limit their values
to visible US-ASCII octets (VCHAR), SP, and HTAB. A recipient SHOULD
treat other allowed octets in field content (i.e., obs-text [%x80-FF])
as opaque data... Field values containing CR, LF, or NUL characters
are invalid and dangerous."
Up to RFC 7230, an obsolete "line-folding" mechanism that included
CRLF was allowed.
So NUL is not allowed, and all the known fields we support only allow
ASCII, so for display purposes it is permissible to retrieve the
value as ASCII. tvb_get_string_enc with ENC_ASCII does actually
retrieve a buffer of the full length with internal NULs if they
are in the buffer, but other functions end up truncating the value
at the first null if it exists. We should eventually have expert infos
that flag internal NULs or other invalid values with varying degrees of
severity, and display unknown header types with invalid values as
something like FT_BYTES with BASE_SHOW_ASCII_PRINTABLE.
Continue, for now, to pass along the raw value in the header_value_map
in case some dissector was using that value.
Fix#18368.
John Thacker
Harald Welte
Pau Espin