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>
