All the "Failed to decrypt frame" debug prints were confusing since
those were not supposed to be shown unless there were one or more real
TKs available. The recently added check for zero TK added these notes
for that case which is not really correct, so get rid of them.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This makes it easier to analyze certain encryption issues. Also print
out an error at the default INFO debug verbosity with the frame number.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This allows Data frames to be fully processed for the case where VLAN
tags are used on the wireless link.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If a sniffer capture does not include FCS for each frame, but may
included frames with invalid FCS, it would be possible for wlantest to
try to decrypt the first received frame and fail (e.g., due to CCMP MIC
mismatch) because that particular frame was corrupted and then ignore
the following retry of that frame as a duplicate even if that retry has
different payload (e.g., if its reception did not show corruption).
Work around this by skipping duplicate frame detection immediately
following a decryption failure.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Commit aab6612836 ('wlantest: Search
bss/sta entry more thoroughly for 4-address frames') allowed wlantest to
find a STA entry in this type of cases, but it was still possible for
that STA entry to be the one that has no derived PTK while the STA entry
for the other side of the link might have the derived PTK available.
Extend this BSS/STA selection mechanism to use sta->ptk_set to determine
which STA entry is more useful for decryption, i.e., select the one with
a known PTK.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Previous design worked for the case where only one of the devices was
beaconing, but failed in one direction to find the PTK if both devices
beaconed. Fix this by checking the A1/A2 fields in both directions if
the first pick fails to find the sta entry.
In addition, select the proper rsc value (rsc_tods vs. rsc_fromds) based
on A2 (TA) value for ToDS+FromDS frames to avoid reporting incorrect
replay issues.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The length of the TK is available within struct wpa_ptk, so there is no
need to try to maintain it separately in wlantest.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This changes wlantest behavior to mark CCMP/TKIP replays for more cases
in case a device is resetting its TSC. Previously, the RSC check got
cleared on the first marked replay and the following packets were not
marked as replays if they continued incrementing the PN even if that PN
was below the highest value received with this key at some point in the
past.
Signed-off-by: Jouni Malinen <j@w1.fi>
This covers the case where 4-address Data frames are exchanged between
an AP and an associated station.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Suite B 192-bit addition from IEEE Std 802.11ac-2013 replaced the
previous fixed length Key MIC field with a variable length field. That
change was addressed with an addition of a new struct defined for the
second MIC length. This is not really scalable and with FILS coming up
with a zero-length MIC case for AEAD, a more thorough change to support
variable length MIC is needed.
Remove the Key MIC and Key Data Length fields from the struct
wpa_eapol_key and find their location based on the MIC length
information (which is determined by the AKMP). This change allows the
separate struct wpa_eapol_key_192 to be removed since struct
wpa_eapol_key will now include only the fixed length fields that are
shared with all EAPOL-Key cases in IEEE Std 802.11.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
There is no strong need for pulling in linux/if_ether.h here since all
that is needed if ETH_P_IP and we already cover multiple other ETH_P_*
values in utils/common.h.
Signed-off-by: Jouni Malinen <j@w1.fi>
This modifies struct wpa_ptk to allow the length of KCK and KEK to be
stored. This is needed to allow longer keys to be used, e.g., with
Suite B 192-bit level.
Signed-off-by: Jouni Malinen <j@w1.fi>
These were somewhat more hidden to avoid direct use, but there are now
numerous places where these are needed and more justification to make
the extern int declarations available from wpa_debug.h. In addition,
this avoids some warnings from sparse.
Signed-hostap: Jouni Malinen <j@w1.fi>
A text file with a hexdump of PTK (KCK|KEK=TK with 48 octets for CCMP or
64 octets for TKIP or alternative 16 or 32 octet TK for CCMP/TKIP) can
now be read from a file specified with the -T command line argument. If
the current known PTK fails to decrypt a frame (or if no current PTK is
known) all listed PTKs are iterated to see if any of them matches.
Signed-hostap: Jouni Malinen <j@w1.fi>
Some corner cases may result in both directions of TDLS tracking context
existing. If that is the case, the incorrect one may end up getting
picked when figuring out which TK to use for decryption or fix
statistics counter to increment. Fix this by preferring the context that
has TDLS link up.
Signed-hostap: Jouni Malinen <j@w1.fi>
This adds debug information from wlantest into pcapng frame comments to
make the information more convenient to use, e.g., in Wireshark.
Signed-hostap: Jouni Malinen <j@w1.fi>
Use a temporary PTK buffer during 4-way handshake when rekeying PTK
so that the new EAPOL-Key frame MIC values are checked against the
new PTK and frames are decrypted using the old PTK. Take the new
PTK into use once msg 4/4 is processed and clear RSC counters at
that point (including moving of RSC update to avoid setting RSC
based on the msg 4/4).
In addition, add a workaround to handle supplicant implementations that
set Secure bit to one during PTK rekeying 4-way handshake in msg 2/4.
This was previously assumed to be msg 4/4, but the key data contents
can be used to figure out whether this is msg 2/4 even if the Secure
bit is set to one.
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Verify that WPA/RSN IE in (Re)Association Request is identical to the
one used in EAPOL-Key message 2/4.
Verify that WPA/RSN IE in Beacon/Probe Response is identical to the
one(s) used in EAPOL-Key message 3/4.
The output file includes all the capture (or read from wireless PCAP
file) frames in their original contents and another copy of each
frame that is decrypted in wlantest (including EAPOL-Key Key Data
field).
