linux-toradex.git/net/mac80211, branch v3.10.24

mac80211: fix crash if bitrate calculation goes wrong

2013-11-13T03:05:30+00:00

commit d86aa4f8ca58898ec6a94c0635da20b948171ed7 upstream.

If a frame's timestamp is calculated, and the bitrate
calculation goes wrong and returns zero, the system
will attempt to divide by zero and crash. Catch this
case and print the rate information that the driver
reported when this happens.

Reported-by: Thomas Lindroth 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: update sta->last_rx on acked tx frames

2013-11-13T03:05:30+00:00

commit 0c5b93290b2f3c7a376567c03ae8d385b0e99851 upstream.

When clients are idle for too long, hostapd sends nullfunc frames for
probing. When those are acked by the client, the idle time needs to be
updated.

To make this work (and to avoid unnecessary probing), update sta->last_rx
whenever an ACK was received for a tx packet. Only do this if the flag
IEEE80211_HW_REPORTS_TX_ACK_STATUS is set.

Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: use sta_info_get_bss() for nl80211 tx and client probing

2013-11-13T03:05:30+00:00

commit 03bb7f42765ce596604f03d179f3137d7df05bba upstream.

This allows calls for clients in AP_VLANs (e.g. for 4-addr) to succeed

Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: drop spoofed packets in ad-hoc mode

2013-11-13T03:05:30+00:00

commit 6329b8d917adc077caa60c2447385554130853a3 upstream.

If an Ad-Hoc node receives packets with the Cell ID or its own MAC
address as source address, it hits a WARN_ON in sta_info_insert_check()
With many packets, this can massively spam the logs. One way that this
can easily happen is through having Cisco APs in the area with rouge AP
detection and countermeasures enabled.
Such Cisco APs will regularly send fake beacons, disassoc and deauth
packets that trigger these warnings.

To fix this issue, drop such spoofed packets early in the rx path.

Reported-by: Thomas Huehn 
Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: correctly close cancelled scans

2013-11-13T03:05:30+00:00

commit a754055a1296fcbe6f32de3a5eaca6efb2fd1865 upstream.

__ieee80211_scan_completed is called from a worker. This
means that the following flow is possible.

 * driver calls ieee80211_scan_completed
 * mac80211 cancels the scan (that is already complete)
 * __ieee80211_scan_completed runs

When scan_work will finally run, it will see that the scan
hasn't been aborted and might even trigger another scan on
another band. This leads to a situation where cfg80211's
scan is not done and no further scan can be issued.

Fix this by setting a new flag when a HW scan is being
cancelled so that no other scan will be triggered.

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

mac80211: add a flag to indicate CCK support for HT clients

2013-09-08T05:09:59+00:00

commit 2dfca312a91631311c1cf7c090246cc8103de038 upstream.

brcm80211 cannot handle sending frames with CCK rates as part of an
A-MPDU session. Other drivers may have issues too. Set the flag in all
drivers that have been tested with CCK rates.

This fixes a reported brcmsmac regression introduced in
commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
"mac80211/minstrel_ht: fix cck rate sampling"

Reported-by: Tom Gundersen 
Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: add missing channel context release

2013-09-08T05:09:59+00:00

commit 2a3ba63c235fdcd37f6451bdf4a0c7865a3930cf upstream.

IBSS needs to release the channel context when leaving
but I evidently missed that. Fix it.

Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: don't wait for TX status forever

2013-08-29T16:47:29+00:00

commit cb236d2d713cff83d024a82b836757d9e2b50715 upstream.

TX status notification can get lost, or the frames could
get stuck on the queue, so don't wait for the callback
from the driver forever and instead time out after half
a second.

Signed-off-by: Johannes Berg 
Signed-off-by: Luciano Coelho 
Signed-off-by: Greg Kroah-Hartman

mac80211: continue using disabled channels while connected

2013-08-20T15:43:03+00:00

commit ddfe49b42d8ad4bfdf92d63d4a74f162660d878d upstream.

In case the AP has different regulatory information than we do,
it can happen that we connect to an AP based on e.g. the world
roaming regulatory data, and then update our database with the
AP's country information disables the channel the AP is using.
If this happens on an HT AP, the bandwidth tracking code will
hit the WARN_ON() and disconnect. Since that's not very useful,
ignore the channel-disable flag in bandwidth tracking.

Reported-by: Chris Wright 
Tested-by: Chris Wright 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix infinite loop in ieee80211_determine_chantype

2013-08-20T15:43:03+00:00

commit b56e4b857c5210e848bfb80e074e5756a36cd523 upstream.

Commit "3d9646d mac80211: fix channel selection bug" introduced a possible
infinite loop by moving the out target above the chandef_downgrade
while loop.  When we downgrade to NL80211_CHAN_WIDTH_20_NOHT, we jump
back up to re-run the while loop...indefinitely.  Replace goto with
break and carry on.  This may not be sufficient to connect to the AP,
but will at least keep the cpu from livelocking.  Thanks to Derek Atkins
as an extra pair of debugging eyes.

Signed-off-by: Chris Wright 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman