Hi,
We are trying to develop an algorithm by using the information of RTS reception at the receiver side. (actually, we need the preceding frame of A-MPDU).
As far as we know, RTS/CTS exchange is done by firmware of NIC.
However, in monitor mode, we quite sure that the RTS/CTS frame reception should be reported to upper layer.
As an evidence, Wireshark can capture and display the RTS/CTS reception.
However, mac80211 and device driver (e.g., ath10k) can not recognize the reception of RTS even if we put the WiFi NIC in monitor mode.
We check the type and subtype of frame_control field for all the received frames at the “ieee80211_rx_monitor” function of mac80211.
We can find the reception of data frames amd mgmt frames, but there is no RTS/CTS frame.
(We confirm that there is the RTS/CTS frame by using wireshark.)
Is there any way to know the information about RTS reception in mac80211 or device driver?
Thank you.
--
Okhwan Lee,
[email protected]
On 7 October 2014 13:30, Okhwan Lee <[email protected]> wrote:
> Hi,
>
> We are trying to develop an algorithm by using the information of RTS reception at the receiver side. (actually, we need the preceding frame of A-MPDU).
> As far as we know, RTS/CTS exchange is done by firmware of NIC.
> However, in monitor mode, we quite sure that the RTS/CTS frame reception should be reported to upper layer.
> As an evidence, Wireshark can capture and display the RTS/CTS reception.
>
> However, mac80211 and device driver (e.g., ath10k) can not recognize the reception of RTS even if we put the WiFi NIC in monitor mode.
> We check the type and subtype of frame_control field for all the received frames at the “ieee80211_rx_monitor” function of mac80211.
> We can find the reception of data frames amd mgmt frames, but there is no RTS/CTS frame.
> (We confirm that there is the RTS/CTS frame by using wireshark.)
>
> Is there any way to know the information about RTS reception in mac80211 or device driver?
I think you've just found an ath10k bug.
I've been running through Rx code lately. I was looking at
htt_rx_mpdu_status and noticed it was a bit greedy. I then recalled
someone was complaining about RTS reception.
I'll try to fix this soon. I'll put you in Cc in case you'd want to
play with it before it's merged.
Michał
Michal Kazior wrote:
> I think you've just found an ath10k bug.
>
> I've been running through Rx code lately. I was looking at
> htt_rx_mpdu_status and noticed it was a bit greedy. I then recalled
> someone was complaining about RTS reception.
Maybe the RX filter to receive control frames is not set properly in the FW ?
ath10k doesn't seem to use WMI_10X_PDEV_PARAM_RX_FILTER.
Sujith
On 8 October 2014 16:50, Sujith Manoharan <[email protected]> wrote:
> Michal Kazior wrote:
>> I think you've just found an ath10k bug.
>>
>> I've been running through Rx code lately. I was looking at
>> htt_rx_mpdu_status and noticed it was a bit greedy. I then recalled
>> someone was complaining about RTS reception.
>
> Maybe the RX filter to receive control frames is not set properly in the FW ?
> ath10k doesn't seem to use WMI_10X_PDEV_PARAM_RX_FILTER.
I suspect ath10k is dropping RTS frames in
ath10k_htt_rx_amsdu_allowed() now because RX_ATTENTION_FLAGS_MGMT_TYPE
includes management, control and null function frames. I'm yet to
confirm what ath10k really ends up dropping now though.
Michał