The probe response/beacon management frame RX code passes a
bool parameter to differentiate beacons and probe responses.
This is useless since we have the frame and can thus use its
frame control field. Moreover it is buggy since there is one
call to ieee80211_rx_bss_info with a beacon frame that is
indicated as a probe response, which is also fixed by using
the frame control field, so do that.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If there are VLANs, stopping an AP is inefficient as it
calls rcu_barrier() once for each interface (the VLANs
and the AP itself). Optimise this by moving rcu_barrier()
out of the station cleanups and calling it only once for
all interfaces combined.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In a file that's only built when CONFIG_MAC80211_MESH
is defined, having an #ifdef on the same is entirely
pointless, so remove it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The last fixes re-added the RCU synchronize penalty
on roaming to fix the races. Split up sta_info_flush()
now to get rid of that again, and let managed mode
(and only it) delay the actual destruction.
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When an interface is brought down it must have been
disconnected (or similar) in all modes other than WDS,
so warn if any stations were removed in other modes.
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When all interfaces have been removed, there can't
be any stations left over, so there's no need to
flush again. Remove this, and all code associated
with it, which also simplifies the function.
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Use short slot time in 5GHz for mesh. The performance is
increased from 16.4Mbps to 23.4Mbps for two directly
connected mesh STAs operating in legacy rate using iperf
measurement. Almost similar to the results claimed in IBSS
mode.
Signed-off-by: NChun-Yeow Yeoh <yeohchunyeow@gmail.com>
[call ieee80211_get_sdata_band() only once]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This allows user-space (wpa_supplicant) to disable
short guard interval (SGI) for 20Mhz.  The SGI-40
disable option is already handled.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The maximum MTU shouldn't take the headers into account,
the maximum MSDU size is exactly the maximum MTU.
Signed-off-by: NT Krishna Chaitanya <chaitanyatk@posedge.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When AP's SSID is hidden the BSS can appear several times in
cfg80211's BSS list: once with a zero-length SSID that comes
from the beacon, and once for each SSID from probe reponses.

Since the mac80211 stores its data in ieee80211_bss which
is embedded into cfg80211_bss, mac80211's data will be
duplicated too.

This becomes a problem when a driver needs the dtim_period
since this data exists only in the beacon's instance in
cfg80211 bss table which isn't the instance that is used
when associating.

Remove the DTIM period from the BSS table and track it
explicitly to avoid this problem.

Cc: stable@vger.kernel.org
Tested-by: NEfi Tubul <efi.tubul@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This is a very old bug, but there's nothing that prevents the
timer from running while the module is being removed when we
only do del_timer() instead of del_timer_sync().

The timer should normally not be running at this point, but
it's not clearly impossible (or we could just remove this.)

Cc: stable@vger.kernel.org
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Unfortunately, commit b22cfcfc, intended to speed up roaming
by avoiding the synchronize_rcu() broke AP/mesh modes as it moved
some code into that work item that will still call into the driver
at a time where it's no longer expected to handle this: after the
AP or mesh has been stopped.

To fix this problem remove the per-station work struct, maintain a
station cleanup list instead and flush this list when stations are
flushed. To keep this patch smaller for stable, do this when the
stations are flushed (sta_info_flush()). This unfortunately brings
back the original roaming delay; I'll fix that again in a separate
patch.

Also, Ben reported that the original commit could sometimes (with
many interfaces) cause long delays when an interface is set down,
due to blocking on flush_workqueue(). Since we now maintain the
cleanup list, this particular change of the original patch can be
reverted.

Cc: stable@vger.kernel.org [3.7]
Reported-by: NBen Greear <greearb@candelatech.com>
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The array of rmc_entrys is redundant since only the
list_head is used. Make this an array of list_heads
instead and save ~6k per vif at runtime :D
Signed-off-by: NThomas Pedersen <thomas@cozybit.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Make AP_VLAN type interfaces track the AP master channel
context so they have one assigned for the various lookups.
Don't give them their own refcount etc. since they're just
slaves to the AP master.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
[change to flush stations with AP flush in second loop]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Do not scan on no-IBSS and disabled channels in IBSS mode. Doing this
can trigger Microcode errors on iwlwifi and iwlegacy drivers.

Also rename ieee80211_request_internal_scan() function since it is only
used in IBSS mode and simplify calling it from ieee80211_sta_find_ibss().

This patch should address:
https://bugzilla.redhat.com/show_bug.cgi?id=883414
https://bugzilla.kernel.org/show_bug.cgi?id=49411Reported-by: NJesse Kahtava <jesse_kahtava@f-m.fm>
Reported-by: NMikko Rapeli  <mikko.rapeli@iki.fi>
Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This patch removes the redundant occurences of simple_strto<foo>
Signed-off-by: NAbhijit Pawar <abhi.c.pawar@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Instead of updating stats before sending a packet,
update them after processing the packet's status.
This makes minstrel in line with minstrel_ht.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This patch replace the obsolete simple_strto<foo> with kstrto<foo>
Signed-off-by: NAbhijit Pawar <abhi.c.pawar@gmail.com>
Acked-by: NNeil Horman <nhorman@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

New drivers that might not support ampdu_action yet while in
development cause a lot of warnings, use WARN_ON_ONCE instead.
Signed-off-by: NT Krushna Chaitanya <chaitanyatk@posedge.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If the sdata work is pending while the interface is stopped,
we currently flush it. If it's not running this means waiting
for it to run, which could take a while if the workqueue is
backlogged. However, the work exits right away if it starts
to run while the interface is already stopping. There's no
point in waiting for that, so use cancel_work_sync() instead.
Reported-by: NBen Greear <greearb@candelatech.com>
Tested-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Previously, mesh peering frames from a STA without a station
entry were being dropped.

Mesh Peering Open and other frames (WLAN_CATEGORY_SELF_PROTECTED)
are valid mesh peering frames even if received from a yet unknown
station; the STA entry will be created in mesh_peer_init later.

The problem didn't occur previously since both STAs receive each
other's beacons which created the STA entry. However, this causes
an unnecessary delay and beacons might not be received if either
node is in PS mode.
Signed-off-by: NMarco Porsch <marco.porsch@etit.tu-chemnitz.de>
[reword commit log a bit]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The radiotap header length "needed_headroom" is only required if we're
sending the skb to a monitor interface. Hence, move the calculation a
bit later so the calculation can be skipped if no monitor interface is
present.
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Commit f0425bed "mac80211: retry sending
failed BAR frames later instead of tearing down aggr" caused regression
on rt2x00 hardware (connection hangs). This regression was fixed by
commit be03d4a4 "rt2x00: Don't let
mac80211 send a BAR when an AMPDU subframe fails". But the latter
commit caused yet another problem reported in
https://bugzilla.kernel.org/show_bug.cgi?id=42828#c22

After long discussion in this thread:
http://mid.gmane.org/20121018075615.GA18212@redhat.com
and testing various alternative solutions, which failed on one or other
setup, we have no other good fix for the issues like just revert both
mentioned earlier commits.

To do not affect other hardware which benefit from commit
f0425bed, instead of reverting it,
introduce flag that when used will restore mac80211 behaviour before
the commit.

Cc: stable@vger.kernel.org
Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
[replaced link with mid.gmane.org that has message-id]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The mic failure count provides the number of mic failures that
have happened on a given key (without a countermeasure being
started, since that would remove the key).
Signed-off-by: NSaravana <saravanad@posedge.com>
[fix NULL pointer issues]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

In 5GHz/802.11a, we are allowed to use short slot times. Doing this
may increases performance by 20% for legacy connections (54 MBit/s).
I can confirm this in my tests (27% more throughput using iperf), and
also have a small positive effect (5% more throughput) for HT rates,
tested on 1 stream.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NMathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

If channel contexts are enabled, the CSA should not be processed
further. A return is missing here.
Signed-off-by: NSimon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

When a BSS struct is updated, the IEs are currently
overwritten or freed. This can lead to races if some
other CPU is accessing the BSS struct and using the
IEs concurrently.

Fix this by always allocating the IEs in a new struct
that holds the data and length and protecting access
to this new struct with RCU.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of allocating a temporary buffer to build IEs
build them right into the SKB.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Instead of assuming 200 bytes are always enough for
all the IEs we add, give the length of the buffer
to the function and warn instead of overrunning.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This change allows userspace to register for probe request
frames on an IBSS interface. Userspace then has to handle
them and send replies.
Signed-off-by: NAntonio Quartulli <antonio@open-mesh.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently the mesh sync code checks, whether peers indicate TBTT adjustment,
but it never sets the corresponding flag itself.

By setting ifmsh->tbtt_adjusting to true, it will set the corresponding field
in the mesh configuration IE of own beacons.
This indication will be set in the current beacon. The TBTT adjustment will be
performed afterwards, affecting the next beacon. Thus, the first beacon with
stable TBTT will not indicate adjustment anymore and peers will continue
tracking the new offset.
Signed-off-by: NMarco Porsch <marco.porsch@etit.tu-chemnitz.de>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add a debugfs file showing the rate at which
the last packet is received.
Signed-off-by: NSaravana <saravanad@posedge.com>
[fix whitespace]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Currently the logic to fill a struct rate_info with
a STA's last RX rate is accessible only in the cfg.c.
As the RX rate calculation might be needed elsewhere,
split this out into a separate function.
Signed-off-by: NSaravana <saravanad@posedge.com>
[fix various whitespace issues, reword commit log]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add a debugfs file showing the current tx rate.
The information available in the rc_stats file
doesn't evidently provides us the current tx rate.
This patch adds the support for the same.
Signed-off-by: NSaravana <saravanad@posedge.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

Add a debugfs file showing the signal strength
of the ack frame that is received for the
currently sent tx packet
Signed-off-by: NSaravana <saravanad@posedge.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

This fixes some unintended resets of the rate control statistics
when minstrel_ht is used resulting in non-optimal throughput on mesh
links.
Tested-by: NEmanuel Taube <emanuel.taube@gmail.com>
Signed-off-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>