A nettrace 3gpp capture contains the 'beginTime' in ISO 8601 format.
This patch corrects the conversion for the following steps:
- the UTC offset must be subtracted from the given time,
- given time must be converted to UTC time when an offset is provided (localtime otherwise)
- sub-seconds conversion fixed (i.e. .0012 was converted to .12).
Closes#16888
Refer to USB Device Class Definition for Video Devices
document revision 1.5.
* bmFramingInfo is 1 byte
* Cut & Paste error for bMaxVersion label
Change-Id: Ib1221886f864a6ab9dbab70a8e5fca6482bf4267
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
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.