The SOCKS dissector temporarily changes the pinfo values for destport
or srcport, so it should get the tcp_conversation_data after doing so
before recursively calling the TCP dissector again. Otherwise the TCP
dissector will be confused about whether a TCP multisegment PDU is in
progress or not, causing failure to lookup and store fragments correctly,
including both failed desegmentation and failed asserts (when it expects
an entry in the table which isn't there, as it was stored under a different
port number.) Fixes#16646.
In captures where a lot of packets are missing, requests and ACKs are
sometimes incorrectly paired. With this improvement, ACKs must arrive in
a reasonable time to be paired with a request.
A previous change initialized the k_connection_handle, so we don't
compare random data with remote_bdaddr->chandle, but perhaps we
shouldn't compare it at all if we didn't find a handle pair.
MSVC doesn't, by default, define __STDC_VERSION__, which means that the
code generated by newer versions of winflexbison3's Bison end up
defining YYPTRDIFF_T as long, which is wrong on 64-bit Windows, as
that's an LLP64 platform, not an LP64 platform, and causes warnings to
be generated. Those warnings turn into errors.
With MSVC, if __STDC_VERSION__ isn't defined, Forcibly include
<stdint.h> here to work around that.
Fixes#16924.
Bison 3.4 and later generate deprecation warnings for the "%pure-parser"
directive. As https://git.savannah.gnu.org/cgit/bison.git/tree/NEWS says,
----
** Deprecated features
The %pure-parser directive is deprecated in favor of '%define api.pure'
since Bison 2.3b (2008-05-27), but no warning was issued; there is one
now. Note that since Bison 2.7 you are strongly encouraged to use
'%define api.pure full' instead of '%define api.pure'.
----
Rename our .y files to .y.in, and modify FindYACC.cmake to detect newer
versions of Bison and configure our .y files with "%pure-parser" or
"%define api.pure" as needed. Squelches warnings from Bison in #16924.
The google.protobuf.Timestamp is a standard protobuf message type and
consists of seconds and nanos fields. We dissect protobuf field in
google.protobuf.Timestamp type as wireshark FT_ABSOLUTE_TIME field.
And add tvb_get_protobuf_field_uint() to make it easy to get a
Protobuf field of varint type from the tvb.
close#16927
The function to dissect CSuite Sel returns offset not number of
dissected bytes so calling function must assign new offset rather
than incrementing. For consistency also update the CSuite List
function to return offset.
Fix issues found by running ./tools/check_typed_item_calls.py
epan/dissectors/packet-eap.c:1475 proto_tree_add_item called for hf_eap_gpsk_failure_code - item type is FT_UINT16 but call has len 4
epan/dissectors/packet-eap.c:1479 proto_tree_add_item called for hf_eap_gpsk_failure_code - item type is FT_UINT16 but call has len 4
Speed functions to print hex bytes, escape XML strings and
print out indents by avoiding specifier calls, and building
larger strings before calling fputs().
Someone mentioned this in the sharkfest chat yesterday.
Also, Ostinato relies upon this when importing from pcap.
An example capture I have has gone from 18 to 11 seconds.
As noted in bug #16386, glib's `g_base64_decode_inplace()` aborts
decoding of base64 strings that aren't padded. This addresses that by
adding padding "=" characters if needed to the buffer which will be
decoded.
I added the test case from the bug report to the test suite, though the
location therein may not be ideal.
Closes#16386
Found by running ./tools/check_typed_item_calls.py
epan/dissectors/packet-ieee80211.c:14209 proto_tree_add_item called for hf_ieee80211_osen_akm_count - item type is FT_UINT8 but call has len 2
epan/dissectors/packet-ieee80211.c:20025 proto_tree_add_item called for hf_ieee80211_tclas_ether_type - item type is FT_UINT8 but call has len 2
Fix issues found by running ./tools/check_typed_item_calls.py
epan/dissectors/packet-gtp.c:4414 proto_tree_add_item called for hf_gtp_sel_mode - item type is FT_UINT8 but call has len 2
epan/dissectors/packet-gtp.c:6807 proto_tree_add_item called for hf_gtp_rai_rac - item type is FT_UINT8 but call has len 2
epan/dissectors/packet-gtp.c:7600 proto_tree_add_item called for hf_gtp_bssgp_cause - item type is FT_UINT8 but call has len 2
epan/dissectors/packet-gtpv2.c:3607 proto_tree_add_item called for hf_gtpv2_trace_id - item type is FT_UINT16 but call has len 3
epan/dissectors/packet-gtpv2.c:5049 proto_tree_add_item called for hf_gtpv2_trace_id - item type is FT_UINT16 but call has len 3
Make display_signed_time() take a 64-bit signed number of seconds, and,
in calls to it, cast the argument to gint64, not gint32.
Addresses issue #16909.
This unfortunately includes the name of the filter element but "sack" in TCP
should not mean "a packet with syn+ack set" to most networking people nowadays.
Added a dissector to reassemble IPP Over USB packets and pass them to
the HTTP dissector. Added a display filter so IPPUSB packets can be
filtered. Dissector checks to ensure semgent is IPPUSB and supports
reassembly of send-documents and print-job documents. It also supports
the reassembly and dissection of packets that are truncted or
incomplete.
Change-Id: Icc9525592c07b00baaac887a70bc9e7568273016
This commit introduces usbll states. These states
represent the transaction upto the current packet.
Uses of introducing usbll states:
1. Avoid condition checks upto last three packets.
2. Identify invalid PID sequences.
3. Identify correct transactions. This will help in
the USB 2.0 reassembly.
Ping-bug: 15908
Signed-off-by: Ameya Deshpande <ameyanrd@outlook.com>
Implement the Unicode Standard "best practices" for replacing ill-formed
sequences with the Unicode REPLACEMENT CHARACTER. Add wmem_strbuf_append_len
for appending strings with embedded null characters. Clarify why
wmem_strbuf_grow() doesn't always ensure that there's enough room for
a new string, and short-circuit some tests there. Related to #14948
- Rename some elements to their current RFC names
- Add an expert item for msg_len field
- Create an attribute for 8006 as unknown to avoid triggering the expert item for unknown attributes
packet-fbzero.c:348:47: error: ‘tag_len’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
Change-Id: I775edcae2bfdc6184267ee8d1873744a675e0fba
Under some conditions the trailer can be added after the FCS has already
been added. Advance 4 bytes and take a second look for a triler without
needing to resort to walking the trailer.
Whether over RTP or just UDP, it's possible to get multiple simultaneous MP2T
transport streams between the same pair of IPs but on different ports. They
will not be part of the same reassembly. Thus the reassembly table functions
that use ports as well should be used to avoid ressembly errors and overlaps.
In the heuristic function we don't know the length of the CID in the short
header, so we assume the worst case scenario compatible with packet length
(no more than 20 bytes)
There's a check for adding a zero length fragment to a reassembly in progress,
but it accidentally checks fd_head->tvb_data (the reassembly in progress)
instead of fd_i->tvb_data (the new fragment) before calling tvb_get_data() on
fd_i->tvb_data. (Note that data / fd_head->tvb_data is created based on the
sum of the lengths of all the fd_i->tvb_data, so the former can only be NULL
if all the latter are, but it's possible for one fragment to be zero length
but not the entire reassembly. Thus this is the necessary and sufficient check.)
Fixes#15569
Request-response tracking of STUN messages encapsulated in CLASSIC-STUN
packets (via DATA attribute) doesn't work right now.
The reason for this is that req-resp tracking is usually performed on
first-pass, but CLASSIC-STUN attributes are not dissected on first-pass
(on wireshark, at least). So the encapsulated STUN messages are never
elaborated on first pass, either.
Add Ethertype for Cisco ACI ARP gleaning and dissect its payload
Improve some Cisco ACI vendor specific DHCP options
Update mcp after looking at knet_parser.py
Update lldp after looking at knet_parser.py
Also reorder some ETHERTYPEs by value
Add a check for valid CoAP info in dissect_thread_coap() before use.
It may happen that this is NULL because setting a decode_as rule
for application/octet-stream will also catch other packets.
The Diameter type Address hase a two byte address type family field
previously only IPv4 and IPv6 was handled. Add handling of E.164 when
encoded as a string.
It is called as a protocol by GTP as before, but making it separate
and findable by name protocol allows for that layer to be logged and
dissected separately.
With the current return parameter of dissect_hs20_osu_provider() function, the dissector only show the first
osu_provider of the list. Changing the return end by return offset, the
dissector show all osu_provider of the list.
Exablaze and Metamako ethernet trailer dissector heuristics are not
specific enough to limit the data they comsume and identiy as the
respective trailers. Disable by default.
Fixes: #16898
Update some field names and capitalization in the IPv4, IPv6, ICMPv4,
and TCP dissectors to match the names documented in their respective
RFCs. This is in no way comprehensive, but it ensures that the packet
diagram more closely matches the RFC diagrams for those protocols.
(I haven't found a document that explitly says so, but protocol field
names in IETF RFCs seem to follow Chicago Manual of Style capitalization
recommendations in section 3.4 of the RFC Style Guide[1] for the most
part.)
[1]https://tools.ietf.org/html/rfc7322#section-3.4
According to 3GPP TS 48.006, section 9.3.2, Data Link Connection
Identifier (DLCI) is coded as follows:
.... .SSS - SAPI value used on the radio link;
CC.. .... - control channel identification:
00.. .... - indicates that the control channel is not further specified,
10.. .... - represents the FACCH or the SDCCH,
11.. .... - represents the SACCH,
other values are reserved.
The following values in value_string 'bssap_cc_values':
{ 0x80, "FACCH or SDCCH" },
{ 0xc0, "SACCH" },
are valid before applying CC_MASK (0xc0) mask, but not after.
Commit 3a5d0569d7 added support for different STUN protocol versions;
a global preference allows the user to select the desired flavour.
Unfortunately, it is pretty common to have different flavours in the same
capture file, or even in the same packet (with STUN messages encapsulated
in a TURN tunnel), so a global preference applied to the entire file might
not provide enough flexibility.
Add a basic auto-detect algorithm to identify the STUN version specific to
each STUN message (the users will still have the option to force a global
version)
New dissector for MC-NMF (.NET Message Framing Protocol) and
MS-NNS (.NET NegotiateStream Protocol).
TLS implementation is not tested due to the lack of a sample capture.
Fixes: wireshark/wireshark#16861
parse_CCategSpec was incorrectly always parsing the CRangeCategSpec
record, this record however is optional depending on the value of
CategType. (see MS-WSP 2.2.1.21)
Signed-off-by: Noel Power <noel.power@suse.com>
Since draft-ietf-quic-tls-17, QUIC uses TLS 1.3 base secrets for
decryption, so no separate key label is necessary. Applications should
not generate such non-standard key log entries. quiche has already been
updated, picoquic will presumably follow soon if it has not already.
Check the tag end offset - the offset in the packet of the tag's value's
end - to make sure that 1) it's at or after the offset of the
*beginning* of the tag's value and 2) that it's not past the end of the
packet; in either case, report an error with an expert info, and do not
show the value of that tag or any subsequent tags, as we don't have a
valid value for the length of this tag's value or even the *offset* of
subsequent tags' values.
For tags whose values have a fixed length, report an error, with an
expert info, if the tag value length isn't the expected value, and don't
dissect it.
For tags whose values have a minimum length, report an error, with an
expert value, if the tag value length isn't at least the minimum value,
and don't dissect it.
For tags whose values consist of a sequence of zero or more fixed-length
items, report an error, with an expert value, if there's leftover data
after processing those items.
Add some comments while we're at it.
These appear to be copy/paste errors detected by running
./tools/check_typed_item_calls.py --consecutive
Quite a few issues still remain after this batch.
Add ui/urls.h to define some URLs on various of our websites. Use the
GitLab URL for the wiki. Add a macro to generate wiki URLs.
Update wiki URLs in comments etc.
Use the #defined URL for the docs page in
WelcomePage::on_helpLabel_clicked; that removes the last user of
topic_online_url(), so get rid of it and swallow it up into
topic_action_url().
The condition aimed to avoid interpreting padding bytes after the
Initial Packet as Short Header to avoid breaking decryption. However it
also prevents actual Short Header packets from being matched that have
the QUIC bit cleared.
To avoid breaking the latter, strengthen the condition to match the
former only. Tested with quic-31_grease_quic_bit__with_keys.pcapng (from
!429). Regression tested against a private Firefox Nightly trace.
MAX_UNCOMPRESSED_SIZE is currently 16MiB.
Fix Coverity report CID 1467509: Insecure data
handling (TAINTED_SCALAR) Using tainted variable "times" as a loop
boundary.
If we did not find an msp that matched the current segment we would
try to find the msp for set-1 instead. This will only work IFF
we do not know the the exact size of the PDU and where it ends,
i.e. DESEGMENT_ONE_MORE_SEGMENT and friends.
In the case where "get msp for seq-1" gives us an msp where we know the exact
PDU boundary and the current seq is beyond the end of that boundary, then
we should not use the msp for seq-1 but instead treat this as a brand new PDU.
This fixes issues with SMB2-over-QUIC dissection that can be seen in the
sample capture for the "add smb2-over-quic" bug where only the first
multi-segment PDU would be dissected correctly for each direction.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Add an encoding for "unpacked" 3GPP TS 23.038 7-bit strings, in which
each code position is in a byte of its own, rather than with the code
positions packed into 7 bits. Rename the packed encoding to explicitly
indicate that it's packed.
Add an encoding for ETSI TS 102 221 Annex A strings.
Use the new encodings.
These were detected by running check_typed_item_calls.py
with --consecutive, which flags items that have different
labels but the same filter string. Usually this is because
of copy/paste.
Quite a few similar bugs still exist, will address in a future commit.
Simple decompression algorithm that encodes a single byte and the
number of times it is repeated.
This algorithm can only be used in chained compression packets.
The compression header "reserved" field is now a flags field.
If the flags have the CHAINED bit, the meaning of the offset field
changes and becomes a length field.
"old" compressed method:
[COMPRESS_TRANSFORM_HEADER with Flags=0]
[OPTIONAL UNCOMPRESSED DATA]
[COMPRESSED DATA]
new "chained" compressed method:
[fist 8 bytes of COMPRESS_TRANSFORM_HEADER with Flags=CHAINED]
[ sequence of
[ COMPRESSION_PAYLOAD_HEADER ]
[ COMPRESSED PAYLOAD ]
Implements [1]. Some code was intentionally simplified from the previous draft
implementation, pending some real-world motivation.
[1]https://datatracker.ietf.org/doc/rfc8754/
Until now, mistakenly, the buffer for decompressing compressed BLIP messages
has been statically allocated as 16 Kb, but that is not valid behavior.
16 Kb is the maximum size of a _compressed_ frame. In theory, due to the
ability to zipbomb, there is virtually no upper bound on what the maximum
size of an uncompressed frame could be. However, to keep sanity, it has
been made into a preference with a reasonable default that is not likely to
be exceeded (64 Kb). The behavior before for this was that wireshark would
crash because the dissector would return NULL for a decompressed buffer due
to error and then try to deference it later. A null check has been added,
so that the behavior is now that the packet will show
'<Error decompressing message>' instead, and log why it couldn't handle the
compressed message. Closes#16866.
In requests:
There appear to be 2 bytes of unknown data (typically 0) after the
2-byte Request Flags field (are they just 2 bytes of additional flags?).
Skip past them before dissecting the iterator.
If there are no bytes remaining in the packet after the parent ID, stop
dissecting; some packets seem to stop there. For those requests, assume
that the response will contain :
entry ID;
entry flags;
subordinate count;
modification time;
base class;
relative distinguished name;
although the last of those might be something else (it appears to be of
the form "CN={name}").
In replies:
For each returned entry, if the requested field flags in the request had
the DSI_OUTPUT_FIELDS bit set, fetch the returned field flags and use
that to determine what fields are present; otherwise, use the requested
field flags.
In dissect_nds_request():
Fill in fieds of the ncp_record structure only on the first pass; once
the first pass is complete, the structure's fully filled in.
That fixes cases where NDS replies aren't fully dissected because the
NDS verb isn't added to the ncp_record structure when the request is
dissected.
Fill in elements as soon as we have the value needed to fill it in, so
that it's filled in even if we throw an exception later, and so that
it's filled in only if we have the value in the packet, so that a valid
value isn't overwritten by a later packet that doesn't have the value.
This fixes cases where, in the second pass, NDS replies aren't fully
dissected because the NDS verb is overwritten in the ncp_record
structure when a continuation of the request is dissected.
Note that we should perhaps make the object_name field a pointer to a
wmem-allocated string, so that NULL can indicate "not set, hence not
known".
Following changes in the file:
1. Explain usbll_address_t and usbll_data_t.
2. Grouping header fields belonging to the same type of packets.
3. Removed unnecessary condition check for usbll_data pointer
in dissect_usbll_data function.
4. Brief comments on the Macros.
5. Correct code indentation at a few places.
Signed-off-by: Ameya Deshpande <ameyanrd@outlook.com>
Use the DSI_ defines, rather than the raw hex values for bits, to make
it clearer what's being tested.
Make all of the DSI_ #defines, rather than just some of them, unsigned.
Playing with the sample capture from bugzilla bug 10562, dissection of
packet 491 (ecmp file_info request) brought up an expert info about a
malformed packet.
The request contains a list of requested attributes. For each attribute,
only the attribute ID is part of the request. The current code tries to
dissect each attribute, this fails when we only have a list of
attribute IDs...
Add a subtree for the list of IDs (and the length of that list).
While at it, remove some unnecessary variable initializers.
Commit 873d5980cd improved STUN heuristic to match TURN ChannelData messages.
It was based on the assumption that, looking at the "stun.type.method" field,
it should be trivial to determine if the current packet carries a TURN message
or not. However, at least one STUN/TURN implementation (Facetime) uses
unknown/custom TURN methods to set up a Channel Data. Fortunately, standard
TURN attributes are still used in the replies.
Improve such heuristic taking into account specific TURN attributes, too.
The list attributes have been taken from RFC5766.
Stream Specification: https://www.ilda.com/resources/StandardsDocs/ILDA_IDN-Stream_rev001.pdf
The stream specification only defines IDN messages. The other packet commands
like ping request, ping response, etc. (see line 25 - 31 in packet-idn.c)
are part of the hello specification which is not released yet. We were still
able to implement some hello packets since we received a preliminary version
of the hello specification, because we need the hello packets for our work.
related to #16707
Stream Specification: https://www.ilda.com/resources/StandardsDocs/ILDA_IDN-Stream_rev001.pdf
The stream specification only defines IDN messages. The other packet commands
like ping request, ping response, etc. (see line 25 - 31 in packet-idn.c)
are part of the hello specification which is not released yet. We were still
able to implement some hello packets since we received a preliminary version
of the hello specification, because we need the hello packets for our work.
related to #16707
This adds a protocol post-dissector for Community ID support to
Wireshark/tshark: https://github.com/corelight/community-id-spec
The protocol is disabled by default. It establishes one new filter
value, "communityid".
Includes test cases and baselines to verify correct Community ID
strings based on similar testsuites in the existing Zeek and Python
implementations.
Define a bew type name type-name="OctetStringOrUTF8" type-parent="OctetString"
to be used with OctetStrings that CAN be strings. This is a Wireshark
unique addition to the xml dixtionarys and makes use of BASE_SHOW_ASCII_PRINTABLE.
If a time field uses a standard enconding, we can call proto_tree_add_item()
to add it to the tree. There's no need to parse the time field ourselves.
Update two places in the afs dissector where the manual parsing can
easily be replaced with a proto_tree_add_item() call.
Remove the old posix_v1 code which no clients ever implemented and add
code to dissect current version of the POSIX extensions as implemented
by the Linux kernel client (cifs.ko).
Pass the value of the NDS class definition type to process_multivalues()
as the vflags, rather than the NDS flags, as that's what the
MVTYPE_CLASS_NAMES case in process_multivalues() is expecting.
That way, the class definitions will be dissected correctly.
Even if Q046 is an old version, it is still used by the current QUICHE
implementation.
In this way, the latest Wireshark is able to dissect all GQUIC versions
supported by recent Chrome (Q043,46,50 and T050,51), i.e. all GQUIC versions
that you can find in live traffic right now.
Pcap examples are available in #15984 and in the attachment.
Some Q046 information are available in:
https://docs.google.com/document/d/1FcpCJGTDEMblAs-Bm5TYuqhHyUqeWpqrItw2vkMFsdY/edit#heading=h.32qkkficm7zaClose#15984
FT_STRINGZPAD is for null-*padded* strings, where the field is in an
area of specified length, and, if the string is shorter than that
length, all bytes past the end of the string are NULs.
FT_STRINGZTRUNC is for null-*truncated* strings, where the field is in
an area of specified length and, if the string is shorter than that
length, there's a null character (which might be more than one byte, for
UCS-2, UTF-16, or UTF-32), and anything after that is not guaranteed to
have any particular value.
Use IS_FT_STRING() in some places rather than enumerating all the string
types, so that those places get automatically changed if the set of
string types changes.
In process_multivalues(), we create a protocol item for the attribute
syntax, but we don't fetch its value, and don't pass it to
print_nds_values() as the syntax argument; instead, we pass a variable
that wee initialize to 0, but never set. (One of the disadvantages of
preemptively initializing local variables is that data flow analyzers in
compilers and static analyzers can't point out that you didn't set the
variables in question to *useful* values.)
This fixes the dissection of NDS Read replies.
This field is actually a bitmask of four bits. It's somewhat odd
to decode it using a value_string. In any case, the values were
plain wrong (shifted to the left by '1').
See Figure A.3 of ITU-T Q.933
A related pcap file can be found at
https://people.osmocom.org/laforge/pcap/gsmtap-fr-q933-pvc_status.pcap
The mask applied to the final octet of the PVC Status IE must be 0x0E,
not 0x0A. The current code masks out the active bit, printing a '.'
instead of it.
See Figure A.3 of ITU-T Q.933
A related pcap file can be found at
https://people.osmocom.org/laforge/pcap/gsmtap-fr-q933-pvc_status.pcapc
FCNO Improve field display
FOPA Improve field display
FCMI Support new structure
GMO Support version 4
LPOO Improve field display
ID Initial Data Improve field display
PMO Improve QName display in COL_INFO
CONN Improve field display
To quote the GenDC 1.1 specification, section 2.2.2 "GenDC Container
Header Description":
Unique signature identifying a GenDC Container: a FourCC code
encoded as 4 ASCII characters not null terminated ...
so it's FT_STRING, not FT_STRINGZ.
Give the URL for a page pointing to all GenICam standards, including the
GenDC standards, version 1.0 and 1.1.
According to the Novell IPX Router Specification, Chapter 4 "Service
Advertising Protocol (SAP)":
Server Name
This field contains the 48 byte character string name that is
assigned to a server. The Server Name, in combination with the
Service Type, uniquely identifies a server on an internetwork.
Although SAP response packets always include the full 48 bytes
for this field, typical server names are usually less than 48
characters long and are ASCII NULL terminated. The contents of
the unused bytes which follow the NULL terminator are undefined.
which seems to indicate that a full 48-byte name will not have a null
termintor. It also indicates that the field isn't null-padded, just
"null-terminated if it's not terminated by the end of the field's fixed
length"; perhaps we need to distinguish between the former and the
latter, although it's not clear what would be a good short name for the
latter.
In any case, it sounds as if it's not guaranteed to be null-terminated.
As per IEEE Std 802.1Q-2016, section 13.8 "MST Configuration Identifier
(MCID)",
The Configuration Name, a variable length text string encoded
within a fixed field of 32 octets, conforming to IETF RFC 2271's
definition of SnmpAdminString. If the Configuration Name is
less than 32 characters, the text string should be terminated by
the NUL character, with the remainder of the 32-octet field
filled with NUL characters. Otherwise, the text string is
encoded with no terminating NUL character.
so it's not FT_STRINGZ, it's FT_STRINGZPAD.
This applies to other configuration names as well.
The Aeron specification says nothing about it being null-terminated, and
in at least some captures, it's not null terminated.
Make it an FT_STRING, rather than an FT_STRINGZ.
Clean up a comment so that more of the URL is visible in a narrower
window.
MariaDB and MySQL are not longer drop-in compatible, they differ in very
different directions
for protocol and api. This patch contains support for MariaDB specific
commands and extensions:
- MariaDB specific character sets and collations (also updated MySQL
collations)
- MariaDB extended capabilities in greeting and login packets
- Support for MARIADB_STMT_BULK_EXECUTE command
- Removal of "5.5.5-" prefix in the version string.
These parameters are used by latest GQUIC versions.
Pcap examples are available in #16825
I noticed that gquic::dissect_gquic_tag() and gquic::dissect_gquic_tags()
don't really need the gquic_info parameter: remove it
Both osmocom and TTCN3 Titan are parsing Handover Request with an IPv6
Transport layer Address just fine, but wireshark was showing it as
malformed. Parsing the address similar to what is done in IPv4 fixes the
issue.
Remove the --check-addtext and --build flags. They were used for
checkAddTextCalls, which was removed in e2735ecfdd.
Add the sources in ui/qt except for qcustomplot.{cpp,h}. Fix issues in
main.cpp, rtp_audio_stream.cpp, and wireshark_zip_helper.cpp.
Rename "index"es in packet-usb-hid.c.
Done by scanning the asan1 template files. If there are spelling
mistakes in the specifications, we should ignore. Note that for z3950, I had
already found and accidentally fixed the same errors in the generated
file (before I taught my script to ignore gnerated dissector files).
In the T11 version of FCOE, the length field was removed. If the last
four reported bytes don't look like the EOF plus padding, but the four
bytes before that do, then the Ethernet FCS is almost surely present so
treat it that way. Closes the other case of #4594
Now that we're setting the C-language locale to use the UTF-8 code page,
they're already *in* UTF-8; g_locale_to_utf8() doesn't treat the
C-language locale's code page as the "locale" code page, it uses the
system code page, so it reads a UTF-8 string as being in some local code
page's encoding and proceeds to mangle it in the process of converting
it to UTF-8.
Closes#16811 (closed)
John Thacker
Vadim Yanitskiy
Harald Welte
Pau Espin