Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 31 7月, 2020 1 次提交
  3. 25 6月, 2020 1 次提交
  5. 08 6月, 2020 1 次提交
  7. 27 5月, 2020 3 次提交
  9. 24 4月, 2020 2 次提交
  11. 20 3月, 2020 1 次提交
  13. 24 2月, 2020 2 次提交
  15. 07 2月, 2020 1 次提交
  17. 15 1月, 2020 1 次提交
  19. 08 10月, 2019 1 次提交
  21. 29 8月, 2019 2 次提交
  23. 19 6月, 2019 1 次提交
  25. 14 6月, 2019 1 次提交
  27. 26 4月, 2019 1 次提交
    • A
      mac80211: IEEE 802.11 Extended Key ID support · 96fc6efb
      由 Alexander Wetzel 提交于 
      Add support for Extended Key ID as defined in IEEE 802.11-2016.

 - Implement the nl80211 API for Extended Key ID
 - Extend mac80211 API to allow drivers to support Extended Key ID
 - Enable Extended Key ID by default for drivers only supporting SW
   crypto (e.g. mac80211_hwsim)
 - Allow unicast Tx usage to be supressed (IEEE80211_KEY_FLAG_NO_AUTO_TX)
 - Select the decryption key based on the MPDU keyid
 - Enforce existing assumptions in the code that rekeys don't change the
   cipher
Signed-off-by: NAlexander Wetzel <alexander@wetzel-home.de>
[remove module parameter]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      96fc6efb
  29. 29 3月, 2019 1 次提交
  31. 22 2月, 2019 2 次提交
  33. 25 1月, 2019 1 次提交
    • M
      mac80211: Add attribute aligned(2) to struct 'action' · 7c53eb5d
      由 Mathieu Malaterre 提交于 
      During refactor in commit 9e478066 ("mac80211: fix MU-MIMO
follow-MAC mode") a new struct 'action' was declared with packed
attribute as:

  struct {
          struct ieee80211_hdr_3addr hdr;
          u8 category;
          u8 action_code;
  } __packed action;

But since struct 'ieee80211_hdr_3addr' is declared with an aligned
keyword as:

  struct ieee80211_hdr {
  	__le16 frame_control;
  	__le16 duration_id;
  	u8 addr1[ETH_ALEN];
  	u8 addr2[ETH_ALEN];
  	u8 addr3[ETH_ALEN];
  	__le16 seq_ctrl;
  	u8 addr4[ETH_ALEN];
  } __packed __aligned(2);

Solve the ambiguity of placing aligned structure in a packed one by
adding the aligned(2) attribute to struct 'action'.

This removes the following warning (W=1):

  net/mac80211/rx.c:234:2: warning: alignment 1 of 'struct <anonymous>' is less than 2 [-Wpacked-not-aligned]

Cc: Johannes Berg <johannes.berg@intel.com>
Suggested-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NMathieu Malaterre <malat@debian.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7c53eb5d
  35. 19 1月, 2019 1 次提交
    • B
      mac80211: fix miscounting of ttl-dropped frames · a0dc0203
      由 Bob Copeland 提交于 
      In ieee80211_rx_h_mesh_fwding, we increment the 'dropped_frames_ttl'
counter when we decrement the ttl to zero.  For unicast frames
destined for other hosts, we stop processing the frame at that point.

For multicast frames, we do not rebroadcast it in this case, but we
do pass the frame up the stack to process it on this STA.  That
doesn't match the usual definition of "dropped," so don't count
those as such.

With this change, something like `ping6 -i0.2 ff02::1%mesh0` from a
peer in a ttl=1 network no longer increments the counter rapidly.
Signed-off-by: NBob Copeland <bobcopeland@fb.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a0dc0203
  37. 19 12月, 2018 2 次提交
  39. 18 12月, 2018 1 次提交
  41. 05 12月, 2018 1 次提交
  43. 09 11月, 2018 1 次提交
  45. 11 10月, 2018 1 次提交
    • J
      mac80211: avoid reflecting frames back to the client · 42dca5ef
      由 Johannes Berg 提交于 
      I'm not really sure exactly _why_ I've been carrying a note
for what's probably _years_ to check that we don't do this,
but we clearly do reflect frames back to the station itself
if it sends such.

One way or the other, it's useless since the station doesn't
really need the AP to talk to itself, so suppress it.

While at it, clarify some of the logic by removing skb->data
references in favour of the destination address (pointer) we
already have separately.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      42dca5ef
  47. 11 9月, 2018 1 次提交
  49. 05 9月, 2018 4 次提交
  51. 29 8月, 2018 1 次提交
    • S
      mac80211: add missing WFA Multi-AP backhaul STA Rx requirement · 1ecef20c
      由 Sathishkumar Muruganandam 提交于 
      The current mac80211 WDS (4-address mode) can be used to cover most of the
Multi-AP requirements for Data frames per the WFA Multi-AP Specification v1.0.
When configuring AP/STA interfaces in 4-address mode, they are able to function
as fronthaul AP/backhaul STA of Multi-AP device complying below
Tx, Rx requirements except one missing STA Rx requirement added by this patch.

Multi-AP specification section 14.1 describes the following requirements:

Transmitter requirements
------------------------
1. Fronthaul AP
        i) When DA!=RA of backhaul STA, must use 4-address format
        ii) When DA==RA of backhaul STA, shall use either 3-address
            or 4-address format with RA updated with STA MAC

            (mac80211 support 4-address format via AP/VLAN interface)

2. Backhaul STA
        i) When SA!=TA of backhaul STA, must use 4-address format
        ii) When SA==TA of backhaul STA, shall use either 3-address
            or 4-address format with RA updated with AP MAC

            (mac80211 support 4-address format via use_4addr)

Receiver requirements
---------------------
1. Fronthaul AP
        i) When SA!=TA of backhaul STA, must support receiving 4-address
           format frames
        ii) When SA==TA of backhaul STA, must support receiving both
            3-address and 4-address format frames

            (mac80211 support both 3-addr & 4-addr via AP/VLAN interface)

2. Backhaul STA
        i) When DA!=RA of backhaul STA, must support receiving 4-address
           format frames
        ii) When DA==RA of backhaul STA,  must support receiving both
            3-address and 4-address format frames

            (mac80211 support only receiving 4-address format via
             use_4addr)

This patch addresses the above Rx requirement (ii) for backhaul STA to receive
unicast (DA==RA) 3-address frames in addition to 4-address frames.

The current design doesn't accept 3-address frames when configured in 4-address
mode (use_4addr). Hence add a check to allow 3-address frames when DA==RA of
backhaul STA (adhering to Table 9-26 of IEEE Std 802.11™-2016).

This case was tested with a bridged station interface when associated with
a non-mac80211 based vendor AP implementation using 3-address frames for WDS.

STA was able to support the Multi-AP Rx requirement when DA==RA. No issues,
no loops seen when tested with mac80211 based AP as well.

Verified and confirmed all other Tx and Rx requirements of AP and STA for
Multi-AP respectively. They all work using the current mac80211-WDS design.
Signed-off-by: NSathishkumar Muruganandam <murugana@codeaurora.org>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1ecef20c
  53. 28 8月, 2018 1 次提交
    • E
      mac80211: don't update the PM state of a peer upon a multicast frame · 20932750
      由 Emmanuel Grumbach 提交于 
      I changed the way mac80211 updates the PM state of the peer.
I forgot that we could also have multicast frames from the
peer and that those frame should of course not change the
PM state of the peer: A peer goes to power save when it
needs to scan, but it won't send the broadcast Probe Request
with the PM bit set.

This made us mark the peer as awake when it wasn't and then
Intel's firmware would fail to transmit because the peer is
asleep according to its database. The driver warned about
this and it looked like this:

 WARNING: CPU: 0 PID: 184 at /usr/src/linux-4.16.14/drivers/net/wireless/intel/iwlwifi/mvm/tx.c:1369 iwl_mvm_rx_tx_cmd+0x53b/0x860
 CPU: 0 PID: 184 Comm: irq/124-iwlwifi Not tainted 4.16.14 #1
 RIP: 0010:iwl_mvm_rx_tx_cmd+0x53b/0x860
 Call Trace:
  iwl_pcie_rx_handle+0x220/0x880
  iwl_pcie_irq_handler+0x6c9/0xa20
  ? irq_forced_thread_fn+0x60/0x60
  ? irq_thread_dtor+0x90/0x90

The relevant code that spits the WARNING is:

        case TX_STATUS_FAIL_DEST_PS:
                /* the FW should have stopped the queue and not
                 * return this status
                 */
                WARN_ON(1);
                info->flags |= IEEE80211_TX_STAT_TX_FILTERED;

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=199967.

Fixes: 9fef6544 ("mac80211: always update the PM state of a peer on MGMT / DATA frames")
Cc: <stable@vger.kernel.org>   #4.16+
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      20932750
  55. 06 7月, 2018 1 次提交
    • D
      nl80211/mac80211: allow non-linear skb in rx_control_port · a948f713
      由 Denis Kenzior 提交于 
      The current implementation of cfg80211_rx_control_port assumed that the
caller could provide a contiguous region of memory for the control port
frame to be sent up to userspace.  Unfortunately, many drivers produce
non-linear skbs, especially for data frames.  This resulted in userspace
getting notified of control port frames with correct metadata (from
address, port, etc) yet garbage / nonsense contents, resulting in bad
handshakes, disconnections, etc.

mac80211 linearizes skbs containing management frames.  But it didn't
seem worthwhile to do this for control port frames.  Thus the signature
of cfg80211_rx_control_port was changed to take the skb directly.
nl80211 then takes care of obtaining control port frame data directly
from the (linear | non-linear) skb.

The caller is still responsible for freeing the skb,
cfg80211_rx_control_port does not take ownership of it.

Fixes: 6a671a50 ("nl80211: Add CMD_CONTROL_PORT_FRAME API")
Signed-off-by: NDenis Kenzior <denkenz@gmail.com>
[fix some kernel-doc formatting, add fixes tag]
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a948f713
  57. 19 6月, 2018 1 次提交
  59. 15 6月, 2018 1 次提交