| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Change-Id: Iba8cbe09b14fcd0644cc3d09303eab1ef71fbca3
|
|
It seems that for some reason the asn2wrs.py code generator cannot deal
with ASN.1 choices being defined with their numeric values defined in
non-ascending order. Other ASN.1 code genreation tools work perfectly
fine under such conditions.
The decode error happens in the COL_INFO: The numeric value of the
choice is mapped to a wrong entry in the string table, resulting in
the wrong message type being shown in the INFO column.
We apply this patch to the ASN.1 source of the RSPRO protocol definition
to fix the decode.
|
|
The Osmocom RSPRO protocol is a protocol for remote SIM card access,
i.e. extending the SIM card interface between phone/mdoem (UE) and
a remote SIM card reader. The primary user of this protocol is
osmo-remsim software suite, which can be found at
https://osmocom.org/projects/osmo-remsim/wiki
RSPRO is specified in ASN.1 using BER and runs on top of the IPA
multiplex (protocol-gsm_ipa.c).
Change-Id: Ibcdb2c92281d05c36e3973de4d7ec4aa0cd9b207
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This feature was dropped between versions 1.1v00 and 1.1v01 of the
Wi-SUN FAN specification.
|
|
- The Voltage was not showing the unit V.
- The temperatures now use directly the base unit degree Celsius.
|
|
Fixes #18895.
|
|
|
|
References #18697
|
|
|
|
|
|
|
|
Removed the following functions as they are not needed anymore:
- masked_guint8_value
- tvb_get_guintX
|
|
Add the frame control flags string to a new field. This can be
used in a custom column, similar to TCP Flags.
|
|
|
|
The old SOME/IP Heur always returned true, even for non SOME/IP. This is
fixed now.
|
|
|
|
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).
|
|
|
|
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)
}
|
|
|
|
Was dropped in error in ccbc0d5fe9355177dd88b8e28551021da3d1ee2d
|
|
Pop up a dialog about bad coloring rules when reading the file
(e.g., when first starting Wireshark), rather than waiting until
you try to edit them.
Have that dialog have details of the problem with the filter
instead of a generic message. The report_warning code will
consolidate multiple warnings into one if more than one filter
has an error, rather than have lots of pop-ups.
Since the dialog (or console message, in the unlikely event that
somehow the colorfilters are read in a CLI tool) is called from
the color filters code, get rid of the separate non-specific
pop-up in ColoringRulesDialog and the special preference for
having a bogus filter.
Now, if the user has a bogus filter in the current profile's
colorfilter, they'll get a useful pop-up warning at startup,
when that filter is disabled. For filters imported / copied from
other profiles through the coloring rules dialog, they'll get the
same useful pop-up.
For trying to enable a disabled coloring rules with an error, or
inserting a *new* coloring rule with invalid filter expression (despite
the editor's Red background warning about an invalid expression),
there's already both the hint at the bottom of the screen and the
OK button becomes disabled. (Maybe the hint could be larger or
bold or something when there's an error.)
Fix #14906. Fix #15034
|
|
|
|
Tag number 221 (Microsoft WPA Information Element) contains an AKM type.
Save this to fix wlan decryption when this tag is used by Access Point.
|
|
This patch cleans up the offset and length handling to allow showing
unparsed bytes.
|
|
|
|
|
|
This was accidentally added in f4242568896a611cfc563c90b57a421ad2805f31
and is clearly incorrect: https://www.rfc-editor.org/rfc/rfc6143#section-7.7.3
Fix #18883
|
|
|
|
Related to #18878
|
|
|
|
A negative number of bits in a bit item isn't allowed. Treat it
as a very large number (i.e., as unsigned), and throw a
ReportedBoundsError. This was already happening in most cases,
but not in the edge case of a number of bits between -1 and -7
(which was being rounded up to 0 octets and passed our length checks.)
Fix #18877
|
