1. 31 5月, 2020 2 次提交
  2. 27 5月, 2020 1 次提交
  3. 29 4月, 2020 1 次提交
  4. 24 4月, 2020 4 次提交
  5. 20 3月, 2020 2 次提交
  6. 24 2月, 2020 2 次提交
  7. 07 2月, 2020 2 次提交
  8. 15 1月, 2020 2 次提交
  9. 08 11月, 2019 1 次提交
  10. 11 9月, 2019 1 次提交
    • J
      mac80211: Do not send Layer 2 Update frame before authorization · 3e493173
      Jouni Malinen 提交于
      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: NJouni Malinen <jouni@codeaurora.org>
      Reviewed-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e493173
  11. 21 8月, 2019 1 次提交
  12. 31 7月, 2019 2 次提交
  13. 21 7月, 2019 1 次提交
  14. 20 6月, 2019 1 次提交
  15. 14 6月, 2019 2 次提交
  16. 05 6月, 2019 1 次提交
  17. 26 4月, 2019 3 次提交
  18. 15 2月, 2019 1 次提交
    • R
      mac80211: Restore vif beacon interval if start ap fails · 83e37e0b
      Rakesh Pillai 提交于
      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: NRakesh Pillai <pillair@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      83e37e0b
  19. 25 1月, 2019 1 次提交
    • B
      mac80211: don't initiate TDLS connection if station is not associated to AP · 7ed52853
      Balaji Pothunoori 提交于
      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: NBalaji Pothunoori <bpothuno@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7ed52853
  20. 19 1月, 2019 4 次提交
  21. 18 12月, 2018 1 次提交
  22. 09 11月, 2018 3 次提交
  23. 12 10月, 2018 1 次提交