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>
