Clean up in a more common fashion as well, initially for ../src/.
Also add $(Q) to the clean target in src/
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some things are used by most of the binaries, pull them
into a common rule fragment that we can use properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The case where a single 0xdd octet without any 0x00 octets is used as
padding was addressed incorrectly and that ended up truncating one octet
of the actual plaintext version of the Key Data value. Fix this by
removing the unnecessary change to the p pointer before calculating the
new length since p is already pointing to one past the last octet of the
full plaintext.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
We're doing a sort of bounds check, based on the previous loop, but only
after we've already tried to read off the end.
This squashes some ASAN errors I'm seeing when running the ap_ft hwsim
test module.
Signed-off-by: Brian Norris <briannorris@chromium.org>
Verify that RSNE, MDE, and FTE have valid information in FT
Reassociation Response frames. In addition, decrypt GTK, IGTK, and BIGTK
from the frame.
Signed-off-by: Jouni Malinen <j@w1.fi>
It is expected for the STA entry on the target AP to move directly from
State 1 to State 3 when performing FT over-the-DS (i.e., FT Action
Request/Response frame exchange through the old AP followed by
Reassociation Request/Response frame exchange with the target AP).
Signed-off-by: Jouni Malinen <j@w1.fi>
The ar operations with embedded libraries were not exactly portable
or strictly speaking necessary. Drop that library completely to make
this more portable.
Signed-off-by: Jouni Malinen <j@w1.fi>
The PN and RSC are already printed in the "replay detected" debug
message so there is no point in having separate hexdumps of the same
values immediately after that.
Signed-off-by: Jouni Malinen <j@w1.fi>
If no WEP keys are available, there is not going to be an attempt to
decrypt the frame, so don't claim decryption failed.
Signed-off-by: Jouni Malinen <j@w1.fi>
Update TPTK to PTK if a valid EAPOL-Key msg 2/4 and 3/4 are available,
but 4/4 is missing. This avoids certain cases where the new TK could be
derived, but it was not being used to try to decrypt following encrypted
frames.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
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>
Previously, missing CCMP protection on Robust Management frames was
reported based on the STA having indicated MFPC=1. That is not accurate
since the AP/BSS may have MFPC=0. Report this failure only if both the
AP and STA have indicated MFPC=1, i.e., when PMF has been negotiated for
the association.
Signed-off-by: Jouni Malinen <j@w1.fi>
If no Beacon or Probe Response frame has been seen in the capture, use
the IEs from EAPOL-Key msg 3/4 to set up BSS information.
Signed-off-by: Jouni Malinen <j@w1.fi>
The previous implementation tried to update STA IE information based on
EAPOL-Key msg 2/4 to be able to handle captures that do not include the
(Re)Association Request frame. This was not sufficient (OSEN was not
included) and was done too late (the parsed information is needed for
PMK-to-PTK derivation).
Move the IE update step to happen before trying to derive the PTK if no
(Re)Association Request frame has been seen.
Signed-off-by: Jouni Malinen <j@w1.fi>
Fetch the BIGTK from EAPOL-Key msg 3/4 and use it to validate MME in
Beacon frames when the AP uses Beacon protection.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
wlantest build did not define build options to determine key management
values for SAE, OWE, and DPP. Add those and the needed SHA512 functions
to be able to decrypt sniffer captures with PMK available from an
external source.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Allow option (command line argument -e) to capture Ethernet headers
instead of IEEE 802.11 so that wlantest can be used as a replacement for
tcpdump/dumpcap for capturing.
Signed-off-by: Jouni Malinen <j@w1.fi>
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>
Hardcode this to be defined and remove the separate build options for
PMF since this functionality is needed with large number of newer
protocol extensions and is also something that should be enabled in all
WPA2/WPA3 networks.
Signed-off-by: Jouni Malinen <j@w1.fi>
Track PMK-R0/PMK-R0-Name from the initial mobility domain association
and derive PMK-R1/PTK when the station uses FT protocol. This allows
frames from additional roaming cases to be decrypted.
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>
DPP allows Diffie-Hellman exchange to be used for PFS in PTK derivation.
This requires an additional Z.x (x coordinate of the DH shared secret)
to be passed to wpa_pmk_to_ptk(). This commit adds that to the function
and updates all the callers to pass NULL,0 for that part in preparation
of the DPP specific changes to start using this.
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>
wlantest used to ignore RSN/WPA/OSEN element in (Re)Association Request
frame if no Beacon frame had been seen from the AP before the
association exchange. This could result in not being able to derive keys
properly. Work around this by skipping that step if the BSS entry is not
yet complete.
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>
This part is missing from IEEE Std 802.11ai-2016, but the lack of DHss
here means there would not be proper PFS for the case where PMKSA
caching is used with FILS SK+PFS authentication. This was not really the
intent of the FILS design and that issue was fixed during REVmd work
with the changes proposed in
https://mentor.ieee.org/802.11/dcn/17/11-17-0906-04-000m-fils-fixes.docx
that add DHss into FILS-Key-Data (and PTK, in practice) derivation for
the PMKSA caching case so that a unique ICK, KEK, and TK are derived
even when using the same PMK.
Note: This is not backwards compatible, i.e., this breaks PMKSA caching
with FILS SK+PFS if only STA or AP side implementation is updated.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
