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>

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>

This allows drivers to support remain-on-channel
offload if they implement smarter timing or need
to use a device implementation like iwlwifi.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The key documentation is slightly out of date, fix
that. Also, the list entry in the key struct is no
longer used that way, so list_del_init() isn't
necessary any more there.

Finally, ieee80211_key_link() is no longer invoked
under RCU read lock, but rather with an appropriate
station lock held.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This reverts enables the reorder release timer once again.

The issues laid out in:
<http://www.spinics.net/lists/linux-wireless/msg57214.html>

Have been addressed by:
	mac80211: serialize rx path workers
	mac80211: ignore PSM bit of reordered frames
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch addresses the issue of serialization between
the main rx path and various reorder release timers.

<http://www.spinics.net/lists/linux-wireless/msg57214.html>

It converts the previously local "frames" queue into
a global rx queue [rx_skb_queue]. This way, everyone
(be it the main rx-path or some reorder release timeout)
can add frames to it.

Only one active rx handler worker [ieee80211_rx_handlers]
is needed. All other threads which have lost the race of
"runnning_rx_handler" can now simply "return", knowing that
the thread who had the "edge" will also take care of their
workload.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Fixed a bug where if a mesh interface has a different MAC address from its bridge
interface, then it would not be able to send data traffic to any other mesh node.
This also adds support for communication between mesh nodes and external bridged
nodes by using a 6 address format if the source is a node within the mesh and the
destination is an external node proxied by a mesh portal.
Signed-off-by: NJoel A Fernandes <agnel.joel@gmail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

This patch tackles one of the problems of my
reorder release timer patch from August.

<http://www.spinics.net/lists/linux-wireless/msg57214.html>
=>
What if the reorder release triggers and ap_sta_ps_end
(called by ieee80211_rx_h_sta_process) accidentally clears
the WLAN_STA_PS_STA flag, because 100ms ago - when the STA
was still active - frames were put into the reorder buffer.
Signed-off-by: NChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

commit ad0e2b5a
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Tue Jun 1 10:19:19 2010 +0200

    mac80211: simplify key locking

removed the synchronization against RCU and thus
opened a race window where we can use a key for
TX while it is already freed. Put a synchronisation
into the right place to close that window.
Reported-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
Cc: stable@kernel.org [2.6.36+]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit b51aff05 said:

    Under memory pressure, the mac80211 mesh code
    may helpfully print a message that it failed
    to clone a mesh frame and then will proceed
    to crash trying to use it anyway. Fix that.

Avoid the reference whenever the frame copy is unsuccessful
regardless of the debug message being suppressed or printed.

Cc: stable@kernel.org [2.6.27+]
Signed-off-by: NMilton Miller <miltonm@bga.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

There's a redundant rcu_read_lock/unlock pair, a
redundant variable, and a few redundant accesses
to the 1d_to_ac array. Fix this to make the code
neater and easier to follow.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If CONFIG_MAC80211_LEDS is not set, ieee80211_i.h was failing to compile,
because struct led_trigger is only declared when CONFIG_LEDS_TRIGGERS is
set.

This patch adds ifdefs around the tpt_led_trigger declaration in
ieee80211_i.h to avoid the problem.
Signed-off-by: NLuciano Coelho <luciano.coelho@nokia.com>
Acked-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The throughput LED trigger was always active when
the radio was enabled. In most cases that's likely
the desired behaviour, but iwlwifi requires it to
be only active when one of the virtual interfaces
is actually "connected" in some way.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

iwlwifi and other drivers like to blink their LED
based on throughput. Implement this generically in
mac80211, based on a throughput table the driver
specifies. That way, drivers can set the blink
frequencies depending on their desired behaviour
and max throughput.

All the drivers need to do is provide an LED class
device, best with blink hardware offload.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The throughput trigger will require doing LED
classdev/trigger handling before register_hw(),
so drivers should have access to the trigger
names before it. If trigger registration fails,
this will still make the trigger name available,
but that's not a big problem since the default
trigger will the simply not be found.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Under memory pressure, the mac80211 mesh code
may helpfully print a message that it failed
to clone a mesh frame and then will proceed
to crash trying to use it anyway. Fix that.

Cc: stable@kernel.org [2.6.27+]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Acked-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When an skb is shared, it needs to be duplicated, along with its data buffer.
If the skb does not have enough headroom, using skb_copy might cause the data
buffer to be copied twice (once by skb_copy and once by pskb_expand_head).
Fix this by using skb_clone initially and letting ieee80211_skb_resize sort
out the rest.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

If the skb is not cloned and we don't need any extra headroom, there
is no point in reallocating the skb head.
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The change 'mac80211: Fix BUG in pskb_expand_head when transmitting shared skbs'
added a check for copying the skb if it's shared, however the tx info variable
still points at the cb of the old skb
Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
Acked-by: NHelmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The Mesh Control header only includes 0, 1 or 2 addresses. If there is
one address, it should be interpreted as Address 4.  If there are 2,
they are interpreted as Addresses 5 and 6 (Address 4 being the 4th
address in the 802.11 header).

The address extension used to hold up to 3 addresses instead of the current 2.
I'm not sure which draft version changed this, but it is very unlikely that it
will change again given the state of the approval process of this draft.  See
section 7.1.3.6.3 in current draft (8.0).

Also, note that the extra address that I'm removing was not being used, so this
change has no effect on over-the-air frame formats.  But I thought I better
remove it before someone does start using it.
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Let path selection frames for protocols other than HWMP be sent to
userspace via NL80211_CMD_REGISTER_FRAME.  Also allow userspace to send
and receive mesh path selection frames.
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Userspace will now be allowed to toggle between the default path
selection algorithm (HWMP, implemented in the kernel), and a vendor
specific alternative.  Also in the same patch, allow userspace to add
information elements to mesh beacons.  This is accordance with the
Extensible Path Selection Framework specified in version 7.0 of the
802.11s draft.
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Mesh parameters can be to setup a mesh or to configure it.
This patch renames the ambiguous name mesh_params to mesh_config
in preparation for mesh_setup.
Signed-off-by: NJavier Cardona <javier@cozybit.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Add a new notification to indicate that a received, unprotected
Deauthentication or Disassociation frame was dropped due to
management frame protection being in use. This notification is
needed to allow user space (e.g., wpa_supplicant) to implement
SA Query procedure to recover from association state mismatch
between an AP and STA.

This is needed to avoid getting stuck in non-working state when MFP
(IEEE 802.11w) is used and a protected Deauthentication or
Disassociation frame is dropped for any reason. After that, the
station would silently discard any unprotected Deauthentication or
Disassociation frame that could be indicating that the AP does not
have association for the STA (when the Reason Code would be 6 or 7).
IEEE Std 802.11w-2009, 11.13 describes this recovery mechanism.
Signed-off-by: NJouni Malinen <j@w1.fi>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Commit 00d3f14c has removed the references of this macro,
but left it only. So remove this definition.

commit 00d3f14c
Author: Johannes Berg <johannes@sipsolutions.net>
Date:   Tue Feb 10 21:26:00 2009 +0100

    mac80211: use cfg80211s BSS infrastructure

    Remove all the code from mac80211 to keep track of BSSes
    and use the cfg80211-provided code completely.
Signed-off-by: NShan Wei <shanwei@cn.fujitsu.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

Allow drivers or rate control algorithms to specify BlockAck session
timeout when initiating an ADDBA transaction. This is useful in cases
where maintaining persistent BA sessions does not incur any overhead.

The current timeout value of 5000 TUs is retained for all non ath9k/ath9k_htc
drivers.
Signed-off-by: NSujith Manoharan <Sujith.Manoharan@atheros.com>
Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

With the upcoming hardware offload implementation,
some devices will have a different maximum duration
for the remain-on-channel command. Advertise the
maximum duration in mac80211, and make mac80211 set
it.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

When software crypto is used, mac80211 will
support IBSS RSN, it doesn't depend on the
driver in that case.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>

The 802.11 spec states that the STA that generated the last Beacon frame shall
be the STA that response to a probe request.  This is important for congestion
reduction when a probe request is received - only 1 node in an adhoc BSS
will transmit a response.  While mac80211 drivers should provide the
tx_last_beacon function to report if they transmitted the last beacon many
do not.  As an attempt to reduce probe response congestion default this
to 0 such that a node not implementing this capability does not contribute
to unnecessary congestion.

In a modern medium sized office environment I see upwards of 100 probe
requests per second received at a given node from various hardware/OS/drivers
doing zeroconf 'active probing' as opposed to passively listening for beacons.
With a modest 10-node adhoc network consisting of drivers that do not implement
this tx_last_beacon feature, I have seen this result in the simultaneous xmit
of probe responses accumulating to 500 probe responses per second because of
collisions which brings the adhoc network to its knees as well as causes
needless congestion.
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>