1. 11 Sep, 2019 1 commit
    • Jouni Malinen's avatar
      mac80211: Do not send Layer 2 Update frame before authorization · 3e493173
      Jouni Malinen authored
      The Layer 2 Update frame is used to update bridges when a station roams
      to another AP even if that STA does not transmit any frames after the
      reassociation. This behavior was described in IEEE Std 802.11F-2003 as
      something that would happen based on MLME-ASSOCIATE.indication, i.e.,
      before completing 4-way handshake. However, this IEEE trial-use
      recommended practice document was published before RSN (IEEE Std
      802.11i-2004) and as such, did not consider RSN use cases. Furthermore,
      IEEE Std 802.11F-2003 was withdrawn in 2006 and as such, has not been
      maintained amd should not be used anymore.
      
      Sending out the Layer 2 Update frame immediately after association is
      fine for open networks (and also when using SAE, FT protocol, or FILS
      authentication when the station is actually authenticated by the time
      association completes). However, it is not appropriate for cases where
      RSN is used with PSK or EAP authentication since the station is actually
      fully authenticated only once the 4-way handshake completes after
      authentication and attackers might be able to use the unauthenticated
      triggering of Layer 2 Update frame transmission to disrupt bridge
      behavior.
      
      Fix this by postponing transmission of the Layer 2 Update frame from
      station entry addition to the point when the station entry is marked
      authorized. Similarly, send out the VLAN binding update only if the STA
      entry has already been authorized.
      Signed-off-by: default avatarJouni Malinen <jouni@codeaurora.org>
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3e493173
  2. 21 Aug, 2019 1 commit
  3. 31 Jul, 2019 2 commits
  4. 20 Jul, 2019 1 commit
  5. 20 Jun, 2019 1 commit
  6. 14 Jun, 2019 2 commits
  7. 05 Jun, 2019 1 commit
  8. 26 Apr, 2019 3 commits
  9. 15 Feb, 2019 1 commit
    • Rakesh Pillai's avatar
      mac80211: Restore vif beacon interval if start ap fails · 83e37e0b
      Rakesh Pillai authored
      The starting of AP interface can fail due to invalid
      beacon interval, which does not match the minimum gcd
      requirement set by the wifi driver. In such case, the
      beacon interval of that interface gets updated with
      that invalid beacon interval.
      
      The next time that interface is brought up in AP mode,
      an interface combination check is performed and the
      beacon interval is taken from the previously set value.
      
      In a case where an invalid beacon interval, i.e. a beacon
      interval value which does not satisfy the minimum gcd criteria
      set by the driver, is set, all the subsequent trials to
      bring that interface in AP mode will fail, even if the
      subsequent trials have a valid beacon interval.
      
      To avoid this, in case of a failure in bringing up an
      interface in AP mode due to interface combination error,
      the interface beacon interval which is stored in bss
      conf, needs to be restored with the last working value
      of beacon interval.
      
      Tested on ath10k using WCN3990.
      
      Cc: stable@vger.kernel.org
      Fixes: 0c317a02 ("cfg80211: support virtual interfaces with different beacon intervals")
      Signed-off-by: default avatarRakesh Pillai <pillair@codeaurora.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      83e37e0b
  10. 25 Jan, 2019 1 commit
    • Balaji Pothunoori's avatar
      mac80211: don't initiate TDLS connection if station is not associated to AP · 7ed52853
      Balaji Pothunoori authored
      Following call trace is observed while adding TDLS peer entry in driver
      during TDLS setup.
      
      Call Trace:
      [<c1301476>] dump_stack+0x47/0x61
      [<c10537d2>] __warn+0xe2/0x100
      [<fa22415f>] ? sta_apply_parameters+0x49f/0x550 [mac80211]
      [<c1053895>] warn_slowpath_null+0x25/0x30
      [<fa22415f>] sta_apply_parameters+0x49f/0x550 [mac80211]
      [<fa20ad42>] ? sta_info_alloc+0x1c2/0x450 [mac80211]
      [<fa224623>] ieee80211_add_station+0xe3/0x160 [mac80211]
      [<c1876fe3>] nl80211_new_station+0x273/0x420
      [<c170f6d9>] genl_rcv_msg+0x219/0x3c0
      [<c170f4c0>] ? genl_rcv+0x30/0x30
      [<c170ee7e>] netlink_rcv_skb+0x8e/0xb0
      [<c170f4ac>] genl_rcv+0x1c/0x30
      [<c170e8aa>] netlink_unicast+0x13a/0x1d0
      [<c170ec18>] netlink_sendmsg+0x2d8/0x390
      [<c16c5acd>] sock_sendmsg+0x2d/0x40
      [<c16c6369>] ___sys_sendmsg+0x1d9/0x1e0
      
      Fixing this by allowing TDLS setup request only when we have completed
      association.
      Signed-off-by: default avatarBalaji Pothunoori <bpothuno@codeaurora.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7ed52853
  11. 19 Jan, 2019 4 commits
  12. 18 Dec, 2018 1 commit
  13. 09 Nov, 2018 3 commits
  14. 12 Oct, 2018 1 commit
  15. 01 Oct, 2018 1 commit
  16. 05 Sep, 2018 2 commits
  17. 28 Aug, 2018 1 commit
  18. 24 Jul, 2018 1 commit
    • Manikanta Pubbisetty's avatar
      mac80211: restrict delayed tailroom needed decrement · 133bf90d
      Manikanta Pubbisetty authored
      As explained in ieee80211_delayed_tailroom_dec(), during roam,
      keys of the old AP will be destroyed and new keys will be
      installed. Deletion of the old key causes
      crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key
      installation causes a transition from 0 to 1.
      
      Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1,
      we invoke synchronize_net(); the reason for doing this is to avoid
      a race in the TX path as explained in increment_tailroom_need_count().
      This synchronize_net() operation can be slow and can affect the station
      roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt
      is delayed for a while so that upon installation of new key the
      transition would be from 1 to 2 instead of 0 to 1 and thereby
      improving the roam time.
      
      This is all correct for a STA iftype, but deferring the tailroom_needed
      decrement for other iftypes may be unnecessary.
      
      For example, let's consider the case of a 4-addr client connecting to
      an AP for which AP_VLAN interface is also created, let the initial
      value for tailroom_needed on the AP be 1.
      
      * 4-addr client connects to the AP (AP: tailroom_needed = 1)
      * AP will clear old keys, delay decrement of tailroom_needed count
      * AP_VLAN is created, it takes the tailroom count from master
        (AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1)
      * Install new key for the station, assume key is plumbed in the HW,
        there won't be any change in tailroom_needed count on AP iface
      * Delayed decrement of tailroom_needed count on AP
        (AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1)
      
      Because of the delayed decrement on AP iface, tailroom_needed count goes
      out of sync between AP(master iface) and AP_VLAN(slave iface) and
      there would be unnecessary tailroom created for the packets going
      through AP_VLAN iface.
      
      Also, WARN_ONs were observed while trying to bring down the AP_VLAN
      interface:
      (warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
      (warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4)
      (ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850)
      (ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c)
      (ieee80211_stop) (__dev_close_many+0x94/0xb8)
      (__dev_close_many) (dev_close_many+0x5c/0xc8)
      
      Restricting delayed decrement to station interface alone fixes the problem
      and it makes sense to do so because delayed decrement is done to improve
      roam time which is applicable only for client devices.
      Signed-off-by: default avatarManikanta Pubbisetty <mpubbise@codeaurora.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      133bf90d
  19. 18 Jun, 2018 1 commit
  20. 15 Jun, 2018 1 commit
  21. 18 May, 2018 1 commit
  22. 08 May, 2018 1 commit
  23. 29 Mar, 2018 3 commits
  24. 23 Mar, 2018 1 commit
  25. 27 Feb, 2018 1 commit
  26. 19 Feb, 2018 1 commit
    • Arnd Bergmann's avatar
      cfg80211: fix cfg80211_beacon_dup · bee92d06
      Arnd Bergmann authored
      gcc-8 warns about some obviously incorrect code:
      
      net/mac80211/cfg.c: In function 'cfg80211_beacon_dup':
      net/mac80211/cfg.c:2896:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
      
      From the context, I conclude that we want to copy from beacon into
      new_beacon, as we do in the rest of the function.
      
      Cc: stable@vger.kernel.org
      Fixes: 73da7d5b ("mac80211: add channel switch command and beacon callbacks")
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      bee92d06
  27. 04 Jan, 2018 1 commit
    • Peter Große's avatar
      mac80211: Fix setting TX power on monitor interfaces · 3a3713ec
      Peter Große authored
      Instead of calling ieee80211_recalc_txpower on monitor interfaces
      directly, call it using the virtual monitor interface, if one exists.
      
      In case of a single monitor interface given, reject setting TX power,
      if no virtual monitor interface exists.
      
      That being checked, don't warn in ieee80211_bss_info_change_notify,
      after setting TX power on a monitor interface.
      
      Fixes warning:
      ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 2193 at net/mac80211/driver-ops.h:167
       ieee80211_bss_info_change_notify+0x111/0x190 Modules linked in: uvcvideo
       videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core
      rndis_host cdc_ether usbnet mii tp_smapi(O) thinkpad_ec(O) ohci_hcd vboxpci(O)
       vboxnetadp(O) vboxnetflt(O) v boxdrv(O) x86_pkg_temp_thermal kvm_intel kvm
       irqbypass iwldvm iwlwifi ehci_pci ehci_hcd tpm_tis tpm_tis_core tpm CPU: 0
       PID: 2193 Comm: iw Tainted: G           O    4.12.12-gentoo #2 task:
       ffff880186fd5cc0 task.stack: ffffc90001b54000 RIP:
       0010:ieee80211_bss_info_change_notify+0x111/0x190 RSP: 0018:ffffc90001b57a10
       EFLAGS: 00010246 RAX: 0000000000000006 RBX: ffff8801052ce840 RCX:
       0000000000000064 RDX: 00000000fffffffc RSI: 0000000000040000 RDI:
       ffff8801052ce840 RBP: ffffc90001b57a38 R08: 0000000000000062 R09:
       0000000000000000 R10: ffff8802144b5000 R11: ffff880049dc4614 R12:
       0000000000040000 R13: 0000000000000064 R14: ffff8802105f0760 R15:
       ffffc90001b57b48 FS:  00007f92644b4580(0000) GS:ffff88021e200000(0000)
       knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00007f9263c109f0 CR3: 00000001df850000 CR4: 00000000000406f0
       Call Trace:
        ieee80211_recalc_txpower+0x33/0x40
        ieee80211_set_tx_power+0x40/0x180
        nl80211_set_wiphy+0x32e/0x950
      Reported-by: default avatarPeter Große <pegro@friiks.de>
      Signed-off-by: default avatarPeter Große <pegro@friiks.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      3a3713ec
  28. 11 Dec, 2017 1 commit