With this .config: http://busybox.net/~vda/kernel_config,
after deinlining these functions have sizes and callsite counts
as follows:
rate_control_rate_init: 554 bytes, 8 calls
rate_control_rate_update: 1596 bytes, 5 calls
Total size reduction: about 11 kbytes.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
CC: John Linville <linville@tuxdriver.com>
CC: Michal Kazior <michal.kazior@tieto.com>
CC: Johannes Berg <johannes.berg@intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
With this .config: http://busybox.net/~vda/kernel_config,
after deinlining the function size is 3132 bytes and there are
7 callsites.
Total size reduction: about 20 kbytes.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
CC: John Linville <linville@tuxdriver.com>
CC: Michal Kazior <michal.kazior@tieto.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
CC: linux-kernel@vger.kernel.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of using peer link id for AID, generate a new
AID when creating mesh STAs in the kernel peering manager.
This enables smaller TIM elements and more closely follows
the standard, and it also enables mesh to work on drivers
that require a valid AID when the STA is inserted (ath10k
firmware has this requirement, for example).
In the case of userspace-managed stations, we use the AID
from NL80211_CMD_NEW_STATION.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
According to 802.11-2012 13.3.1, a mesh STA should assign an AID
upon receipt of a mesh peering open frame rather than using the link
id of the peer. Using the peer link id has two potential issues:
it may not be unique among the peers, and by its nature it is random,
so the TIM may not compress well.
In preparation for allocating it properly, use sta->sta.aid, but keep
the existing behavior of using the plid in the aid we send.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Move mesh_plink_frame_tx() above the first caller to remove
the forward declaration.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, mac80211 calls drv_resume() on wowlan resume,
but drops any incoming frame until local->suspended is
cleared later on.
This requires the low-level driver to support a new state,
in which it is expected to fully work (as it was resumed)
but not passing rx frames yet (as they will be dropped).
iwlwifi (and probably other drivers as well) has issues
supporting such mode.
Since in the wowlan case we already short-circuit
ieee80211_reconfig, there's nothing that prevents us from
clearing local->suspend before calling drv_resume(),
and letting the low-level driver work normally.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If a TDLS station is not allowed to beacon on a channel, don't accept
a channel switch request to this channel.
Move channel building code up to avoid lockdep violations - reg_can_beacon
needs to take the wdev lock.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Move TDLS channel-switch Rx handling into an RTNL locked work. This is
required to add proper regulatory checking to incoming channel-switch
requests.
Queue incoming requests in a dedicated skb queue and handle the request
in a device-specific work to avoid deadlocking on interface removal.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Add support for declaring MU-MIMO beamformee capability for
relevant hardware.
When sending association request, the capability is included if both
hardware and the AP support it, and no other virtual interface
is using it.
This is in order to avoid multiple interfaces using MU-MIMO in parallel
which might lead to contradictions in the group-id mechanism.
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If an SKB will be segmented by the driver, count it for multiple
MSDUs that are being transmitted rather than just a single.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Commit eeca9fce1d ('cfg80211: Schedule timeout for all CRDA calls')
left behind a superfluous check after it removed some earlier code.
In reg_process_hint, the test of "treatment == REG_REQ_IGNORE ||
treatment == REG_REQ_ALREADY_SET" is superfluous because the code in the
if-then branch is identical to the code after the if statement.
Coverity CID #1295939
I also removed the unnecessary assignment of treatment in this case,
and added a comment reminding any future patch authors to ensure that
treatment is properly assigned before it is used after the switch.
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This callback is currently not allowed to sleep, which makes it more
difficult to implement proper driver methods in mac80211 than it has
to be. Instead of doing asynchronous work here in mac80211, make it
possible for the callback to sleep by doing some asynchronous work
in cfg80211. This also enables improvements to other drivers, like
ath6kl, that would like to sleep in this callback.
While at it, also fix the code to call the driver on the implicit
unregistration when an interface is removed, and do that also when
a P2P-Device wdev is destroyed (otherwise we leak the structs.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Most of the fields in this struct use too wide types, change
that to shrink the struct from 64 to 48 bytes (on 64-bit.)
This results in a total saving of 64 bytes for each interface.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some drivers may need to store data per key, for example for PN
validation. Allow this by adding a pointer to the struct that
the driver can assign.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
In case of Dynamic SMPS enable RTS/CTS for all rates.
Signed-off-by: Chaitanya T K <chaitanya.mgit@gmail.com>
[change comment]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This patch does the following:
- Remove unnecessary flags field used by PERR element
- Use the per target flags defined in <linux/ieee80211.h>
- Process the target only subfield based on case E2 of
IEEE802.11-2012 13.10.9.3
Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@gmail.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The IEEE802.11-2012 specification is vague regarding SMPS operation during
TDLS. It does not define a clear way to transition between SMPS states.
To avoid interop issues, set SMPS to off when TDLS peers are connected.
Accomplish this by extending the definition of the AUTOMATIC state. If the
driver forces a state other than OFF, disconnect all TDLS peers.
While at it, avoid changing the SMPS state of the peer STA. We have no
way to control it, so try and behave correctly towards it.
Move the TDLS peer-teardown function to where the rest of the TDLS code
resides.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We already set a station to be associated when peering completes, both
in user space and in the kernel. Thus we should always have an
associated sta before sending data frames to that station.
Failure to check assoc state can cause crashes in the lower-level driver
due to transmitting unicast data frames before driver sta structures
(e.g. ampdu state in ath9k) are initialized. This occurred when
forwarding in the presence of fixed mesh paths: frames were transmitted
to stations with whom we hadn't yet completed peering.
Cc: stable@vger.kernel.org
Reported-by: Alexis Green <agreen@cococorp.com>
Tested-by: Jesse Jones <jjones@cococorp.com>
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When processing a PREQ or PREP it's critical to use the incoming SN. If
that is improperly done routing loops and other types of badness can
happen. But the code was always processing path messages for deactivated
paths. This path fixes that so that if we have a valid SN then we use it
to verify that it is a message we can accept. For reference the relevant
section of the standard is 13.10.8.4 which doesn't address the deactivated
path case at all.
I also included a special case for when our peer reboots or restarts
networking. This is an important case because without it there can be a
very long delay before we accept path messages from that peer. It's also a
simple case and intimately associated with processing messages for
deactivated paths so I used one patch instead of two.
Signed-off-by: Alexis Green <agreen@cococorp.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The 2012 spec mentions that path SNs can be invalid when created (see
section 13.10.8.4 table 13-9) but AFAICT never talks about invalidating
SNs. Which makes sense: if we have figured out the path to a target at a
certain SN then we want to remember that fact. Failing to do so can lead
to routing loops because if we don't have a valid SN then we have no way
of knowing whether an incoming path message leads to or away from the
target.
However currently when discovery fails we zero out mpath->flags which
clears MESH_PATH_SN_VALID. This patch fixes that so that only the
discovery relevant flags are cleared.
Signed-off-by: Alexis Green <agreen@cococorp.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When the nexthop is unable to resolve its own nexthop it will send back a
PERR with a zero target_sn. According to section 13.10.11.4.3 step b in the
2012 standard that perr should be forwarded and the associated mpath->sn
should be incremented. Neither one of those was happening which is rather
bad because the originator was not told that packets are black holing.
Signed-off-by: Alexis Green <agreen@cococorp.com>
CC: Jesse Jones <jjones@cococorp.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Define a station chandef, to be used for wider-bw TDLS peers. When both
peers support the feature, upgrade the channel bandwidth to the maximum
allowed by both peers and regulatory. Currently widths up to 80MHz are
supported in the 5GHz band.
When a TDLS peer connects/disconnects recalculate the channel type of the
current chanctx.
Make the chanctx width calculation consider wider-bw TDLS peers and
similarly fix the max_required_bw calculation for the chanctx min_def.
Since the sta->bandwidth is calculated only later on, take
bss_conf.chandef.width as the minimal width for station interface.
Set the upgraded channel width in the VHT-operation set during TDLS setup.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Allow a device to specify support for the TDLS wider-bandwidth feature.
Indicate this support during TDLS setup in the ext-capab IE and set an
appropriate station flag when our TDLS peer supports it.
This feature gives TDLS peers the ability to use a wider channel than
the base width of the BSS. For instance VHT capable TDLS peers connected
on a 20MHz channel can extend the channel to 80MHz, if regulatory
considerations allow it.
Do not cap the bandwidth of such stations by the current BSS channel width
in mac80211.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If reconfiguration fails, local->in_reconfig is never
cleaned, resulting in rx frames being dropped next
time the device is started.
Signed-off-by: Eliad Peller <eliadx.peller@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Simply return NULL in this case, instead of crashing. This can
simplify callers that would otherwise have to check for this
explicitly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The beacon struct is already available in many contexts that
are also already in an RCU read-locked section. Avoid that by
using the existing beacon struct pointer directly.
Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@neratec.com>
[rewrite subject/add commit message]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The code was always a bit awkward due to the 80-col restriction
and got worse in the previous patch. Refactor it a bit into its
own function to make it read nicer.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are now a fairly large number of mesh fields that really
aren't needed in any other modes; move those into their own
structure and allocate them separately.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There's a long-standing TODO item to use this flag in the cooked
monitor RX, but clearly it was never needed and now this hasn't
been used by userspace for a long time, so no userspace changes
could require it now.
Remove the unused flag.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Currently, the station hash table lookup (or iteration) must
access two cachelines for each station - the one with the hash
table node, and the one with the MAC address.
Duplicate the MAC address next to the hash node to get rid of
this. Since the MAC address is static there's no consistency
problem introduced by this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When there are multiple RX queues, the PN checks in mac80211 cannot be
used since packets might be processed out of order on different CPUs.
Allow the driver to report that the PN has been checked, drivers that
will use multi-queue RX will have to set this flag.
For now, the flag is only valid when the frame has been decrypted, in
theory that restriction doesn't have to be there, but in practice the
hardware will have decrypted the frame already.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This counter is inherently racy (since it can be incremented by RX
as well as by concurrent TX) and only available in debugfs. Instead
of fixing it to be per-CPU or similar, remove it for now. If needed
it should be added without races and with proper nl80211, perhaps
even addressing the threshold reporting TODO item that's been there
since the code was originally added.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
As there's no driver using this capability and reporting zero-length
A-MPDU subframes for radiotap monitoring, remove the capability to
free up two RX flags.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When introducing multiple RX queues, a single NAPI struct will not
be sufficient. Instead of trying to store multiple, simply change
the API to have the NAPI struct passed to the RX function. This of
course means that drivers using rx_irqsafe() cannot use NAPI, but
that seems a reasonable trade-off, particularly since only two of
all drivers are currently using it at all.
While at it, we can now remove the IEEE80211_RX_REORDER_TIMER flag
again since this code path cannot have a napi struct anyway.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
There are no RX queues in mac80211 (yet), the comment should refer
to the TID (including one slot for non-QoS) rather than 'RX queue'.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This function is only used in the RX code, so moving it into
that file gives the compiler better optimisation possibilities
and also allows us to remove the check for short frames (which
in the RX path cannot happen, but as a generic utility needed
to be checked.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Short frames less than 16 octets are already blocked in the monitor
code by the should_drop_frame() function, and cannot get into the
regular RX path. Therefore, this check can never trigger and the
counter invariably stays zero. Remove the useless code.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
We typically use 'sta' for the station info struct, and if needed
'pubsta' for the public (driver-visible) portion thereof. Do this
in the ieee80211_sta_ps_transition() function.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The RTNL is required to check for IR-relaxation conditions that allow
more channels to beacon. Export an RTNL locked version of reg_can_beacon
and use it where possible in AP/STA interface type flows, where
IR-relaxation may be applicable.
Fixes: 06f207fc54 ("cfg80211: change GO_CONCURRENT to IR_CONCURRENT for STA")
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Although mesh_rx_plink_frame() already checks that frames have enough
bytes for the action code plus another two bytes for capability/reason
code, it doesn't take into account that confirm frames also have an
additional two-byte aid. As a result, a corrupt frame could cause a
subsequent subtraction to wrap around to ill effect. Add another
check for this case.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
According to 802.11-2012 8.5.16.3.2 AID comes directly after the
capability bytes in mesh peering confirm frames. The existing
code, however, was adding a 2 byte offset to this location,
resulting in garbage data going out over the air. Remove the
offset to fix it.
Signed-off-by: Bob Copeland <me@bobcopeland.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
With a basic Linux userspace, the messages "Calling CRDA to update
world regulatory domain" appears 10 times after boot every second or
so, followed by a final "Exceeded CRDA call max attempts. Not calling
CRDA". For those of us not having the corresponding userspace parts,
having those messages repeatedly displayed at boot time is a bit
annoying, so this commit reduces their log level to pr_debug().
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the hardware is unregistered while interfaces are up, mac80211 will
unregister all interfaces, which in turns causes mac80211 to be called
again to remove them all from the driver and eventually shut down the
hardware.
During this shutdown, however, it's currently already unsafe to iterate
the list of interfaces atomically, as the list is manipulated in an
unsafe manner. This puts an undue burden on the driver - it must stop
all its activities before calling ieee80211_unregister_hw(), while in
the normal stop path it can do all cleanup in the stop method. If, for
example, it's using the iteration during RX for some reason, it would
have to stop RX before unregistering to avoid crashes.
Fix this problem by closing all interfaces before unregistering them.
This will cause the driver stop to have completed before we manipulate
the interface list, and after the driver is stopped *and* has called
ieee80211_unregister_hw() it really musn't be iterating any more as
the memory will be freed as well.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If for any reason we're in the middle of PS-polling or awake after
TX due to dynamic powersave while going to suspend, go back to save
power. This might cause a response frame to get lost, but since we
can't really wait for it while going to suspend that's still better
than not enabling powersave which would cause higher power usage
during (and possibly even after) suspend.
Note that this really only affects the very few drivers that use
the powersave implementation in mac80211.
Signed-off-by: Chaitanya T K <chaitanya.mgit@gmail.com>
[rewrite misleading commit log]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When acting as AP and a PS-Poll frame is received
associated station is marked as one in a Service
Period. This state is kept until Tx status for
released frame is reported. While a station is in
Service Period PS-Poll frames are ignored.
However if PS-Poll was received during A-MPDU
teardown it was possible to have the to-be
released frame re-queued back to pending queue.
In such case the frame was stripped of 2 important
flags:
(a) IEEE80211_TX_CTL_NO_PS_BUFFER
(b) IEEE80211_TX_STATUS_EOSP
Stripping of (a) led to the frame that was to be
released to be queued back to ps_tx_buf queue. If
station remained to use only PS-Poll frames the
re-queued frame (and new ones) was never actually
transmitted because mac80211 would ignore
subsequent PS-Poll frames due to station being in
Service Period. There was nothing left to clear
the Service Period bit (no xmit -> no tx status ->
no SP end), i.e. the AP would have the station
stuck in Service Period. Beacon TIM would
repeatedly prompt station to poll for frames but
it would get none.
Once (a) is not stripped (b) becomes important
because it's the main condition to clear the
Service Period bit of the station when Tx status
for the released frame is reported back.
This problem was observed with ath9k acting as P2P
GO in some testing scenarios but isn't limited to
it. AP operation with mac80211 based Tx A-MPDU
control combined with clients using PS-Poll frames
is subject to this race.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Denys Vlasenko
Bob Copeland
Eliad Peller
Arik Nemtsov
Johannes Berg
Sara Sharon
John Linville
Krishna Chaitanya
Chun-Yeow Yeoh
Jesse Jones
Alexis Green
Wojciech Dubowik
Thomas Petazzoni
Michal Kazior