Hey, After looking again into why we were sending frames with invalid QoS control fields under certain circumstances it occurred to me that this would only happen when CONFIG_NET_SCHED was not set. That, however, seems wrong: when CONFIG_NET_SCHED is unset we really are behaving as a non-QoS STA. However, even if it is set we never announce our QoS capability, hostapd will never set the QoS capability field in a beacon and neither will we set in our capability information in (re)association requests. On the other hand, in both cases we will start sending QoS frames if the other side has announced support for it in their capability information. It seems to me that this violates the mandated behaviour if we're an AP in that we force a QoS-capable STA to behave as a QoS STA although it is associated to a non-QoS BSS and thus should expect to work as a non-QoS STA. It seems to me that we should introduce a new per-interface (where VLAN interfaces use the AP setting) "QoS enabled" setting that wpa_supplicant (when acting as MLME) or hostapd set. For the in-kernel-MLME, I would suggest to force it to be off. Enabling QoS would be disallowed when CONFIG_NET_SCHED is unset or when we have only one hardware queue. It should then behave like the 802.11 option "dot11QosOptionImplemented", but consistency wouldn't be enforced (i.e. hostapd sets this option so it is also required to set the QoS capability flag and insert the EDCA parameter set or QOS capability IE) johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
