| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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).
Change-Id: I7ef15c9540c4300a29ffd27754b25fd02afbf34f
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the driver advertised support for a CAB queue, then we
should put all multicast frames there, otherwise sending
them can be racy with clients going to sleep while we TX
a frame. To avoid this, always TX multicast frames on the
multicast queue.
It seems like even drivers not using the queue framework
might want to do this which would mean also moving the
IEEE80211_TX_CTL_SEND_AFTER_DTIM flag assignment, but it
also seems that drivers behave differently here so that
just moving it wouldn't be a good idea. It'd be better to
modify those drivers to use the queue framework.
Change-Id: I7993bfb8af3ab67564698d6ff64136d976ff671f
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 6b07d9ca9b5363dda959b9582a3fc9c0b89ef3b5 upstream.
The code currently assumes that buffered multicast PS frames don't have
a pending ACK frame for tx status reporting.
However, hostapd sends a broadcast deauth frame on teardown for which tx
status is requested. This can lead to the "Have pending ack frames"
warning on module reload.
Fix this by using ieee80211_free_txskb/ieee80211_purge_tx_queue.
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
commit 3633ebebab2bbe88124388b7620442315c968e8f upstream.
We already set a station to be associated when peering completes, both
in user space and in the kernel. Thus we should always have an
associated sta before sending data frames to that station.
Failure to check assoc state can cause crashes in the lower-level driver
due to transmitting unicast data frames before driver sta structures
(e.g. ampdu state in ath9k) are initialized. This occurred when
forwarding in the presence of fixed mesh paths: frames were transmitted
to stations with whom we hadn't yet completed peering.
Reported-by: Alexis Green <agreen@cococorp.com>
Tested-by: Jesse Jones <jjones@cococorp.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Stefan Guendhoer <stefan@guendhoer.com>
|
| |
|
