Also, take a chance to correct the comment: section 6.11.0 does
not exit in 3GPP TS 44.018. In version 15.4.0 Release 15 of
the referenced document it is 10.5.2.31 (table 10.5.2.31.1).
Corretly decode MNC if it consists of 3 digits
Change to what is called big endinan MNC
8 7 6 5 4 3 2 1
+---+---+---+---+---+---+---+---+
| MCC digit 2 | MCC digit 1 | octet x
+---------------+---------------+
| Filler | MCC digit 3 | octet x+1
+---------------+---------------+
| MNC digit 2 | MNC digit 1 | octet x+2
+---------------+---------------+
MNC of length 3:
8 7 6 5 4 3 2 1
+---+---+---+---+---+---+---+---+
| MCC digit 2 | MCC digit 1 | octet x
+---------------+---------------+
| MNC digit 1 | MCC digit 3 | octet x+1
+---------------+---------------+
| MNC digit 3 | MNC digit 2 | octet x+2
+---------------+---------------+
From 3GPP TS 29.171
7.4.27 PLMN Identity
- digits 0 to 9, encoded 0000 to 1001,
- 1111 used as filler digit, two digits per octet,
- bits 4 to 1 of octet n encoding digit 2n-1
- bits 8 to 5 of octet n encoding digit 2n
The Selected PLMN identity consists of 3 digits from MCC followed by either
- a filler digit plus 2 digits from MNC (in case of 2 digit MNC) or
- 3 digits from MNC (in case of a 3 digit MNC).
Creating protocols with unknown length must be created to the end of the TVB
first and reined back using proto_set_len() once the length becomes known.
Not doing so can make indentification of problems harder and prevents analysis
engines like MATE from properly processing the generated protocol trees.
With this change the remaining offending dissectors are corrected for this.
Closes#16961
In IEEE1905.1, everything is encoded in network byte order (big endian).
However, the dissector has a lot of ENC_LITTLE_ENDIAN. Change these into
ENC_BIG_ENDIAN.
The IPv4 Type TLV is not changed in this commit, since I'm not able to
test that TLV with an actual IEEE1905.1a implementation.
Many other fields are currently encoded as ENC_NA put should probably be
ENC_BIG_ENDIAN as well. However, they seem to work with ENC_NA, so they
are also not changed.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Don't try to dissect bytes as string and show its value item if the
bytes field has a subdissector. And add field subdissector under field
item instead of value item.
close#16956
The TECMP vendor data format for the Status Capture Module message has
support for two temperatures (chassis and silicon). This patch allows
dissection of those temperatures.
Systemd journal entries aren't file-type-specific; they're found in both
systemd journal entry blocks in pcapng files and in systemd journal
export files. Give it a record type, for use with both file types.
This fixes#16955.
It also means that you can open a systemd journal export file and save
it as a pcapng file.
The AT response may not contain a leading \r\n, so avoid checking
for this to determine if it's a response. This characters will be
removed as a part of white space removal anyway.
Start the limit at 2^32-1, as we use a guint32 to store the frame
number.
With Qt prior to Qt 6, lower the limit to 53 million packets; this
should fix issue #16908.
This reverts commit 5df2925434.
The problem only showed up in tfshark.c, and was caused by tfshark.c
using stuff from ui/urls.h but not *including* ui/urls.h.
Normal DNS response times are in the milli-seconds range, but are currently
listed as seconds.
It is more readable when msec unit is used instead.
Also the average display is hard coded (%.2f) so under normal conditions it
is currently shown as "0.00".
With this change the average value displayed is more useful and high response
times (retransmissions) stand out more clearly.
If you use it, GCC 9.3.0 seems to think there's a missing parenthesis
somewhere, just as the version of clang++ in my version of Xcode does,
even though other versions of GCC don't. I'm clearly missing something
obscure about C here; I give up.
1) Allow AVP_DEBUGGING settings to be made from Preferences, iff compiled so.
2) Flush MATE/AVP debug output once sequential packet parse has completed.
While running a test suite of a DNS server, a lot of DNS messages on
non-standard ports were not recognized. Rather than manually discovering
and decoding every port using an iterative process of checking the
output of the `udp and not dns` filter, have some heuristics to detect
DNS messages automatically.
Enable these heuristics by default assuming that the checks are strong
enough, 8 bytes are essentially fixed to a low number of possibilities.
Should it cause issued, then the heuristics could be disabled (assuming
that non-standard DNS ports are uncommon) or strengthened.
The macOS installer works differently from the way it did when that
message was written (it's now a drag-install for Wireshark, with
separate installers for ChmodBPF and for files to add the Wireshark
binary directory to the default $PATH), and the macOS main screen now
offers a "click this to install" link, running the ChmodBPF installer,
if the user doesn't have permissions to capture. Update the message
to reflect that (although that's wrong if you directly run dumpcap or
run it via TShark - this needs to be cleaned up in some fashion).
Fix a capitalization error while we're at it.
In the code that generates the main screen message to which the dumpcap
message refers, add a comment saying that, if the main screen message
changes, dumpcap's message should also be updated.
Move the maximum number of tree items and maximum tree depth to
preferences instead of hardcoded values. Refer to issue #12584 for
an example VNC capture where real data exceeds the current limit.
Masaru Tsuchiyama
Vadim Yanitskiy