kernel/git/stable/linux-stable.git/net/mac80211/offchannel.c, branch linux-3.16.y

mac80211: fix on-channel remain-on-channel

2014-05-14T13:48:38+00:00

Jouni reported that if a remain-on-channel was active on the same channel as the current operating channel, then the ROC would start, but any frames transmitted using mgmt-tx on the same channel would get delayed until after the ROC. The reason for this is that the ROC starts, but doesn't have any handling for "remain on the same channel", so it stops the interface queues. The later mgmt-tx then puts the frame on the interface queues (since it's on the current operating channel) and thus they get delayed until after the ROC. To fix this, add some logic to handle remaining on the same channel specially and not stop the queues etc. in this case. This not only fixes the bug but also improves behaviour in this case as data frames etc. can continue to flow. Cc: stable@vger.kernel.org Reported-by: Jouni Malinen Tested-by: Jouni Malinen Signed-off-by: Johannes Berg

mac80211: fix software remain-on-channel implementation

2014-04-09T08:47:47+00:00

Jouni reported that when doing off-channel transmissions mixed with on-channel transmissions, the on-channel ones ended up on the off-channel in some cases. The reason for that is that during the refactoring of the off- channel code, I lost the part that stopped all activity and as a consequence the on-channel frames (including data frames) were no longer queued but would be transmitted on the temporary channel. Fix this by simply restoring the lost activity stop call. Cc: stable@vger.kernel.org Fixes: 2eb278e083549 ("mac80211: unify SW/offload remain-on-channel") Reported-by: Jouni Malinen Signed-off-by: Johannes Berg

mac80211: Run deferred scan if last roc_list item is not started

2013-09-30T10:36:56+00:00

mac80211 scan processing could get stuck if roc work for pending, but not started when a scan request was deferred due to such roc item. Normally the deferred scan would be started from ieee80211_start_next_roc(), but ieee80211_sw_roc_work() calls that only if the finished ROC was started. Fix this by calling ieee80211_run_deferred_scan() in the case the last ROC was not actually started. This issue was hit relatively easily in P2P find operations where Listen state (remain-on-channel) and Search state (scan) are repeated in a loop. Signed-off-by: Jouni Malinen Signed-off-by: Johannes Berg

Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next

2013-04-10T18:09:54+00:00

Conflicts: drivers/net/wireless/ath/carl9170/debug.c drivers/net/wireless/ath/carl9170/main.c net/mac80211/ieee80211_i.h

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless

2013-04-10T13:31:39+00:00

Conflicts: drivers/net/wireless/rt2x00/rt2x00pci.c

mac80211: purge remain-on-channel items when suspending

2013-04-08T07:17:00+00:00

They can't really be executed while suspended and could trigger work warnings, so abort all ROC items. When the system resumes the notifications about this will be delivered to userspace which can then act accordingly (though it will assume they were canceled/finished.) Signed-off-by: Johannes Berg

mac80211: fix remain-on-channel cancel crash

2013-03-25T12:50:33+00:00

If a ROC item is canceled just as it expires, the work struct may be scheduled while it is running (and waiting for the mutex). This results in it being run after being freed, which obviously crashes. To fix this don't free it when aborting is requested but instead mark it as "to be freed", which makes the work a no-op and allows freeing it outside. Cc: stable@vger.kernel.org [3.6+] Reported-by: Jouni Malinen Tested-by: Jouni Malinen Signed-off-by: Johannes Berg

mac80211: stop queues temporarily for flushing

2013-03-18T19:15:05+00:00

Sometimes queues are flushed in the middle of operation, which can lead to driver issues. Stop queues temporarily, while flushing, to avoid transmitting new packets while they are being flushed. Signed-off-by: Johannes Berg

mac80211: pass queue bitmap to flush operation

2013-03-18T19:15:03+00:00

There are a number of situations in which mac80211 only really needs to flush queues for one virtual interface, and in fact during this frames might be transmitted on other virtual interfaces. Calculate and pass a queue bitmap to the driver so it knows which queues to flush. Signed-off-by: Johannes Berg

mac80211: Allow drivers to differentiate between ROC types

2013-03-06T15:35:49+00:00

Some devices can handle remain on channel requests differently based on the request type/priority. Add support to differentiate between different ROC types, i.e., indicate that the ROC is required for sending managment frames. Signed-off-by: Ilan Peer Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg