[RFC/Report] hostapd: Gracefully handle unsolicited 802.11k Link Measurement Reports

[Brian J. Murrell]

Hi all,

I am writing to report an issue and propose a change to how hostapd
handles 802.11k Link Measurement Reports, specifically regarding
unsolicited reports from client devices.

The Problem:
When 802.11k is enabled (specifically advertising Link Measurement
capabilities), many modern client devices (iOS, Android, various IoT)
will proactively send unsolicited Link Measurement Reports to the AP to
help it assess bi-directional link quality.

Currently, in src/ap/rrm.c, the hostapd_handle_link_mesr_report()
function strictly expects a solicited response. It checks if hapd-
>link_mesr_req_active is true and if the dialog_token matches the AP's
request.

If a client sends an unsolicited report, link_mesr_req_active is false.
hostapd drops the frame and logs the following at the MSG_INFO level:
"Unexpected Link measurement report, token %u"

With multiple active clients on a network, this results in significant
log spam, making it difficult to monitor the AP for actual issues.

The Root Cause:
While the 802.11k standard allows for unsolicited Link Measurement
Reports, hostapd's current state machine is rigidly built around a
Request-Response model. Because it doesn't expect the frame, it treats
it as an anomaly and logs it as an informational error, even though the
frame itself is valid.

Proposed Solutions:
I would like to propose one of the following changes to address this:
Accept and Process Unsolicited Reports: Modify
hostapd_handle_link_mesr_report() to allow processing when
link_mesr_req_active == 0. The AP could parse the unsolicited report
and pass the link quality data (RSSI, SNR, etc.) to the control
interface or update the internal STA state, turning this "spam" into
useful proactive telemetry.
Silent Drop (Fallback): If processing unsolicited reports is out of
scope for the current architecture, at minimum, change the log level
for this specific condition from MSG_INFO to MSG_DEBUG. Since the AP is
safely ignoring a valid (but un-prompted) 802.11k frame, it shouldn't
pollute the standard INFO logs.

Current Workaround:
Right now, the only way to stop the log spam without muting the entire
INFO log level is to disable rrm_link_measurement_report in
hostapd.conf. This forces clients to stop sending the reports, but it
deprives the AP of useful link quality telemetry that the 802.11k
standard is designed to provide.

I am reporting this in hopes that the maintainers or community can
consider implementing a fix to handle these frames more gracefully.

Thank you for your time and for maintaining this project.

Cheers,
b.