1. 11 2月, 2019 1 次提交
  2. 01 2月, 2019 1 次提交
    • F
      mac80211: ensure that mgmt tx skbs have tailroom for encryption · 9d0f50b8
      Felix Fietkau 提交于
      Some drivers use IEEE80211_KEY_FLAG_SW_MGMT_TX to indicate that management
      frames need to be software encrypted. Since normal data packets are still
      encrypted by the hardware, crypto_tx_tailroom_needed_cnt gets decremented
      after key upload to hw. This can lead to passing skbs to ccmp_encrypt_skb,
      which don't have the necessary tailroom for software encryption.
      
      Change the code to add tailroom for encrypted management packets, even if
      crypto_tx_tailroom_needed_cnt is 0.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9d0f50b8
  3. 25 1月, 2019 2 次提交
    • 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
    • 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
  4. 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
  5. 19 12月, 2018 3 次提交
  6. 18 12月, 2018 10 次提交
  7. 05 12月, 2018 5 次提交
    • E
      mac80211: fix deauth TX when we disconnect · f6c7f03f
      Emmanuel Grumbach 提交于
      The iTXQs stop/wake queue mechanism involves a whole bunch
      of locks and this is probably why the call to
      ieee80211_wake_txqs is deferred to a tasklet when called from
      __ieee80211_wake_queue.
      
      Another advantage of that is that ieee80211_wake_txqs might
      call the wake_tx_queue() callback and then the driver may
      call mac80211 which will call it back in the same context.
      
      The bug I saw is that when we send a deauth frame as a
      station we do:
      
      flush(drop=1)
      tx deauth
      flush(drop=0)
      
      While we flush we stop the queues and wake them up
      immediately after we finished flushing. The problem here is
      that the tasklet that de-facto enables the queue may not have
      run until we send the deauth. Then the deauth frame is sent
      to the driver (which is surprising by itself), but the driver
      won't get anything useful from ieee80211_tx_dequeue because
      the queue is stopped (or more precisely because
      vif->txqs_stopped[0] is true).
      Then the deauth is not sent. Later on, the tasklet will run,
      but that'll be too late. We'll already have removed all the
      vif etc...
      
      Fix this by calling ieee80211_wake_txqs synchronously if we
      are not waking up the queues from the driver (we check the
      reason to determine that). This makes the code really
      convoluted because we may call ieee80211_wake_txqs from
      __ieee80211_wake_queue. The latter assumes that
      queue_stop_reason_lock has been taken by the caller and
      ieee80211_wake_txqs may release the lock to send the frames.
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      f6c7f03f
    • B
      mac80211: rewrite Kconfig text for mesh · c8d10cbd
      Bob Copeland 提交于
      Lubomir Rintel recently pointed out a dead link for o11s.org, and
      repointed it to a still live, but also stale website.  As far as I
      know, no one is updating the content at open80211s.org.
      
      Since this Kconfig text was originally written, though, the 802.11s
      mesh drafts were approved and ultimately rolled into 802.11 proper.
      Meanwhile, the implementation has converged on the final standard,
      so we can lose all of the text here and provide something that's a
      little more helpful and accurate.
      Signed-off-by: NBob Copeland <bobcopeland@fb.com>
      Reviewed-by: NLubomir Rintel <lkundrak@v3.sk>
      Reviewed-by: NSteve deRosier <derosier@cal-sierra.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c8d10cbd
    • E
      mac80211: ignore NullFunc frames in the duplicate detection · 990d7184
      Emmanuel Grumbach 提交于
      NullFunc packets should never be duplicate just like
      QoS-NullFunc packets.
      
      We saw a client that enters / exits power save with
      NullFunc frames (and not with QoS-NullFunc) despite the
      fact that the association supports HT.
      This specific client also re-uses a non-zero sequence number
      for different NullFunc frames.
      At some point, the client had to send a retransmission of
      the NullFunc frame and we dropped it, leading to a
      misalignment in the power save state.
      Fix this by never consider a NullFunc frame as duplicate,
      just like we do for QoS NullFunc frames.
      
      This fixes https://bugzilla.kernel.org/show_bug.cgi?id=201449
      
      CC: <stable@vger.kernel.org>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      990d7184
    • F
      mac80211: fix reordering of buffered broadcast packets · 9ec1190d
      Felix Fietkau 提交于
      If the buffered broadcast queue contains packets, letting new packets bypass
      that queue can lead to heavy reordering, since the driver is probably throttling
      transmission of buffered multicast packets after beacons.
      
      Keep buffering packets until the buffer has been cleared (and no client
      is in powersave mode).
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9ec1190d
    • F
      mac80211: ignore tx status for PS stations in ieee80211_tx_status_ext · a317e65f
      Felix Fietkau 提交于
      Make it behave like regular ieee80211_tx_status calls, except for the lack of
      filtered frame processing.
      This fixes spurious low-ack triggered disconnections with powersave clients
      connected to an AP.
      
      Fixes: f027c2ac ("mac80211: add ieee80211_tx_status_noskb")
      Cc: stable@vger.kernel.org
      Signed-off-by: NFelix Fietkau <nbd@nbd.name>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a317e65f
  8. 20 11月, 2018 1 次提交
  9. 09 11月, 2018 14 次提交
  10. 12 10月, 2018 2 次提交