this is an ugly hack, as there is no code for packet re-assembly
in betwween, i.e. we only get proper dissection if the LLC message
was fitting entirely into one RLC block. Nevertheless, sufficient to
see things like RAU, ATTACH, IDENTITY procedures.
Change-Id: I1fc488aa58353e5f4264b940f9f4c18987148a7d
On truncated TLS records, just fail when attempting to decrypt or
calculate the handshake hash instead of raising an BoundsError.
The appropriate exception will be raised later when fields are
actually added to the tree.
This only makes a difference on the first pass, especially with
unencrypted initial handshake messages, as we don't try to decrypt
or calculate the hash on the second pass.
Fix#18896
This is a dissector for the GSM "Layer 2 Relay Character Oriented
Protocol" as used in non-transparent CSD (Circuit Switched Data)
calls in GSM and UMTS cellular networks.
This protocol is used in the user plane of non-transparent CSD (Circuit
Switched Data) calls in GSM networks. RLP frames are sent over the Um
air interface, and are sent as modified V.110 frames over 64k TDM
channels in the back-haul/core network. For modern implementations,
this means in RFC4040 RTP CLEARMODE.
As there's no V.110 decoder in wireshark, we cannot connect the RLP
decoder to that. However, we hook it up to the GSMTAP dissector to
enable other software to pass the decoded RLP frames into wireshark.
This changes the tree received by registered vendor dissectors (the
OUI isn't part of the dissected tree anymore). Thankfully there are
currently no dissector registered.
When right-clicking an item in the packet details and using "Colorize
with Filter", the colour may be applied using the wrong filter.
The code currently only updates the filter used for "Colorize with
Filter" if the packet details are visible and has focus. This is not
the case when you switch from one packet to another (at least by
clicking the other frame in the packet list).
The patch moves the emit of fieldFilterChanged() up to where the
filed_filter is identified. This seems the least intrusive.
Commit e921b804d0 removed the
user data parameter from logging, so remove it here.
Explain how the debugging defines work.
If DEBUG_DUMPCAP is defined and dumpcap is a capture child, don't send
logs to stderr with normal formatting, because that will be connected to
the sync pipe. Don't send them to stdout either, because that can be
connected to a data pipe (e.g., for retrieving interface information.)
Instead, send it to stderr with the special formatting so that the
parent recognizes it.
Use va_copy if both DEBUG_DUMPCAP and DEBUG_CHILD_DUMPCAP are defined,
avoiding undefined behavior that can lead to segfaults.
Set the log level to DEBUG when running as a capture child if the
DEBUG defines are set, because sync_pipe_start doesn't pass along
log level information. If you turned on the extra #define, you
presumably want to debug.
If logging to a file, open the file before any log messages.
Get rid of a check for the log level being below the default level.
It's either redundant of a check already done in ws_log_full, or it
prevents logs from being shown when dumpcap is run standalone with
logging options.
Fix the file name in the introductory comment.
Update a comment to note that a base64 value is handled, in some ways,
like a nested element, even though it's not nested in the way that an
object or array is.
Have json_dumper_bad() write current stack depth and the current and
previous types in, if possible, symbolic or numeric form; don't dump
other information. Also have it set JSON_DUMPER_FLAGS_ERROR, so no
other routine needs to do so.
Add routines to check for dumper stack overflow *and* underflow and
report them with appropriate messages, and use them in routines that
push onto or pop off of that stack, respectively.
This means that the stack depth won't overflow or underflow, so we can
make it unsigned (as it will never underflow below 0) and don't need to
check for negative or bigger-than-the-stack values.
Pull check out of json_dumper_check_state() into various existing or new
routines (for common code to call in those existing routines), and have
the error messages passed to json_dumper_bad() give a more detailed
explanation of the particular problem detected.
Check whether last received packet ended transfer on STALL only if there
was active transfer key set. This fixes failed transfer type assertion
for control transfers without data stage that were STALLed by device
(during status stage).
Set the "profile_filename" property on the special System Default
QAction in the CopyFromProfileButton so that the action will actually
do something when triggered.
Fix#13373
This adds the following KDEs defined by the Wi-SUN FAN specification:
- Pairwise Transient Key KDE (PTKID)
- Group Transient Key Liveness KDE (GTKL)
- Node Role KDE (NR)
- LFN Group Transient Key KDE (LGTK)
- LFN Group Transient Key Liveness KDE (LGTKL)
The Wi-SUN FAN specification describes the format of the EAPOL-Key frame
in section 6.5.2.2 (Authentication and PMK Installation Flow):
Descriptor Type = 2
Key Information:
1. Key Descriptor Version = 2
2. Key Type = 0
3. Install = 0
4. Key Ack = 0
5. Key MIC = 0
6. Secure = 0
7. Error = 0
8. Request = 1
9. Encrypted Key Data = 0
10. SMK Message = 0
11. Reserved = 0
Key Length = 0
Key Replay Counter = see [IEEE802.11] section 11.6.2.
Key Nonce = 0
EAPOL-Key IV = 0
Key RSC = 0
Key MIC = 0
Key Data Length = length of Key Data field in octets.
Key Data = PMKID KDE if the PMK is live, PTKID KDE if the PTK is live, GTKL
KDE, Node Role KDE, and LGTKL KDE.
The current dissector will try do decrypt if the Key Type is 0 while the
Encrypted Key Data is unset, which appears to be for supporting
non-standard WPA implementations. The Key Data is not encrypted in
Wi-SUN, so a workaround is made to dissect the Key Data if the Key
Length is 0.
Defined in the Wi-SUN FAN specification as:
id-kp-wisun-fan-device ::= {
iso(1)
identified-organization(3)
dod(6)
internet(1)
private(4)
enterprise(1)
Wi-SUN (45605)
FieldAreaNetwork(1)
}
Harald Welte
John Thacker