1. 05 9月, 2018 11 次提交
    • S
      wireless: align to draft 11ax D3.0 · add7453a
      Shaul Triebitz 提交于
      Align to new 11ax draft D3.0.  Change/add new MAC and PHY capabilities
      and update drivers' 11ax capabilities and mac80211's debugfs
      accordingly.
      Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      add7453a
    • S
      mac80211: support reporting 0-length PSDU in radiotap · c3d1f875
      Shaul Triebitz 提交于
      For certain sounding frames, it may be useful to report them
      to userspace even though they don't have a PSDU in order to
      determine the PHY parameters (e.g. VHT rate/stream config.)
      Add support for this to mac80211.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c3d1f875
    • A
      mac80211: Fix PTK rekey freezes and clear text leak · 62872a9b
      Alexander Wetzel 提交于
      Rekeying PTK keys without "Extended Key ID for Individually Addressed
      Frames" did use a procedure not suitable to replace in-use keys and
      could caused the following issues:
      
       1) Freeze caused by incoming frames:
          If the local STA installed the key prior to the remote STA we still
          had the old key active in the hardware when mac80211 switched over
          to the new key.
          Therefore there was a window where the card could hand over frames
          decoded with the old key to mac80211 and bump the new PN (IV) value
          to an incorrect high number. When it happened the local replay
          detection silently started to drop all frames sent with the new key.
      
       2) Freeze caused by outgoing frames:
          If mac80211 was providing the PN (IV) and handed over a clear text
          frame for encryption to the hardware prior to a key change the
          driver/card could have processed the queued frame after switching
          to the new key. This bumped the PN value on the remote STA to an
          incorrect high number, tricking the remote STA to discard all frames
          we sent later.
      
       3) Freeze caused by RX aggregation reorder buffer:
          An aggregation session started with the old key and ending after the
          switch to the new key also bumped the PN to an incorrect high number,
          freezing the connection quite similar to 1).
      
       4) Freeze caused by repeating lost frames in an aggregation session:
          A driver could repeat a lost frame and encrypt it with the new key
          while in a TX aggregation session without updating the PN for the
          new key. This also could freeze connections similar to 2).
      
       5) Clear text leak:
          Removing encryption offload from the card cleared the encryption
          offload flag only after the card had deleted the key and we did not
          stop TX during the rekey. The driver/card could therefore get
          unencrypted frames from mac80211 while no longer be instructed to
          encrypt them.
      
      To prevent those issues the key install logic has been changed:
       - Mac80211 divers known to be able to rekey PTK0 keys have to set
         @NL80211_EXT_FEATURE_CAN_REPLACE_PTK0,
       - mac80211 stops queuing frames depending on the key during the replace
       - the key is first replaced in the hardware and after that in mac80211
       - and mac80211 stops/blocks new aggregation sessions during the rekey.
      
      For drivers not setting
      @NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 the user space must avoid PTK
      rekeys if "Extended Key ID for Individually Addressed Frames" is not
      being used. Rekeys for mac80211 drivers without this flag will generate a
      warning and use an extra call to ieee80211_flush_queues() to both
      highlight and try to prevent the issues with not updated drivers.
      
      The core of the fix changes the key install procedure from:
       - atomic switch over to the new key in mac80211
       - remove the old key in the hardware (stops encryption offloading, fall
         back to software encryption with a potential clear text packet leak
         in between)
       - delete the inactive old key in mac80211
       - enable hardware encryption offloading for the new key
      to:
       - if it's a PTK mark the old key as tainted to drop TX frames with the
         outgoing key
       - replace the key in hardware with the new one
       - atomic switch over to the new (not marked as tainted) key in
         mac80211 (which also resumes TX)
       - delete the inactive old key in mac80211
      
      With the new sequence the hardware will be unable to decrypt frames
      encrypted with the old key prior to switching to the new key in mac80211
      and thus prevent PNs from packets decrypted with the old key to be
      accounted against the new key.
      
      For that to work the drivers have to provide a clear boundary.
      Mac80211 drivers setting @NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 confirm
      to provide it and mac80211 will then be able to correctly rekey in-use
      PTK keys with those drivers.
      
      The mac80211 requirements for drivers to set the flag have been added to
      the "Hardware crypto acceleration" documentation section. It drills down
      to:
      The drivers must not hand over frames decrypted with the old key to
      mac80211 once the call to set_key() with %DISABLE_KEY has been
      completed. It's allowed to either drop or continue to use the old key
      for any outgoing frames which are already in the queues, but it must not
      send out any of them unencrypted or encrypted with the new key.
      
      Even with the new boundary in place aggregation sessions with the
      reorder buffer are problematic:
      RX aggregation session started prior and completed after the rekey could
      still dump frames received with the old key at mac80211 after it
      switched over to the new key. This is side stepped by stopping all (RX
      and TX) aggregation sessions when replacing a PTK key and hardware key
      offloading.
      Stopping TX aggregation sessions avoids the need to get
      the PNs (IVs) updated in frames prepared for the old key and
      (re)transmitted after the switch to the new key. As a bonus it improves
      the compatibility when the remote STA is not handling rekeys as it
      should.
      
      When using software crypto aggregation sessions are not stopped.
      Mac80211 won't be able to decode the dangerous frames and discard them
      without special handling.
      Signed-off-by: NAlexander Wetzel <alexander@wetzel-home.de>
      [trim overly long rekey warning]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      62872a9b
    • A
      nl80211: Add CAN_REPLACE_PTK0 API · 2b815b04
      Alexander Wetzel 提交于
      Drivers able to correctly replace a in-use key should set
      @NL80211_EXT_FEATURE_CAN_REPLACE_PTK0 to allow the user space (e.g.
      hostapd or wpa_supplicant) to rekey PTK keys.
      
      The user space must detect a PTK rekey attempt and only go ahead with it
      when the driver has set this flag. If the driver is not supporting the
      feature the user space either must not replace the PTK key or perform a
      full re-association instead.
      
      Ignoring this flag and continuing to rekey the connection can still work
      but has to be considered insecure and broken. Depending on the driver it
      can leak clear text packets or freeze the connection and is only
      supported to allow the user space to be updated.
      Signed-off-by: NAlexander Wetzel <alexander@wetzel-home.de>
      Reviewed-by: NDenis Kenzior <denkenz@gmail.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2b815b04
    • S
      mac80211: support radiotap L-SIG data · d1332e7b
      Shaul Triebitz 提交于
      As before with HE, the data needs to be provided by the
      driver in the skb head, since there's not enough space
      in the skb CB.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d1332e7b
    • W
      mac80211: Store sk_pacing_shift in ieee80211_hw · 70e53669
      Wen Gong 提交于
      Make it possibly for drivers to adjust the default skb_pacing_shift
      by storing it in the hardware struct.
      Signed-off-by: NWen Gong <wgong@codeaurora.org>
      [adjust commit log, move & adjust comment]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      70e53669
    • J
      mac80211: introduce capability flags for VHT EXT NSS support · 09b4a4fa
      Johannes Berg 提交于
      Depending on whether or not rate control supports selecting
      rates depending on the bandwidth, we can use VHT extended
      NSS support. In essence, this is dot11VHTExtendedNSSBWCapable
      from the spec, since depending on that we'll need to parse
      the bandwidth.
      
      If needed, also set/clear the VHT Capability Element bit for
      this capability so that we don't advertise it erroneously or
      don't advertise it when we actually use it.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      09b4a4fa
    • J
      ieee80211: add new VHT capability fields/parsing · b0aa75f0
      Johannes Berg 提交于
      IEEE 802.11-2016 extended the VHT capability fields to allow
      indicating the number of spatial streams depending on the
      actually used bandwidth, add support for decoding this.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b0aa75f0
    • S
      cfg80211: add he_capabilities (ext) IE to AP settings · 244eb9ae
      Shaul Triebitz 提交于
      Same as for HT and VHT.
      This helps the lower level to know whether the AP supports HE.
      Signed-off-by: NShaul Triebitz <shaul.triebitz@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      244eb9ae
    • S
      ieee80211: remove redundant leading zeroes · 03512ceb
      Sara Sharon 提交于
      The defines of IEEE80211_HE_OPERATION_VHT_OPER_INFO and
      IEEE80211_HE_OPERATION_MULTI_BSSID_AP have leading zeroes
      that makes the number look like it is bigger than 32 bit.
      This is misleading, remove it.
      Signed-off-by: NSara Sharon <sara.sharon@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      03512ceb
    • J
      mac80211: add an optional TXQ for other PS-buffered frames · adf8ed01
      Johannes Berg 提交于
      Some drivers may want to also use the TXQ abstraction with
      non-data packets that need powersave buffering, so add a
      hardware flag to allow this.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      adf8ed01
  2. 04 9月, 2018 2 次提交
  3. 03 9月, 2018 2 次提交
    • V
      uapi: Fix linux/rds.h userspace compilation errors. · 59a03fea
      Vinson Lee 提交于
      Include linux/in6.h for struct in6_addr.
      
      /usr/include/linux/rds.h:156:18: error: field ‘laddr’ has incomplete type
        struct in6_addr laddr;
                        ^~~~~
      /usr/include/linux/rds.h:157:18: error: field ‘faddr’ has incomplete type
        struct in6_addr faddr;
                        ^~~~~
      /usr/include/linux/rds.h:178:18: error: field ‘laddr’ has incomplete type
        struct in6_addr laddr;
                        ^~~~~
      /usr/include/linux/rds.h:179:18: error: field ‘faddr’ has incomplete type
        struct in6_addr faddr;
                        ^~~~~
      /usr/include/linux/rds.h:198:18: error: field ‘bound_addr’ has incomplete type
        struct in6_addr bound_addr;
                        ^~~~~~~~~~
      /usr/include/linux/rds.h:199:18: error: field ‘connected_addr’ has incomplete type
        struct in6_addr connected_addr;
                        ^~~~~~~~~~~~~~
      /usr/include/linux/rds.h:219:18: error: field ‘local_addr’ has incomplete type
        struct in6_addr local_addr;
                        ^~~~~~~~~~
      /usr/include/linux/rds.h:221:18: error: field ‘peer_addr’ has incomplete type
        struct in6_addr peer_addr;
                        ^~~~~~~~~
      /usr/include/linux/rds.h:245:18: error: field ‘src_addr’ has incomplete type
        struct in6_addr src_addr;
                        ^~~~~~~~
      /usr/include/linux/rds.h:246:18: error: field ‘dst_addr’ has incomplete type
        struct in6_addr dst_addr;
                        ^~~~~~~~
      
      Fixes: b7ff8b10 ("rds: Extend RDS API for IPv6 support")
      Signed-off-by: NVinson Lee <vlee@freedesktop.org>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      59a03fea
    • F
      net/sched: fix type of htb statistics · b9de3963
      Florent Fourcot 提交于
      tokens and ctokens are defined as s64 in htb_class structure,
      and clamped to 32bits value during netlink dumps:
      
      cl->xstats.tokens = clamp_t(s64, PSCHED_NS2TICKS(cl->tokens),
                                  INT_MIN, INT_MAX);
      
      Defining it as u32 is working since userspace (tc) is printing it as
      signed int, but a correct definition from the beginning is probably
      better.
      
      In the same time, 'giants' structure member is unused since years, so
      update the comment to mark it unused.
      Signed-off-by: NFlorent Fourcot <florent.fourcot@wifirst.fr>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b9de3963
  4. 02 9月, 2018 1 次提交
    • V
      net/tls: Add support for async decryption of tls records · 94524d8f
      Vakul Garg 提交于
      When tls records are decrypted using asynchronous acclerators such as
      NXP CAAM engine, the crypto apis return -EINPROGRESS. Presently, on
      getting -EINPROGRESS, the tls record processing stops till the time the
      crypto accelerator finishes off and returns the result. This incurs a
      context switch and is not an efficient way of accessing the crypto
      accelerators. Crypto accelerators work efficient when they are queued
      with multiple crypto jobs without having to wait for the previous ones
      to complete.
      
      The patch submits multiple crypto requests without having to wait for
      for previous ones to complete. This has been implemented for records
      which are decrypted in zero-copy mode. At the end of recvmsg(), we wait
      for all the asynchronous decryption requests to complete.
      
      The references to records which have been sent for async decryption are
      dropped. For cases where record decryption is not possible in zero-copy
      mode, asynchronous decryption is not used and we wait for decryption
      crypto api to complete.
      
      For crypto requests executing in async fashion, the memory for
      aead_request, sglists and skb etc is freed from the decryption
      completion handler. The decryption completion handler wakesup the
      sleeping user context when recvmsg() flags that it has done sending
      all the decryption requests and there are no more decryption requests
      pending to be completed.
      Signed-off-by: NVakul Garg <vakul.garg@nxp.com>
      Reviewed-by: NDave Watson <davejwatson@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      94524d8f
  5. 01 9月, 2018 2 次提交
  6. 31 8月, 2018 4 次提交
  7. 30 8月, 2018 8 次提交
  8. 29 8月, 2018 3 次提交
  9. 28 8月, 2018 4 次提交
    • A
      cfg80211: Add support for 60GHz band channels 5 and 6 · 9cf0a0b4
      Alexei Avshalom Lazar 提交于
      The current support in the 60GHz band is for channels 1-4.
      Add support for channels 5 and 6.
      This requires enlarging ieee80211_channel.center_freq from u16 to u32.
      Signed-off-by: NAlexei Avshalom Lazar <ailizaro@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9cf0a0b4
    • M
      mac80211: add stop/start logic for software TXQs · 21a5d4c3
      Manikanta Pubbisetty 提交于
      Sometimes, it is required to stop the transmissions momentarily and
      resume it later; stopping the txqs becomes very critical in scenarios where
      the packet transmission has to be ceased completely. For example, during
      the hardware restart, during off channel operations,
      when initiating CSA(upon detecting a radar on the DFS channel), etc.
      
      The TX queue stop/start logic in mac80211 works well in stopping the TX
      when drivers make use of netdev queues, i.e, when Qdiscs in network layer
      take care of traffic scheduling. Since the devices implementing
      wake_tx_queue can run without Qdiscs, packets will be handed to mac80211
      directly without queueing them in the netdev queues.
      
      Also, mac80211 does not invoke any of the
      netif_stop_*/netif_wake_* APIs if wake_tx_queue is implemented.
      Since the queues are not stopped in this case, transmissions can continue
      and this will impact negatively on the operation of the wireless device.
      
      For example,
      During hardware restart, we stop the netdev queues so that packets are
      not sent to the driver. Since ath10k implements wake_tx_queue,
      TX queues will not be stopped and packets might reach the hardware while
      it is restarting; this can make hardware unresponsive and the only
      possible option for recovery is to reboot the entire system.
      
      There is another problem to this, it is observed that the packets
      were sent on the DFS channel for a prolonged duration after radar
      detection impacting the channel closing time.
      
      We can still invoke netif stop/wake APIs when wake_tx_queue is implemented
      but this could lead to packet drops in network layer; adding stop/start
      logic for software TXQs in mac80211 instead makes more sense; the change
      proposed adds the same in mac80211.
      Signed-off-by: NManikanta Pubbisetty <mpubbise@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      21a5d4c3
    • D
      cfg80211/mac80211: make ieee80211_send_layer2_update a public function · 30ca1aa5
      Dedy Lansky 提交于
      Make ieee80211_send_layer2_update() a common function so other drivers
      can re-use it.
      Signed-off-by: NDedy Lansky <dlansky@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      30ca1aa5
    • S
      cfg80211: make wmm_rule part of the reg_rule structure · 38cb87ee
      Stanislaw Gruszka 提交于
      Make wmm_rule be part of the reg_rule structure. This simplifies the
      code a lot at the cost of having bigger memory usage. However in most
      cases we have only few reg_rule's and when we do have many like in
      iwlwifi we do not save memory as it allocates a separate wmm_rule for
      each channel anyway.
      
      This also fixes a bug reported in various places where somewhere the
      pointers were corrupted and we ended up doing a null-dereference.
      
      Fixes: 230ebaa1 ("cfg80211: read wmm rules from regulatory database")
      Signed-off-by: NStanislaw Gruszka <sgruszka@redhat.com>
      [rephrase commit message slightly]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      38cb87ee
  10. 27 8月, 2018 1 次提交
  11. 24 8月, 2018 2 次提交