_next_ns_data could look like it would be used uninitialized in
ieee80211_radiotap_iterator_next() to static analyzers. Avoid
unnecessary reports by explicitly initializing all variables in struct
ieee80211_radiotap_iterator. (CID 62878)
Signed-off-by: Jouni Malinen <j@w1.fi>
The previous version was valid, but apparently too complex for some
static analyzers. Use a local variable for uri_len and explicitly
compare it against the remaining buffer length. (CID 68121)
Signed-off-by: Jouni Malinen <j@w1.fi>
The previous version was fine, but too much for some static analyzers to
understand as proper bounds checking. (CID 68122)
Signed-off-by: Jouni Malinen <j@w1.fi>
Static analyzers may not have understood the bounds checking on
data->num_pmkid. Use a local, temporary variable and validate that that
value is within length limits before assining this to data->num_pmkid to
make this clearer. (CID 62857, CID 68126)
Signed-off-by: Jouni Malinen <j@w1.fi>
This makes it easier for static analyzer to confirm that the length
field bounds are checked. WPA_GET_BE16() is also used instead of
explicit byte-swapping operations in this file. (CID 68129)
Signed-off-by: Jouni Malinen <j@w1.fi>
Use a temporary, local variable to check the DH parameters received from
the server before assigning the length to the struct tlsv1_client
variables. This will hopefully make it easier for static analyzers to
figure out that there is bounds checking for the value. (CID 72699)
Signed-off-by: Jouni Malinen <j@w1.fi>
The upper bound for the element length was already verified, but that
was not apparently noticed by a static analyzer (CID 68128).
Signed-off-by: Jouni Malinen <j@w1.fi>
It could have been possible to select a socket that is not open
(sel_sock == -1) and try to use that in socket operations. This would
fail with potentially confusing error messages. Make this clearer by
printing a clear debug log entry on socket not being available.
(CID 72696)
Signed-off-by: Jouni Malinen <j@w1.fi>
It looks like the "pos + plen > end" case was not clear enough for a
static analyzer to figure out that plen was being verified to not go
beyond the buffer. (CID 72687)
Signed-off-by: Jouni Malinen <j@w1.fi>
Send link measurement response when a request is received. Advertise
only RCPI, computing it from the RSSI of the request. The TX power field
is left to be filled by the driver. All other fields are not published.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Add link measurement request to registration of Action frames to be
handled by wpa_supplicant if the driver supports TX power value
insertation.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Allow supplying an SSID for the SSID IE. If not supplied, no SSID IE is
sent, and the request implies the current SSID.
Signed-off-by: Assaf Krauss <assaf.krauss@intel.com>
Add NEIGHBOR_REP_REQUEST command to the wpa_supplicant ctrl_iface.
This command triggers the sending of a Neighbor Report Request to the
associated AP.
Signed-off-by: Assaf Krauss <assaf.krauss@intel.com>
Add the ability to send a Neighbor Report Request (part of
RRM). Requester is then notified once the report arrives.
Signed-off-by: Assaf Krauss <assaf.krauss@intel.com>
Add Neighbor Report Response Action frame to registration of Action
frames to be handled by wpa_supplicant.
Signed-off-by: Assaf Krauss <assaf.krauss@intel.com>
In case the AP we are associating with advertises support for RRM,
advertise our own RRM support in the (Re)Association Request frame. This
is done by adding an RRM Capabilities IE. The underlying driver is
expected to further add a Power Capabilities IE to the request, and set
the Radio Measurement flag in the Capability Info field. At this point
the RRM Capabilities IE advertises no measurement support.
Signed-off-by: Assaf Krauss <assaf.krauss@intel.com>
Set the RRM capability flags, based on the capabilities reported
by the underlying driver.
In addition, upon connection, notify the underlying driver regarding
RRM support.
Signed-off-by: Assaf Krauss <assaf.krauss@intel.com>
Add definitions for RRM (Radio Resource Measurement) support:
1. Flags that specify the RRM capabilities of the underlying driver
2. Flag for RRM in Capability Info field in Management frames
3. Indication in association parameters regarding an RRM connection
Signed-off-by: Assaf Krauss <assaf.krauss@intel.com>
If the last scans are recent (for now, less than ten seconds old), use
them instead of triggering a new scan when a BSS Transition Management
Request frame is received. As a fallback, allow a new scan to be
triggered if no matches were found.
Signed-off-by: Jouni Malinen <j@w1.fi>
When the list of preferred transition candidates is received, use the
identified channels to optimize the following scan so that no time is
wasted on other channels.
Signed-off-by: Jouni Malinen <j@w1.fi>
ieee80211_chan_to_freq() is a generic function that replaces and extends
the previous P2P-specific p2p_channel_to_freq(). The new function
supports both the global operating class table as well as the additional
US, EU, JP, and CN operating class tables.
Signed-off-by: Jouni Malinen <j@w1.fi>
except_ack() was supposed to be verifying that the frame was ACK'ed,
i.e., it was really supposed to be called expect_ack().
Signed-off-by: Jouni Malinen <j@w1.fi>
The implementation of WNM BSS transition management was extended to be
able to return a reject status code based on whether a matching entry is
found. The test case wnm_bss_tm_req was trying to enforce a different
status code to be used here based on old implementation.
Signed-off-by: Jouni Malinen <j@w1.fi>
The previously cached candidate list needs to be free properly through a
call to wnm_deallocate_memory() to ensure all subelements gets freed.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows an AP to steer us to another BSS within the ESS even if that
results in reduced signal strength as long as the signal strength with
the target BSS is expected to provide some connectivity.
Signed-off-by: Jouni Malinen <j@w1.fi>
There is no need to use a separately allocated data structures for this.
A bitfield indicating which information is present and variables within
struct neighbor_report are simpler to use and more efficient.
Signed-off-by: Jouni Malinen <j@w1.fi>
hostapd control interface can now be used to request transmission of a
BSS Transition Management Request frame to a specified station.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This implements minimal RSN 4-way handshake Supplicant in Python and
uses that to test hostapd Authenticator implementation in various
possible protocol sequencies.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If the 4-way handshake ends up having to retransmit the EAPOL-Key
message 1/4 due to a timeout on waiting for the response, it is possible
for the Supplicant to change SNonce between the first and second
EAPOL-Key message 2/4. This is not really desirable due to extra
complexities it causes on the Authenticator side, but some deployed
stations are doing this.
This message sequence looks like this:
AP->STA: EAPOL-Key 1/4 (replay counter 1, ANonce)
AP->STA: EAPOL-Key 1/4 (replay counter 2, ANonce)
STA->AP: EAPOL-Key 2/4 (replay counter 1, SNonce 1)
AP->STA: EAPOL-Key 3/4 (replay counter 3, ANonce)
STA->AP: EAPOL-Key 2/4 (replay counter 2, SNonce 2)
followed by either:
STA->AP: EAPOL-Key 4/4 (replay counter 3 using PTK from SNonce 1)
or:
AP->STA: EAPOL-Key 3/4 (replay counter 4, ANonce)
STA->AP: EAPOL-Key 4/4 (replay counter 4, using PTK from SNonce 2)
Previously, Authenticator implementation was able to handle the cases
where SNonce 1 and SNonce 2 were identifical (i.e., Supplicant did not
update SNonce which is the wpa_supplicant behavior) and where PTK
derived using SNonce 2 was used in EAPOL-Key 4/4. However, the case of
using PTK from SNonce 1 was rejected ("WPA: received EAPOL-Key 4/4
Pairwise with unexpected replay counter" since EAPOL-Key 3/4 TX and
following second EAPOL-Key 2/4 invalidated the Replay Counter that was
used previously with the first SNonce).
This commit extends the AP/Authenticator workaround to keep both SNonce
values in memory if two EAPOL-Key 2/4 messages are received with
different SNonce values. The following EAPOL-Key 4/4 message is then
accepted whether the MIC has been calculated with the latest SNonce (the
previously existing behavior) or with the earlier SNonce (the new
extension). This makes 4-way handshake more robust with stations that
update SNonce for each transmitted EAPOL-Key 2/4 message in cases where
EAPOL-Key message 1/4 needs to be retransmitted.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
