Previous code set the channel type to NO_HT, but it
appears that NO_HT packets can be sent on any channel
type, so we do not need to change the channel type
as long as the channel is correct.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some were indirectly set to NO_HT (zero), but I think
it's better to explicitly set it in case the enum ever
changes.  In cfg.c, it seems the channel-type was just
ignored (and thus always set to NO_HT).
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

"ap" is the address of sdata->u.ap so it can never be NULL here.  Also
we dereferenced it on the previous line.  I removed the check.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mac80211 now supports passing MCS index to radiotap, so update the
comments regarding this
Signed-off-by: NMohammed Shafi Shajakhan <mshajakhan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since 4-addr frames completely override the source address which will
make it into the converted 802.3 frames, receiving frames for other
4-addr stations will confuse the bridging code.

To be able to handle traffic for all connected devices, the bridge
code will automatically turn on promiscuous mode, which triggers
this problem.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Reported-by: NSteve Brown <sbrown@cortland.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This allows users to tune the connection-loss algorithms
to be more or less lenient.  In particular, larger
null-func retries helps when using lots of virtual
stations on a loaded network.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This should decrease un-necessary flushes, on/off channel work,
and channel changes in cases where the only scanned channel is
the current operating channel.

* Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
  and is-scanning flags instead.

* Add helper method to determine if we are currently configured
  for the operating channel.

* Do no blindly go off/on channel in work.c  Instead, only call
  appropriate on/off code when we really need to change channels.
  Always enable offchannel-ps mode when starting work,
  and disable it when we are done.

* Consolidate ieee80211_offchannel_stop_station and
  ieee80211_offchannel_stop_beaconing, call it
  ieee80211_offchannel_stop_vifs instead.

* Accept non-beacon frames when scanning on operating channel.

* Scan state machine optimized to minimize on/off channel
  transitions.  Also, when going on-channel, go ahead and
  re-enable beaconing.  We're going to be there for 200ms,
  so seems like some useful beaconing could happen.
  Always enable offchannel-ps mode when starting software
  scan, and disable it when we are done.

* Grab local->mtx earlier in __ieee80211_scan_completed_finish
  so that we are protected when calling hw_config(), etc.

* Pass probe-responses up the stack if scanning on local
  channel, so that mlme can take a look.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I can't think of a valid use case for this aside from debugging (which can
also be done with a real monitor interface), and dropping these frames saves
some precious CPU cycles.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

While leaving oper channel, STA informs sleep state to AP to
stop sending data. Till sending ack for the nullfunc, AP
continues to send the data to STA which restarts ps_timer that
is causing unnecessary nullfunc exchange on timer expiry
when the STA was already moved to offchannel. So don't restart ps_timer
on data reception during scan. This issue was identified by
the following warning.

WARNING: at net/mac80211/tx.c:661 invoke_tx_handlers+0xf07/0x1330 [mac80211]
wlan0: Dropped data frame as no usable bitrate found while scanning and
associated. Target station: 00:03:7f:0b:a6:1b on 5 GHz band
Call Trace:
  [<ffffffffa0413ba7>] invoke_tx_handlers+0xf07/0x1330 [mac80211]
  [<ffffffffa0414056>] ieee80211_tx+0x86/0x2c0 [mac80211]
  [<ffffffffa0414345>] ieee80211_xmit+0xb5/0x1d0 [mac80211]
  [<ffffffffa04037e0>] ieee80211_dynamic_ps_enable_work+0x0/0xb0 [mac80211]
  [<ffffffffa04158cf>] ieee80211_tx_skb+0x4f/0x60 [mac80211]
  [<ffffffffa04026e6>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
  [<ffffffffa0403885>] ieee80211_dynamic_ps_enable_work+0xa5/0xb0 [mac80211]
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

On review of 'zd1211rw: implement beacon fetching and handling
ieee80211_get_buffered_bc()', Christian Lamparter noted that [1]:

   Since zd_beacon_done also uploads the next beacon so long in advance,
   there could be an equally long race between the outdated state of the
   next beacon's DTIM broadcast traffic indicator (802.11-2007 7.3.2.6)
   which -in your case- was uploaded almost a beacon interval ago and
   the xmit of ieee80211_get_buffered_bc *now*.

   The dtim bc/mc bit might be not set, when a mc/bc arrived after the
   beacon was uploaded, but before the "beacon done event" from the
   hardware. So, dozing stations don't expect the broadcast traffic
   and of course, they might miss it completely.

   It's probably better to fix this in mac80211 (see the attached hack).

[1] http://marc.info/?l=linux-wireless&m=129435041117256&w=2

CC: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

TKIP countermeasures depend on devices being able to detect Michael
MIC failures on received frames and for stations to report errors to
the AP. In order to test that behavior, it is useful to be able to
send out TKIP frames with incorrect Michael MIC. This testing behavior
has minimal effect on the TX path, so it can be added to mac80211 for
convenient use.

The interface for using this functionality is a file in mac80211
netdev debugfs (tkip_mic_test). Writing a MAC address to the file
makes mac80211 generate a dummy data frame that will be sent out using
invalid Michael MIC value. In AP mode, the address needs to be for one
of the associated stations or ff:ff:ff:ff:ff:ff to use a broadcast
frame. In station mode, the address can be anything, e.g., the current
BSSID. It should be noted that this functionality works correctly only
when associated and using TKIP.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The TKIP implementation was originally prepared to be a bit more
flexible in the way Michael MIC TX/RX keys are configured. However, we
are now taking care of the TX/RX MIC key swapping in user space, so
this code will not be needed. Similarly, there were some remaining WPA
testing code that won't be used in their current form. Remove the
unneeded extra complexity.
Signed-off-by: NJouni Malinen <jouni.malinen@atheros.com>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There's no point in disallowing scanning for a
GO interface when it's not beaconing yet.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Beacons from external BSSes are required for updating overlapping BSS
info (i.e. ERP protection). Pass them up unconditionally.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When operating in AP mode the wl1271 hardware filters out null-data
packets as well as management packets. This makes it impossible for
mac80211 to monitor the PS mode by using the PM bit of incoming frames.

Implement a HW flag to indicate that mac80211 should ignore the PM bit.
In addition, expose ieee80211_sta_ps_transition() to make low-level
drivers capable of controlling PS-mode.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When rate-control is performed in HW, we cannot calculate frame
duration as we do not have the skb transmission rate in SW.

ieee80211_tx_h_calculate_duration() should only be called when
ieee80211_tx_h_rate_ctrl() has been called before to initialize data
in skb->cb. This doesn't happen for drivers with HW rate-control.

Fixes the following warning when operating in AP-mode
in a driver with HW rate-control.

WARNING: at net/mac80211/tx.c:57 ieee80211_duration+0x54/0x1d8 [mac80211]()
Modules linked in: wl1271_sdio wl1271 firmware_class crc7 mac80211 cfg80211
[<c0046090>] (unwind_backtrace+0x0/0x124) from [<c0064c10>] (warn_slowpath_common+0x4c/0x64)
[<c0064c10>] (warn_slowpath_common+0x4c/0x64) from [<c0064c40>] (warn_slowpath_null+0x18/0x1c)
[<c0064c40>] (warn_slowpath_null+0x18/0x1c) from [<bf040e34>] (ieee80211_duration+0x54/0x1d8 [mac80211])
[<bf040e34>] (ieee80211_duration+0x54/0x1d8 [mac80211]) from [<bf04200c>] (invoke_tx_handlers+0xfa0/0x1088 [mac80211])
[<bf04200c>] (invoke_tx_handlers+0xfa0/0x1088 [mac80211]) from [<bf042178>] (ieee80211_tx+0x84/0x248 [mac80211])
[<bf042178>] (ieee80211_tx+0x84/0x248 [mac80211]) from [<bf042f44>] (ieee80211_tx_pending+0x12c/0x278 [mac80211])
[<bf042f44>] (ieee80211_tx_pending+0x12c/0x278 [mac80211]) from [<c0069a9c>] (tasklet_action+0x68/0xbc)
[<c0069a9c>] (tasklet_action+0x68/0xbc) from [<c006a044>] (__do_softirq+0x84/0x114)
[<c006a044>] (__do_softirq+0x84/0x114) from [<c006a1b8>] (do_softirq+0x48/0x54)
[<c006a1b8>] (do_softirq+0x48/0x54) from [<c006a4f8>] (local_bh_enable+0x98/0xcc)
[<c006a4f8>] (local_bh_enable+0x98/0xcc) from [<bf074e60>] (wl1271_rx+0x2e8/0x3a4 [wl1271])
[<bf074e60>] (wl1271_rx+0x2e8/0x3a4 [wl1271]) from [<bf071ae4>] (wl1271_irq_work+0x230/0x310 [wl1271])
[<bf071ae4>] (wl1271_irq_work+0x230/0x310 [wl1271]) from [<c0076864>] (process_one_work+0x208/0x350)
[<c0076864>] (process_one_work+0x208/0x350) from [<c0076e14>] (worker_thread+0x1cc/0x300)
[<c0076e14>] (worker_thread+0x1cc/0x300) from [<c007bb88>] (kthread+0x84/0x8c)
[<c007bb88>] (kthread+0x84/0x8c) from [<c0041494>] (kernel_thread_exit+0x0/0x8)
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When a vif goes away, it could cause the super-chan
to be recalculated differently, so do that calculation
on iface removal.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

I have a netgear WNDR3700 that appears to have an off-by-four
bug in how it fills out the hti->control_chan (I configure the
AP to channel 11, it reports 15 as control_chan).

Poke a message into the kernel logs to give users a
clue as to why they are not getting the expected
channel-type or rate.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If we cannot set the channel type, set the channel back to the
original.

Don't update the driver hardware if nothing actually changed.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

PS should not be enabled if an infra AP vif exists in
the interface list. So while recalculating PS,
AP vif type should be taken into account.
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NRajkumar Manoharan <rmanoharan@atheros.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This adds the MCS information we currently get
from the drivers into radiotap.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

For events that include only the local struct as
their parameter, we can use DECLARE_EVENT_CLASS
and save quite some binary size across segments
as well lines of code.

   text	   data	    bss	    dec	    hex	filename
 375745	  19296	    916	 395957	  60ab5	mac80211.ko.before
 367473	  17888	    916	 386277	  5e4e5	mac80211.ko.after
  -8272   -1408       0   -9680   -25d0 delta

Some more tracepoints with identical arguments
could be combined like this but for now this is
the one that benefits most.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some drivers (e.g. ath9k) do not always disable beacons when they're
supposed to. When an interface is changed using the change_interface op,
the mode specific sdata part is in an undefined state and trying to
get a beacon at this point can produce weird crashes.

To fix this, add a check for ieee80211_sdata_running before using
anything from the sdata.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Cc: stable@kernel.org
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Extend channel to frequency mapping for 802.11j Japan 4.9GHz band, according to
IEEE802.11 section 17.3.8.3.2 and Annex J. Because there are now overlapping
channel numbers in the 2GHz and 5GHz band we can't map from channel to
frequency without knowing the band. This is no problem as in most contexts we
know the band. In places where we don't know the band (and WEXT compatibility)
we assume the 2GHz band for channels below 14.

This patch does not implement all channel to frequency mappings defined in
802.11, it's just an extension for 802.11j 20MHz channels. 5MHz and 10MHz
channels as well as 802.11y channels have been omitted.

The following drivers have been updated to reflect the API changes:
iwl-3945, iwl-agn, iwmc3200wifi, libertas, mwl8k, rt2x00, wl1251, wl12xx.
The drivers have been compile-tested only.
Signed-off-by: NBruno Randolf <br1@einfach.org>
Signed-off-by: NBrian Prodoehl <bprodoehl@gmail.com>
Acked-by: NLuciano Coelho <coelho@ti.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This particular error isn't about multicast.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When running as a 4-addr station against an AP that has the 4-addr VLAN
interface and the main 3-addr AP interface bridged together, sometimes
frames originating from the station were looping back from the 3-addr AP
interface, causing the bridge code to emit warnings about receiving frames
with its own source address.
I'm not sure why this is happening yet, but I think it's a good idea to
drop all frames (except 802.1x/EAP frames) that do not match the configured
addressing mode, including 4-address frames sent to a 3-address station.
User test reports indicate that the problem goes away with this patch.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Currently, mac80211 always advertises that it may send
up to 64 subframes in an aggregate. This is fine, since
it's the max, but might as well be set to zero instead
since it doesn't have any information.

However, drivers might have that information, so allow
them to set a variable giving it, which will then be
used. The default of zero will be fine since to the
peer that means we don't know and it will just use its
own limit for the buffer size.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The aggregation code currently doesn't implement the
buffer size negotiation. It will always request a max
buffer size (which is fine, if a little pointless, as
the mac80211 code doesn't know and might just use 0
instead), but if the peer requests a smaller size it
isn't possible to honour this request.

In order to fix this, look at the buffer size in the
addBA response frame, keep track of it and pass it to
the driver in the ampdu_action callback when called
with the IEEE80211_AMPDU_TX_OPERATIONAL action. That
way the driver can limit the number of subframes in
aggregates appropriately.

Note that this doesn't fix any drivers apart from the
addition of the new argument -- they all need to be
updated separately to use this variable!
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When mesh is disabled, mac80211 was returning
beacons with an empty mesh ID. That isn't
desirable, even if drivers shouldn't be trying
to get beacons to start with.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Signed-off-by: NBen Greear <greearb@candelatech.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

mppath is mesh related parameter and maybe unused
Signed-off-by: NWey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Some devices don't support the maximum AMDPU buffer size of 64, so we
need to add an option to configure this in the hardware configuration.
This value will be used in the ADDBA response instead of the value
suggested in the request, if the latter is greater than the max
supported.
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Tested-by: NJuuso Oikarinen <juuso.oikarinen@nokia.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Replace MESH_WORK_GROW_MPATH_TABLE by MESH_WORK_GROW_MPP_TABLE in
mesh_mpp_table_grow call condition.

(Clearly the original was a typo... -- JWL)
Signed-off-by: NNickolay Ledovskikh <nledovskikh@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Rewrote code for checking if the destination is proxied by a mesh portal, to facilitate better
understanding of the functionality.
Signed-off-by: NJoel A Fernandes <agnel.joel@gmail.com>
Acked-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the buffer size is set to zero in the block ack parameter set
field, we should use the maximum supported number of subframes.  The
existing code was bogus and was doing some unnecessary calculations
that lead to wrong values.

Thanks Johannes for helping me figure this one out.

Cc: stable@kernel.org
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: NLuciano Coelho <coelho@ti.com>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Since the introduction of the fixes for the
reorder timer, mac80211 will cause lockdep
warnings because lockdep confuses
local->skb_queue and local->rx_skb_queue
and treats their lock as the same.

However, their locks are different, and are
valid in different contexts (the former is
used in IRQ context, the latter in BH only)
and the only thing to be done is mark the
former as a different lock class so that
lockdep can tell the difference.
Reported-by: NLarry Finger <Larry.Finger@lwfinger.net>
Reported-by: NSujith <m.sujith@gmail.com>
Reported-by: NMiles Lane <miles.lane@gmail.com>
Tested-by: NSujith <m.sujith@gmail.com>
Tested-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Somehow this snuck into my earlier patch, and
only now did I see a compiler warning:

net/mac80211/led.c:218:13: warning: function '__ieee80211_create_tpt_led_trigger' with external linkage has definition

Remove the stray extern.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When the driver has remain-on-channel offload,
implement off-channel transmission using that
primitive.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>