Includes DMG parameter, Spectrum management and Radio measurement
fields to DMG parameter whenever it is transmitted by a DMG STA/AP.
These fields were added in 802.11ad-2012 Spec.
Change-Id: I56356b804703251981772499534e029a324766df
Signed-off-by: Jambukumar Kulandaivel <jambukumar@codeaurora.org>
Reviewed-on: https://code.wireshark.org/review/36276
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Dissect the 60GHz information element which is part of the
WI-FI alliance (WFA) 60Ghz technical specification version 1.0.
Change-Id: Ib5a7f0e137a8ef11b389253026ee9fb1b54cdfa3
Signed-off-by: Jambukumar Kulandaivel <jambukumar@codeaurora.org>
Reviewed-on: https://code.wireshark.org/review/35975
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
My previous patch was broken and did not handle the new Anti-Clogging Token
container. It was broken because I did not realise that Table 9-42 specified
the order of elements in the SAE Fixed Field. Table 9-43 specifies when
elements will be in which type of SAE request. However, 9-42 specifies the
order.
This has been tested with captures from WFA and Jouni Malinen.
Change-Id: Icbaa53560036c421299c74867ec04d9a28ea8aa0
Reviewed-on: https://code.wireshark.org/review/36098
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The code was not properly corrected and a confirm result would show
a malformed packet because two bytes were not accounted for.
Change-Id: Ibc2f14ec46b0d63401d8d3b3768b032ed9b12e56
Reviewed-on: https://code.wireshark.org/review/36028
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
After feedback from the WFA and checking tables 9-3 and 9-6 in
IEEE802.11-2016 and testing this is more correct.
Change-Id: I26e65046610d887b2bcdac6caa8b4665eb2f6e20
Reviewed-on: https://code.wireshark.org/review/36018
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
With SAE there is a need to handle the anti-clogging token.
Tested with test cases from WFA.
Change-Id: I5bad92677481bc45b7bd10b526aa6a44c200ce17
Reviewed-on: https://code.wireshark.org/review/36019
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Change-Id: Ifcf041eb70bd68564d326b94868a45efab86a71f
Reviewed-on: https://code.wireshark.org/review/35568
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Guy Harris <guy@alum.mit.edu>
It's the responsibility of code that processes radio metadata (file
readers in libwiretap or dissectors in libwireshark) to set the PHY
correctly, even if it has to infer it from the frequency. The 802.11
dissector should just check the PHY.
Change-Id: Ie6aa73a062c7538cbe2e994fb6a6a2a1e9ac978d
Reviewed-on: https://code.wireshark.org/review/35533
Petri-Dish: Guy Harris <guy@alum.mit.edu>
Reviewed-by: Guy Harris <guy@alum.mit.edu>
This prevents the use of too high values when using the
shift operator.
Bug: 15632
Change-Id: Iba4156c3038ca3c6645e41650b716c2ab07d3e43
Reviewed-on: https://code.wireshark.org/review/35344
Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Change-Id: I4ef686f5dc9a43f94db34cab0f7fe466ef271585
Reviewed-on: https://code.wireshark.org/review/35482
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Compressed block acks, in the form of 256 bit bitmaps, are parsed
per 64 bit section. Scanning along a section needs to be done by
indexing this section, not the full 256 bits of the complete bitmap.
Change-Id: Id0e6a7299e14be1ad68dd1cf6d736123008854ac
Reviewed-on: https://code.wireshark.org/review/35440
Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl>
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
If the capture does not contain any indication of the Key MIC Len or we
are making only one pass (such as with tshark) we can actually figure
out the Key MIC Len if we see the first frame of the four-way handshake.
We only use this approach if we used the default value for the Key MIC Len
and defer to other information if it is available. We also save the value
once we have figured it out and only try to figure it out on the first
frame of the four-way handshake.
If we cannot determine the Key MIC length from the first frame in the
four-way handshake we can use the second frame in the four-way handshake.
However, we also need to keep some extra state, specifically, whether or not
we have actually set the last AKM suite seen.
Bug: 16210
Change-Id: I28bc7dacbd34d03b24e66371f66b22853fa608d1
Reviewed-on: https://code.wireshark.org/review/35119
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Mikael Kanstrup <mikael.kanstrup@sony.com>
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
The "Preferred AC" field in the "Trigger Dependent User Info"
subfield of the Basic Trigger frame uses the "ACI-to-AC encoding"
described in Table 9-136 of the 2016 IEEE 802.11 specification. The
802.11ax specification refers the reader to this table when describing
the "Preferred AC" field.
Change-Id: I81ca3280c2865bc87fc4a8ddb63b5e8f7255d414
Reviewed-on: https://code.wireshark.org/review/35190
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
With AKMS 00-0F-AC:12 a 384 bit long PMK shall be used. To be able
to support key derivation and decryption from this larger sized
PMK the user PSK / PMK key input validation code is updated as well
as the various places where a hard coded PMK size is used.
Ping-Bug: 16197
Change-Id: I39c9337e8a84095246e3db5ef33dc96fb78e5dc3
Reviewed-on: https://code.wireshark.org/review/35065
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Use AKM, cipher suite and group cipher suite from RSNA to determine
key lenghts and offsets. This allows keys of different lengths
for PTK derivation, MIC validation etc.
Ping-Bug: 16197
Change-Id: I9a721fb9811db89357218b50a2a107cf945d3dae
Reviewed-on: https://code.wireshark.org/review/35064
Reviewed-by: Anders Broman <a.broman58@gmail.com>
The ieee80211 dissector reuses the conversation concept to track
each association as one conversation. For this a simple counter
is incremented on each (re)assoc request frame.
There are two already existing hacky tricks for conversation lookup:
1. Each frame is marked with current assoc counter value
2. pinfo srcport and destport is then set to assoc counter value
With the above a conversation can then be looked up using the normal
conversation utility functions.
Though depending on the dissection flow a conflicting conversation can
be created eap dissector making the conversation lookup used for
function determine_mic_len return the one created by EAP dissector
instead with the effect that wrong mic length is returned.
Building further on this hack a way to solve this is to explictly
mark pinfo srcport destport whenever we're either creating or searching
for a "wlan conversation".
Uploading the patch to get some feedback on how this whole "wlan
conversation" thing can be properly solved. This error was discovered
when working on implementing support for bug 16197 where 24 byte long
MICs are used.
Change-Id: I7bd22cdf5d382a6c5f881ee29820f058d581a94e
Reviewed-on: https://code.wireshark.org/review/35050
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Simplify the still quite complex Dot11DecryptScanEapolForKeys function
and further reduce frame parsing inside Dot11Decrypt engine. This is
done by breaking out the EAPOL keydata decryption step into a new
function Dot11DecryptDecryptKeyData to be called from dissector.
After this Dot11DecryptScanEapolForKeys can now focus on one
task, to scan for keys in (unencrypted) EAPOL key frames.
With keydata decryption step separated from the broadcast
key parsing step the dissectors' GTK parsing can replace
the Dot11Decrypt internal RSN GTK TAG parsing.
Change-Id: I3b89f40586b8b7dbe2ff74cfc30761010d5b80bc
Reviewed-on: https://code.wireshark.org/review/35022
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
To be able to support authentication key management suites that use
different MIC, PMK, PTK lengths the engine would need to be extended
to support parsing EAPOL Key frames with variable field lengts. Though
as the IEEE 802.11 dissector already support this the alternative
(implemented in this patch) is to remove the EAPOL frame parsing inside
the engine and have the dissector feed it with a struct of parsed
fields instead.
For this a new type DOT11DECRYPT_EAPOL_PARSED is exported and
dot11decrypt now expects dissector to fill this struct with parsed
EAPOL fields before calling Dot11DecryptScanEapolForKeys.
Dissection of EAPOL fields is scattered over several functions in the
dissector code so parsed fields are temporarily stored in proto data
and then gathered before fed into dot11decrypt engine.
Change-Id: Ic6aeb4900f373dcde1ea3f1f0f24df2ae827576e
Reviewed-on: https://code.wireshark.org/review/35020
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
This reverts commit 39bbb90e78.
If you check 9.4.2.242.3 HE PHY Capabilities Information field, you will see the "Supported Channel Width" field starts from B1 of the "HE PHY Capabilities Information field", not B0.
The Table 9-231 Subfields of the HE PHY Capabilities Information fiel applies only for the Channel Width Support Field. So B1 of the PHY cap should be used as B0 of the channel width.
Bug: 16190
Change-Id: Iff5beaf93f57d535b70ffab4b51e4a163aaf3a6d
Reviewed-on: https://code.wireshark.org/review/35038
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
EAPOL key message type is known by dissector so no need for dot11decrypt
to parse frames to determine this. Instead feed engine with message
type from dissector. With this some code duplication can be avoided.
Change-Id: Icfd119186ebab5b0db29968df3eb94275d921e76
Reviewed-on: https://code.wireshark.org/review/34929
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Roland Knall <rknall@gmail.com>
As a step towards removing the parsing of frames inside dot11decrypt
engine separate the key extraction step from the decryption step.
Two new functions for extracting keys are now provided by the
do11decrypt engine. One to be called for EAPOL key frames that
will extract and feed the engine with keys present in 4-way handshake
and group handshake messages. And one to be called for TDLS action
frames to extract keys and feed the engine with keys during TDLS
session establishement.
The old Dot11DecryptPacketProcess function called for all 802.11
frames is simplified and now only has one purpose. To decrypt
encrypted packets. Hence renamed to Dot11DecryptDecryptPacket.
Change-Id: Idb38d538f435ec352c6bbb200a09bc2a2347c42e
Reviewed-on: https://code.wireshark.org/review/34928
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Roland Knall <rknall@gmail.com>
Support Extended Key ID for Individually Addressed Frames from
IEEE 802.11 - 2016.
Extended Key ID allows unicast (PTK) keys to also use key ID 1 and has
an additional RSN attribute "KeyID" in EAPOL #3.
Add the additional attribute KeyID to the RSN parser, stop assuming
unicast keys are only using key ID 0 and add a test case to verify
Extended Key ID parsing and decoding.
Change-Id: I43005c74df561be5524fa3738149781f50dafa14
Reviewed-on: https://code.wireshark.org/review/34883
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl>
This handles the various Multi-AP additions and has been checked by
the WFA.
Change-Id: I56d32f3efec24923e1a710cb67c67f7e0b4630dc
Reviewed-on: https://code.wireshark.org/review/34794
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Add support for the WFA Neighbor Awareness Networking (NAN) protocol.
Bug: 16087
Change-Id: Ideeeea2551c8db722b5578340bef4e504ea73dcf
Reviewed-on: https://code.wireshark.org/review/34635
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
RM Report channel number and duration share the same abbreviation.
Rename duration to wlan.measure.re[qp].duration.
Change-Id: I0a24ffb69e1b0f1c81626ccaeaa7ce1675158465
Reviewed-on: https://code.wireshark.org/review/34562
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Petri-Dish: Gerald Combs <gerald@wireshark.org>
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
If GTK cannot be found inside a successfully decrypted wireless frame
the dot11crypt engine returns incorrect decrypted data length of 0
bytes. As the IEEE802.11 dissector does not check the length of the
decrypted frame the number of bytes allocated and copied to wmem ends
up being a negative number (i.e. a huge unsigned number). This results
in a SIGSEGV crash while copying data.
Fix this both by returning a correct length from dot11crypt engine
and add extra an protection to the IEEE802.11 dissector if the length
for any (other) reason still would end up being a negative number.
Bug: 16058
Change-Id: I9d0d1cf50498dece2e008222eebbb3edc8f10159
Reviewed-on: https://code.wireshark.org/review/34558
Petri-Dish: Pascal Quantin <pascal@wireshark.org>
Tested-by: Petri Dish Buildbot
Reviewed-by: Pascal Quantin <pascal@wireshark.org>
it is now Nominal Packet Padding
fix also some variable name (missing he_phy_cap)
From 802.11ax (Draft 4.1)
Issue reported by Helge Mangus Keck
Change-Id: Iba1d5524383222582060e259b9977b06938d96d6
Reviewed-on: https://code.wireshark.org/review/34515
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Wrong bitmask and duplicate field for same byte
Issue reported by Helge Mangus Keck
Change-Id: Ibc5a914fc2ecc05b9b5f6d0025c52c80af23d9f4
Reviewed-on: https://code.wireshark.org/review/34483
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
1. he_mac_headers can be changed at runtime, so it is not "static" or "const"
2. Optimize out extended length calculation.
Ping-Bug: 15866
Change-Id: Ibf8191a7043a22109ae8a3db481bfbbef583b110
Reviewed-on: https://code.wireshark.org/review/34424
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
IEEE 802.11-2016 Section 9.4.2.25 RSNE
All information after Element ID, Length, and Version are optional; therefore the minimal IE length is 2.
Bug: 15905
Change-Id: I231e31c6a0fe5a26d5dd7c1c36be4e9816a7bb50
Reviewed-on: https://code.wireshark.org/review/34411
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Michael Mann <mmann78@netscape.net>
The contents of the Symbol Proprietary TLV was assumbed to be the same
as the Vendor Specific TLV. This proved not to be the case, at least for
Zebra Extreme networks nodes. This change implements the dissection of
the format as defined in the bug.
Bug: 15909
Change-Id: I4c14dde386d33302d187680f9f09f8b5bb1ef213
Reviewed-on: https://code.wireshark.org/review/34023
Petri-Dish: Jaap Keuter <jaap.keuter@xs4all.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Jaap Keuter <jaap.keuter@xs4all.nl>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
The original code was causing a malformed packet exception if there was
one additional byte after the measurement pilot interval.
Bug: 15903
Change-Id: Ibe3e7fab5ea5c3d18ea4792ff342a0d8b8d2533b
Reviewed-on: https://code.wireshark.org/review/33858
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Petri-Dish: Peter Wu <peter@lekensteyn.nl>
Tested-by: Petri Dish Buildbot
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
This helps developers know they are missing bits of data that should be
there by adding an expert info rather than showing a malformed packet.
Bug: 15861
Change-Id: Iacd85be228c60e4e3dcef344a38506568172e0da
Reviewed-on: https://code.wireshark.org/review/33691
Petri-Dish: Richard Sharpe <realrichardsharpe@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Bits named according to IEEE 802.11-2016, p.836, Figure 9-192
Change-Id: I4e0a6c90796d80ebbdc31c32a3ea2d9da4db8885
Reviewed-on: https://code.wireshark.org/review/33193
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Fine Time Measurement protocol has been introduced as part of 802.11mc,
wireshark software is missing the support of parsing the FTM.
Add necessary changes to parse FTM frames.
Bug: 15721
Change-Id: I86c6a8db25ffc99df146e0fa1c1cc05bf29710d2
Reviewed-on: https://code.wireshark.org/review/32935
Reviewed-by: Michael Mann <mmann78@netscape.net>
Petri-Dish: Michael Mann <mmann78@netscape.net>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Issue reported by Helge Magnus Keck
Change-Id: I7878a56acf07119fc7f900eb72b6d497c675567c
Reviewed-on: https://code.wireshark.org/review/32808
Reviewed-by: Richard Sharpe <realrichardsharpe@gmail.com>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Issue reported by Helge Magnus Keck
Change-Id: Ib761b4209d1efc80ca2c107dda9919e71f5865c2
Reviewed-on: https://code.wireshark.org/review/32798
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
In the IEEE 802.11 dissector the conversations concept is (re)used
for tracking associations. The conversations are then used to keep
data that's unique for a certain association, like negotiated AKMS.
Though currently associations are unique per (re)association
whereas conversations are unique based only on src/dest address.
This is problematic for captures with multiple associations with
same STA/BSSI pair.
For example:
Assoc req frame (assoc #1, conversation #1)
Reassoc frame (assoc #2, conversation #1)
Assoc req frame (assoc #3, conversation #1)
To make a one to one mapping between conversations and associations
store an association counter with each frame and use it with the pinfo
srcport/destport fields to build a conversation key:
(src, dest, association_counter).
Bug: 15616
Change-Id: Ie020bdffbcdab4739ee07f73025ef1157c1fc329
Reviewed-on: https://code.wireshark.org/review/32737
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Also the MIC inside FT IE is variable length in coming IEEE 802.11
spec. According to IEEE 802.11 spec the MIC length is based on AKMS
negotiated during (re)association phase. This is good as long as
the capture file contains needed assoc frames.
Though if association frames are missing the MIC length is unknown.
As a backup try to use the AKMS found in current frame to
determine MIC length. Handle this logic in a new function like this:
MIC length is detemined by:
1. User overridden MIC length setting
2. AKMS negotiated during association phase (conversation)
3. AKMS from current frame
4. Default 16 bytes length.
Also changes had to be done to the ieee80211_packet_data_t handling.
This structure appears to be used as a temporary storage for data
related to current frame. However data was stored in file scope making
it impossible to know whether data was from current or another frame.
This is fixed by changing to the pinfo pool.
Bug: 15616
Change-Id: I521d440b47d71cbc94cd6c56714d21274c8dd23e
Reviewed-on: https://code.wireshark.org/review/32693
Petri-Dish: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Formation Information: Connect to Mesh Gate / AS
Reserved bit Capability
Issue reported by Helge Magnus Keck
Change-Id: Icf5337ab45bbf7ce1660b560b5fbc22d11785ec0
Reviewed-on: https://code.wireshark.org/review/32797
Petri-Dish: Anders Broman <a.broman58@gmail.com>
Tested-by: Petri Dish Buildbot
Reviewed-by: Anders Broman <a.broman58@gmail.com>
Mikael Kanstrup