Add support for new channels 173 and 177 in the operating classes 125 to
130 as defined in draft IEEE P802.11ax/D8.0.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Replace the implicit boolean checks that used int variables with use of
a more explicit bool variable type.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This makes it easier to change the internal struct wpa_bss design for
storing the variable length IE buffers.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add support for missing 6 GHz operating classes as defined in
IEEE P802.11ax/D7.0.
This is needed to avoid OCV failures on the 6 GHz band when the channel
width is larger than 20 MHz.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
The previous implementation was assuming a fixed 20 MHz channel
bandwidth when determining which operating class value to indicate as
the Current Operating Class in the Supported Operating Classes element.
This is not accurate for many HT/VHT cases.
Fix this by determining the current operating class (i.e., the operating
class used for the requested association) based on the HT/VHT operation
elements from scan results.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The 5 GHz channels are stored in one hw_features set with mode
HOSTAPD_MODE_IEEE80211A while the 6 GHz channels will need to be stored
in a separate hw_features set (but with same mode
HOSTAPD_MODE_IEEE80211A) due to possibility of different HT/VHT/HE
capabilities being available between the 5 GHz and 6 GHz bands.
Iterate through all hw_features sets and check and match the band of
channel supported by the hw_features set while getting the hw_features
set in get_mode(). This allows both the 5 GHz and 6 GHz channels to be
found and correct capabilities to be used in cases where the driver
reports different capability values between 5 and 6 GHz channels.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This gives us the network device name in logging messages, which can be
helpful when having one wpa_supplicant process handle multiple devices.
Signed-off-by: Ben Greear <greearb@candelatech.com>
This is needed to allow the 6 GHz operating classes to be compared
against the driver support channels since the channel numbers are not
really unique identifiers of a channel even within a single band.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
ENOTCONN, EOPNOTSUPP, and ECANCELED are defined in a newer version of
MinGW, so make this workaround conditional on what is defined in the
header files.
Signed-off-by: Jouni Malinen <j@w1.fi>
The bandwidth values are shared between VHT and HE mode so remove the
VHT specific prefix.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
The last beacon report indication was set in all the beacon report
elements in the last frame of the beacon report, while it should be
set only in the last beacon report element of the last frame.
Fixes: ecef0687dc ("RRM: Support for Last Beacon Report Indication subelement")
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
IEEE P802.11-REVmd/D2.0, 9.4.2.20.7 (Beacon request) and 9.4.2.21.7
(Beacon report) add the Last Beacon Report Indication subelement to
Beacon Request and Beacon Report elements.
Add the Last Beacon Report Indication subelement to all Beacon Report
elements if the Beacon Request indicated that this subelement is
requested.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
When the frame body subelement would cause the measurement report
element to exceed the maximum element size, the frame body subelement
used to be truncated. In addition, some elements were always truncated
in order to keep the reported frame body short (e.g. RSN IE).
Alternatively, IEEE P802.11-REVmd/D2.0, 9.4.2.21.7 extension to Beacon
reporting can be used: The frame body subelement is fragmented across
multiple beacon report elements, and the reported frame body fragment ID
subelement is added.
Use beacon report fragmentation instead of truncating the frame body
as this method gives the AP a more complete information about the
reported APs.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
When setting the frequencies for beacon report request scan, it is
possible that a frequency is added twice (e.g., when the same channel
appears both in the channel field and in the AP channel report
subelement). This may cause the scan request to fail.
Make sure the frequencies array contains no duplications before
requesting the scan.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Send Radio Measurement response with measurement mode set to reject
in the following cases:
1. Reporting conditions is not supported.
2. No valid channels found for the measurement
Sending a response with an incapable indication will stop the AP from
sending other measurement requests of the same type as specified
in IEEE Std 802.11-2016, 11.11.6.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
When failing to trigger scan for beacon report (e.g., when the
requested duration is not supported by the driver), send a
Radio Measurement response with the mode set to refused and don't
retry the scan.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
IEEE Std 802.11-2016, 11.11.6 specifies that a station that is unable to
make a requested measurement or refuses to make a measurement shall
respond only if the measurement request was received within an
individually addressed radio measurement request frame, but shall not
respond if such a request was received in a group addressed frame.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Scan results with parent TSF older than the scan start TSF are not added
to the beacon report since they are considered as scan results from
previous scans. However, for drivers that report the scan start TSF but
not the parent TSF of each scan result, the parent TSF will be zero so
valid scan results will be dropped.
Fix this by filtering scan results by the parent TSF only if the
driver supports reporting the parent TSF for each scan result.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
The while (len) loop was updating the next pointer at the end even when
len == 0, i.e., when the new next value won't be used. This could result
in reading one octet beyond the end of the allocated response wpabuf.
While the read value is not really used in practice, this is not correct
behavior, so fix this by skipping the unnecessary next pointer update in
len == 0 case.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The maximum required size for each Beacon Report element is known in
advance: it is the size of the Beacon Report element fixed fields + the
size of the Reported Frame Body subelement.
Allocate the buffer used for constructing the Beacon Report element
dynamically with the maximum needed size, instead of using a very
large static buffer.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Free the pending frequency list if a second beacon request is received
before the scan for the previous one has been completed.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Add a comment to note which fields are expected to be updated by the
driver. In addition, reorder subfield writing to match the order in
which the fields are in the frame.
Signed-off-by: Jouni Malinen <j@w1.fi>
ieee80211_chan_to_freq() is not really meant for conversion of 20 MHz
primary channel numbers for wider VHT channels, so handle those as
special cases here for now.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpabuf_resize() can handle the initial allocation of a wpabuf and all
the other callers of wpas_rrm_report_elem() were already using a pointer
to a pointer and a wpabuf_resize() call. Simplify this by resizing the
wpabuf (if needed) within wpas_rrm_report_elem() instead of having to
calculate the needed size in all the callers. Thsi is also fixing one of
the allocation sizes to use the correct size instead of a size of a
struct that has nothing to do with the allocation (but is larger than
the needed five octets, so does not break anything).
Signed-off-by: Jouni Malinen <j@w1.fi>
There is only a single caller for wpas_rrm_send_neighbor_rep_request()
and it unconditionally uses a callback function, so cb cannot be NULL
here and there is no need for additional complexity and extra code size
to check for it explicitly.
Signed-off-by: Jouni Malinen <j@w1.fi>
The pending neighbor report state needs to be cleared on error path here
to avoid getting stuck with being unable to perform any additional
neighbor reports during the association.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Allow shorter request since the subelements are optional to include.
Also print the hexdump of the subelements into debug log.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The requested behavior can be approximated for most use cases even if
the driver does not support reporting exact TSF values for frames.
Enable this capability for all drivers to make beacon report processing
more useful for a common use case.
Signed-off-by: Jouni Malinen <j@w1.fi>
The special parameters for beacon report scan are not needed for the
beacon report when using the beacon table measurement mode. Advertise
support for this case regardless of whether the driver supports the scan
parameters.
Signed-off-by: Jouni Malinen <j@w1.fi>
Beacon Report Radio Measurement is defined in IEEE Std 802.11-2016,
11.11.9.1. Beacon Report is implemented by triggering a scan on the
requested channels with the requested parameters.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
This conversion will be done several times in the code, so add a helper
function that does this conversion.
Signed-off-by: Avrahams Stern <avraham.stern@intel.com>
1. Change the return type to reflect whether building the report
succeeded or failed.
2. Change argument type to rrm_measurement_request_element instead
of raw packet data to ease processing the request.
3. Use already existing function to create the measurement report
and add it to the report buffer.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Send measurement report with the mode field set to incapable in response
to measurement requests with unsupported measurement types.
In addition, measurements requests that request parallel measurements
are rejected since these features are not supported.
Measurement request frames with the enable bit set are ignored since
these are not really requesting measurements and are not supported for
now.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
The length of a Measurement Report frame should be limited by the
maximum allowed MMPDU size (IEEE Std 802.11-2016, 9.6.2.3). Enforce this
size limit, and in case the report elements are longer than the allowed
size, split them between several MPDUs.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Extract the code dealing with processing the measurement request
elements to a separate function. This will be needed for beacon report
requests processing.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
RRM request frame should contain only information elements of type Radio
Measurement Request. Go through all the frame and validate that only
elements of this type are included.
In addition, if a truncated element is encountered, or the element
length field indicates that the element length is more than the
entire frame, abort the request.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
As support for new RRM measurements will be added, the RRM
implementation will become quite large, so move it to a dedicated file.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Sreeramya Soratkal
Jouni Malinen
Veerendranath Jakkam
Ananya Barat
Vamsi Krishna
Ben Greear
Jouni Malinen
John Crispin
Avraham Stern
Jouni Malinen
Johannes Berg