linux-stable.git/net/mac80211, branch v4.9.147

mac80211: Fix condition validating WMM IE

2018-12-21T13:11:32+00:00

[ Upstream commit 911a26484c33e10de6237228ca1d7293548e9f49 ]

Commit c470bdc1aaf3 ("mac80211: don't WARN on bad WMM parameters from
buggy APs") handled cases where an AP reports a zeroed WMM
IE. However, the condition that checks the validity accessed the wrong
index in the ieee80211_tx_queue_params array, thus wrongly deducing
that the parameters are invalid. Fix it.

Fixes: c470bdc1aaf3 ("mac80211: don't WARN on bad WMM parameters from buggy APs")
Signed-off-by: Ilan Peer 
Signed-off-by: Luca Coelho 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

mac80211: don't WARN on bad WMM parameters from buggy APs

2018-12-21T13:11:32+00:00

[ Upstream commit c470bdc1aaf36669e04ba65faf1092b2d1c6cabe ]

Apparently, some APs are buggy enough to send a zeroed
WMM IE. Don't WARN on this since this is not caused by a bug
on the client's system.

This aligns the condition of the WARNING in drv_conf_tx
with the validity check in ieee80211_sta_wmm_params.
We will now pick the default values whenever we get
a zeroed WMM IE.

This has been reported here:
https://bugzilla.kernel.org/show_bug.cgi?id=199161

Fixes: f409079bb678 ("mac80211: sanity check CW_min/CW_max towards driver")
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

mac80211: ignore NullFunc frames in the duplicate detection

2018-12-13T08:20:30+00:00

commit 990d71846a0b7281bd933c34d734e6afc7408e7e upstream.

NullFunc packets should never be duplicate just like
QoS-NullFunc packets.

We saw a client that enters / exits power save with
NullFunc frames (and not with QoS-NullFunc) despite the
fact that the association supports HT.
This specific client also re-uses a non-zero sequence number
for different NullFunc frames.
At some point, the client had to send a retransmission of
the NullFunc frame and we dropped it, leading to a
misalignment in the power save state.
Fix this by never consider a NullFunc frame as duplicate,
just like we do for QoS NullFunc frames.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449

CC: 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix reordering of buffered broadcast packets

2018-12-13T08:20:30+00:00

commit 9ec1190d065998650fd9260dea8cf3e1f56c0e8c upstream.

If the buffered broadcast queue contains packets, letting new packets bypass
that queue can lead to heavy reordering, since the driver is probably throttling
transmission of buffered multicast packets after beacons.

Keep buffering packets until the buffer has been cleared (and no client
is in powersave mode).

Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext

2018-12-13T08:20:30+00:00

commit a317e65face482371de30246b6494feb093ff7f9 upstream.

Make it behave like regular ieee80211_tx_status calls, except for the lack of
filtered frame processing.
This fixes spurious low-ack triggered disconnections with powersave clients
connected to an AP.

Fixes: f027c2aca0cf4 ("mac80211: add ieee80211_tx_status_noskb")
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: Clear beacon_int in ieee80211_do_stop

2018-12-13T08:20:30+00:00

commit 5c21e8100dfd57c806e833ae905e26efbb87840f upstream.

This fixes stale beacon-int values that would keep a netdev
from going up.

To reproduce:

Create two VAP on one radio.
vap1 has beacon-int 100, start it.
vap2 has beacon-int 240, start it (and it will fail
  because beacon-int mismatch).
reconfigure vap2 to have beacon-int 100 and start it.
  It will fail because the stale beacon-int 240 will be used
  in the ifup path and hostapd never gets a chance to set the
  new beacon interval.

Cc: stable@vger.kernel.org
Signed-off-by: Ben Greear 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix TX aggregation start/stop callback race

2018-11-10T15:42:47+00:00

[ Upstream commit 7a7c0a6438b8e7636d5a22e572892cc234f68297 ]

When starting or stopping an aggregation session, one of the steps
is that the driver calls back to mac80211 that the start/stop can
proceed. This is handled by queueing up a fake SKB and processing
it from the normal iface/sdata work. Since this isn't flushed when
disassociating, the following race is possible:

 * associate
 * start aggregation session
 * driver callback
 * disassociate
 * associate again to the same AP
 * callback processing runs, leading to a WARN_ON() that
   the TID hadn't requested aggregation

If the second association isn't to the same AP, there would only
be a message printed ("Could not find station: "), but the
same race could happen.

Fix this by not going the whole detour with a fake SKB etc. but
simply looking up the aggregation session in the driver callback,
marking it with a START_CB/STOP_CB bit and then scheduling the
regular aggregation work that will now process these bits as well.
This also simplifies the code and gets rid of the whole problem
with allocation failures of said skb, which could have left the
session in limbo.

Reported-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

mac80211: TDLS: fix skb queue/priority assignment

2018-11-10T15:42:41+00:00

[ Upstream commit cb59bc14e830028d2244861216df038165d7625d ]

If the TDLS setup happens over a connection to an AP that
doesn't have QoS, we nevertheless assign a non-zero TID
(skb->priority) and queue mapping, which may confuse us or
drivers later.

Fix it by just assigning the special skb->priority and then
using ieee80211_select_queue() just like other data frames
would go through.

Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

mac80211: fix pending queue hang due to TX_DROP

2018-11-10T15:42:41+00:00

[ Upstream commit 6eae4a6c2be387fec41b0d2782c4fffb57159498 ]

In our environment running lots of mesh nodes, we are seeing the
pending queue hang periodically, with the debugfs queues file showing
lines such as:

    00: 0x00000000/348

i.e. there are a large number of frames but no stop reason set.

One way this could happen is if queue processing from the pending
tasklet exited early without processing all frames, and without having
some future event (incoming frame, stop reason flag, ...) to reschedule
it.

Exactly this can occur today if ieee80211_tx() returns false due to
packet drops or power-save buffering in the tx handlers.  In the
past, this function would return true in such cases, and the change
to false doesn't seem to be intentional.  Fix this case by reverting
to the previous behavior.

Fixes: bb42f2d13ffc ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue")
Signed-off-by: Bob Copeland 
Acked-by: Toke Høiland-Jørgensen 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin

mac80211: Always report TX status

2018-11-10T15:42:41+00:00

[ Upstream commit 8682250b3c1b75a45feb7452bc413d004cfe3778 ]

If a frame is dropped for any reason, mac80211 wouldn't report the TX
status back to user space.

As the user space may rely on the TX_STATUS to kick its state
machines, resends etc, it's better to just report this frame as not
acked instead.

Signed-off-by: Andrei Otcheretianski 
Signed-off-by: Luca Coelho 
Signed-off-by: Johannes Berg 
Signed-off-by: Sasha Levin