On Tue, Jan 5, 2016 at 4:52 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote:
> On Tue, 2016-01-05 at 16:43 +0100, Helmut Schaa wrote:
>
>> > That said, it obviously also points to a driver bug not treating
>> > these frames correctly, so you might want to investigate why you
>> > got here to start with!
>>
>> It was not the driver marking the frame as filtered but mac80211
>> itself in status.c:
>>
>> acked = !!(info->flags & IEEE80211_TX_STAT_ACK);
>> if (!acked && test_sta_flag(sta, WLAN_STA_PS_STA)) {
>> /*
>> * The STA is in power save mode, so assume
>> * that this TX packet failed because of
>> that.
>> */
>> ieee80211_handle_filtered_frame(local, sta,
>> skb);
>> rcu_read_unlock();
>> return;
>> }
>
> Ah, yes, ok. So the frame simply didn't go through, for whatever
> reason. Hopefully the driver actually transmitted it :)
Yep, saw it on the air.
It was a STA sending probe requests while in PS mode and jumping to a new
channel before receiving/acking all probe responses. Hence, a probe response
ended up in the filtered queue. And it was easy to reproduce with this specific
STA (some old voip phone).
>> However, I've put the code into ieee80211_handle_filtered_frame to
>> not grow ieee80211_tx_status even more :)
>>
>> If you prefer to add it here directly I'm fine to change it.
>>
>
> No, looks fine as is. I just misunderstood how we got here.
Ok, I'd still like to change to checking IEEE80211_TX_CTL_NO_PS_BUFFER
instead -> v2 follows.
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
