Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 24 Feb, 2016 2 commits
    • Eliad Peller's avatar
      mac80211: move TKIP TX IVs to public part of key struct · f8079d43
      Eliad Peller authored 
      Some drivers/devices might want to set the IVs by
themselves (and still let mac80211 generate MMIC).

Specifically, this is needed when the device does
offloading at certain times, and the driver has
to make sure that the IVs of new tx frames (from
the host) are synchronized with IVs that were
potentially used during the offloading.

Similarly to CCMP, move the TX IVs of TKIP keys to the
public part of the key struct, and export a function
to add the IV right into the crypto header.

The public tx_pn field is defined as atomic64, so define
TKIP_PN_TO_IV16/32 helper macros to convert it to iv16/32
when needed.

Since the iv32 used for the p1k cache is taken
directly from the frame, we can safely remove
iv16/32 from being protected by tkip.txlock.
Signed-off-by: default avatarEliad Peller <eliadx.peller@intel.com>
Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f8079d43
    • Emmanuel Grumbach's avatar
      mac80211: limit the A-MSDU Tx based on peer's capabilities · 506bcfa8
      Emmanuel Grumbach authored 
      In VHT, the specification allows to limit the number of
MSDUs in an A-MSDU in the Extended Capabilities IE. There
is also a limitation on the byte size in the VHT IE.
In HT, the only limitation is on the byte size.
Parse the capabilities from the peer and make them
available to the driver.

In HT, there is another limitation when a BA agreement
is active: the byte size can't be greater than 4095.
This is not enforced here.
Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      506bcfa8
  3. 15 Dec, 2015 1 commit
  5. 04 Dec, 2015 5 commits
  7. 02 Dec, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: fix off-channel mgmt-tx uninitialized variable usage · c1df932c
      Johannes Berg authored 
      In the last change here, I neglected to update the cookie in one code
path: when a mgmt-tx has no real cookie sent to userspace as it doesn't
wait for a response, but is off-channel. The original code used the SKB
pointer as the cookie and always assigned the cookie to the TX SKB in
ieee80211_start_roc_work(), but my change turned this around and made
the code rely on a valid cookie being passed in.

Unfortunately, the off-channel no-wait TX path wasn't assigning one at
all, resulting in an uninitialized stack value being used. This wasn't
handed back to userspace as a cookie (since in the no-wait case there
isn't a cookie), but it was tested for non-zero to distinguish between
mgmt-tx and off-channel.

Fix this by assigning a dummy non-zero cookie unconditionally, and get
rid of a misleading comment and some dead code while at it. I'll clean
up the ACK SKB handling separately later.

Fixes: 3b79af97 ("mac80211: stop using pointers as userspace cookies")
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      c1df932c
  9. 03 Nov, 2015 1 commit
  11. 14 Oct, 2015 3 commits
  13. 13 Oct, 2015 1 commit
  15. 29 Sep, 2015 1 commit
  17. 22 Sep, 2015 4 commits
  19. 04 Sep, 2015 1 commit
  21. 14 Aug, 2015 1 commit
  23. 17 Jul, 2015 5 commits
  25. 10 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: convert HW flags to unsigned long bitmap · 30686bf7
      Johannes Berg authored 
      As we're running out of hardware capability flags pretty quickly,
convert them to use the regular test_bit() style unsigned long
bitmaps.

This introduces a number of helper functions/macros to set and to
test the bits, along with new debugfs code.

The occurrences of an explicit __clear_bit() are intentional, the
drivers were never supposed to change their supported bits on the
fly. We should investigate changing this to be a per-frame flag.
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      30686bf7
  27. 09 Jun, 2015 1 commit
  29. 02 Jun, 2015 3 commits
    • Johannes Berg's avatar
      mac80211: stop using pointers as userspace cookies · 3b79af97
      Johannes Berg authored 
      Even if the pointers are really only accessible to root and used
pretty much only by wpa_supplicant, this is still not great; even
for debugging it'd be easier to have something that's easier to
read and guaranteed to never get reused.

With the recent change to make mac80211 create an ack_skb for the
mgmt-tx path this becomes possible, only the client probe method
needs to also allocate an ack_skb, and we can store the cookie in
that skb.
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3b79af97
    • Johannes Berg's avatar
      mac80211: copy nl80211 mgmt TX SKB for status · b2eb0ee6
      Johannes Berg authored 
      When we return the TX status for an nl80211 mgmt TX SKB, we
should also return the original frame with the status to
allow userspace to match up the submission (it could also
use the cookie but both ways are permissible.)

As TX SKBs could be encrypted, at least in the case of ANQP
while associated with the AP, copy the original SKB, store
it with an ACK frame ID and restructure the status path to
use that to return status with the original SKB. Otherwise,
userspace (in particular wpa_supplicant) will get confused.
Reported-by: default avatarMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b2eb0ee6
    • Johannes Berg's avatar
      mac80211: move TX PN to public part of key struct · db388a56
      Johannes Berg authored 
      For drivers supporting TSO or similar features, but that still have
PN assignment in software, there's a need to have some memory to
store the current PN value. As mac80211 already stores this and it's
somewhat complicated to add a per-driver area to the key struct (due
to the dynamic sizing thereof) it makes sense to just move the TX PN
to the keyconf, i.e. the public part of the key struct.

As TKIP is more complicated and we won't able to offload it in this
way right now (fast-xmit is skipped for TKIP unless the HW does it
all, and our hardware needs MMIC calculation in software) I've not
moved that for now - it's possible but requires exposing a lot of
the internal TKIP state.

As an bonus side effect, we can remove a lot of code by assuming the
keyseq struct has a certain layout - with BUILD_BUG_ON to verify it.

This might also improve performance, since now TX and RX no longer
share a cacheline.
Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      db388a56
  31. 20 May, 2015 2 commits
    • Johannes Berg's avatar
      mac80211: don't split remain-on-channel for coalescing · 252ec2b3
      Johannes Berg authored 
      Due to remain-on-channel scheduling delays, when we split an ROC
while coalescing, we'll usually get a picture like this:

existing ROC:  |------------------|
current time:              ^
new ROC:                   |------|              |-------|

If the expected response frames are then transmitted by the peer
in the hole between the two fragments of the new ROC, we miss
them and the process (e.g. ANQP query) fails.

mac80211 expects that the window to miss something is small:

existing ROC:  |------------------|
new ROC:                   |------||-------|

but that's normally not the case.

To avoid this problem, coalesce only if the new ROC's duration
is <= the remaining time on the existing one:

existing ROC:  |------------------|
new ROC:                   |-----|

and never split a new one but schedule it afterwards instead:

existing ROC:  |------------------|
new ROC:                                       |-------------|

type=bugfix
bug=not-tracked
fixes=unknown
Reported-by: default avatarMatti Gottlieb <matti.gottlieb@intel.com>
Reviewed-by: default avatarEliadX Peller <eliad@wizery.com>
Reviewed-by: default avatarMatti Gottlieb <matti.gottlieb@intel.com>
Tested-by: default avatarMatti Gottlieb <matti.gottlieb@intel.com>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      252ec2b3
    • Michal Kazior's avatar
      mac80211: check fast-xmit on station change · 464daaf0
      Michal Kazior authored 
      Drivers with fast-xmit (e.g. ath10k) running in
AP_VLAN setups would fail to communicate with
connected 4addr stations.

The reason was when new station associates it
first goes into master AP interface. It is not
until later that a dedicated AP_VLAN is created
for it and the station itself is moved there.
After that Tx directed at the station should use
4addr header. However fast-xmit wasn't
recalculated and 3addr header remained to be used.
This in turn caused the connected 4addr stations
to drop packets coming from the AP until some
other event would cause fast-xmit to recalculate
for that station (which could never come).
Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      464daaf0
  33. 06 May, 2015 2 commits
  35. 24 Apr, 2015 1 commit
  37. 22 Apr, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: add TX fastpath · 17c18bf8
      Johannes Berg authored 
      In order to speed up mac80211's TX path, add the "fast-xmit" cache
that will cache the data frame 802.11 header and other data to be
able to build the frame more quickly. This cache is rebuilt when
external triggers imply changes, but a lot of the checks done per
packet today are simplified away to the check for the cache.

There's also a more detailed description in the code.
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      17c18bf8
  39. 30 Mar, 2015 3 commits
    • Johannes Berg's avatar
      mac80211: set QoS capability before changing station state · 2c44be81
      Johannes Berg authored 
      In the upcoming fast-xmit patch, changing station state will
build a header cache based on the station's capabilities, and
as the QoS capability (sta.wme) impacts the header, it needs
to be set before.
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      2c44be81
    • Johannes Berg's avatar
      mac80211: make sta.wme indicate whether QoS is used · 527871d7
      Johannes Berg authored 
      Indicating just the peer's capability is fairly pointless
if the local device doesn't support it. Make the variable
track both combined, and remove the 'local support' check
in the TX path.
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      527871d7
    • Tom Gundersen's avatar
      cfg80211: pass name_assign_type to rdev_add_virtual_intf() · 6bab2e19
      Tom Gundersen authored 
      This will expose in /sys whether the ifname of a device is set by
userspace or generated by the kernel. The latter kind (wlanX, etc)
is not deterministic, so userspace needs to rename these devices
to names that are guaranteed to stay the same between reboots. The
former, however should never be renamed, so userspace needs to be
able to reliably tell the difference.

Similar functionality was introduced for the rtnetlink core in
commit 5517750f ("net: rtnetlink - make create_link take name_assign_type")
Signed-off-by: default avatarTom Gundersen <teg@jklm.no>
Cc: Kalle Valo <kvalo@qca.qualcomm.com>
Cc: Brett Rudley <brudley@broadcom.com>
Cc: Arend van Spriel <arend@broadcom.com>
Cc: Franky (Zhenhui) Lin <frankyl@broadcom.com>
Cc: Hante Meuleman <meuleman@broadcom.com>
Cc: Johannes Berg <johannes@sipsolutions.net>
[reformat changelog to fit 72 cols]
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6bab2e19
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7