1. 26 Aug, 2011 2 commits
    • Arik Nemtsov's avatar
      mac80211: allow action frames with unknown BSSID in GO mode · a21fa87e
      Arik Nemtsov authored
      When operating as a P2P GO, we receive some P2P action frames where the
      BSSID is set to the peer MAC address. Specifically, this occurs for
      invitation responses. These are valid action frames and they should be
      passed up.
      Signed-off-by: default avatarArik Nemtsov <arik@wizery.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Guy Eilam's avatar
      mac80211: fix race condition between assoc_done and first EAP packet · 2a33bee2
      Guy Eilam authored
      When associating to an AP, the station might miss the first EAP
      packet that the AP sends due to a race condition between the association
      success procedure and the rx flow in mac80211.
      In such cases, the packet might fall in ieee80211_rx_h_check due to
      the fact that the relevant rx->sta wasn't allocated yet.
      Allocation of the relevant station info struct before actually
      sending the association request and setting it with a new
      dummy_sta flag solve this problem.
      The station will accept only EAP packets from the AP while it
      is in the pre-association/dummy state.
      This dummy station entry is not seen by normal sta_info_get()
      calls, only by sta_info_get_bss_rx().
      The driver is not notified for the first insertion of the
      dummy station. The driver is notified only after the association
      is complete and the dummy flag is removed from the station entry.
      That way, all the rest of the code flow should be untouched by
      this change.
      Signed-off-by: default avatarGuy Eilam <guy@wizery.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  2. 22 Aug, 2011 2 commits
  3. 13 Jul, 2011 1 commit
    • Johannes Berg's avatar
      mac80211: allow driver to disconnect after resume · 95acac61
      Johannes Berg authored
      In WoWLAN, devices may use crypto keys for TX/RX
      and could also implement GTK rekeying. If the
      driver isn't able to retrieve replay counters and
      similar information from the device upon resume,
      or if the device isn't responsive due to platform
      issues, it isn't safe to keep the connection up
      as GTK rekey messages from during the sleep time
      could be replayed against it.
      The only protection against that is disconnecting
      from the AP. Modifying mac80211 to do that while
      it is resuming would be very complex and invasive
      in the case that the driver requires a reconfig,
      so do it after it has resumed completely. In that
      case, however, packets might be replayed since it
      can then only happen after TX/RX are up again, so
      mark keys for interfaces that need to disconnect
      as "tainted" and drop all packets that are sent
      or received with those keys.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  4. 08 Jul, 2011 1 commit
    • Johannes Berg's avatar
      mac80211: simplify RX PN/IV handling · 9e26297a
      Johannes Berg authored
      The current rx->queue value is slightly confusing.
      It is set to 16 on non-QoS frames, including data,
      and then used for sequence number and PN/IV checks.
      Until recently, we had a TKIP IV checking bug that
      had been introduced in 2008 to fix a seqno issue.
      Before that, we always used TID 0 for checking the
      PN or IV on non-QoS packets.
      Go back to the old status for PN/IV checks using
      the TID 0 counter for non-QoS by splitting up the
      rx->queue value into "seqno_idx" and "security_idx"
      in order to avoid confusion in the future. They
      each have special rules on the value used for non-
      QoS data frames.
      Since the handling is now unified, also revert the
      special TKIP handling from my patch
      "mac80211: fix TKIP replay vulnerability".
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  5. 27 Jun, 2011 1 commit
  6. 16 May, 2011 2 commits
  7. 11 May, 2011 2 commits
  8. 02 May, 2011 1 commit
  9. 26 Apr, 2011 1 commit
  10. 19 Apr, 2011 1 commit
  11. 13 Apr, 2011 1 commit
  12. 12 Apr, 2011 1 commit
  13. 04 Apr, 2011 1 commit
  14. 31 Mar, 2011 1 commit
  15. 30 Mar, 2011 1 commit
  16. 28 Mar, 2011 1 commit
    • Daniel Halperin's avatar
      mac80211: fix aggregation frame release during timeout · 499fe9a4
      Daniel Halperin authored
      Suppose the aggregation reorder buffer looks like this:
      where x and y are frames that have not been received, T is a received
      frame that has timed out, and R1,R2 are received frames that have not
      yet timed out. The proper behavior in this scenario is to move the
      window past x (skipping it), release T and R1, and leave the window at y
      until y is received or R2 times out.
      As written, this code will instead leave the window at R1, because it
      has not yet timed out. Fix this by exiting the reorder loop only when
      the frame that has not timed out AND there are skipped frames earlier in
      the current valid window.
      Signed-off-by: default avatarDaniel Halperin <dhalperi@cs.washington.edu>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  17. 01 Mar, 2011 1 commit
  18. 23 Feb, 2011 1 commit
  19. 14 Feb, 2011 1 commit
  20. 07 Feb, 2011 2 commits
  21. 04 Feb, 2011 3 commits
    • Ben Greear's avatar
      mac80211: Optimize scans on current operating channel. · b23b025f
      Ben Greear authored
      This should decrease un-necessary flushes, on/off channel work,
      and channel changes in cases where the only scanned channel is
      the current operating channel.
        and is-scanning flags instead.
      * Add helper method to determine if we are currently configured
        for the operating channel.
      * Do no blindly go off/on channel in work.c  Instead, only call
        appropriate on/off code when we really need to change channels.
        Always enable offchannel-ps mode when starting work,
        and disable it when we are done.
      * Consolidate ieee80211_offchannel_stop_station and
        ieee80211_offchannel_stop_beaconing, call it
        ieee80211_offchannel_stop_vifs instead.
      * Accept non-beacon frames when scanning on operating channel.
      * Scan state machine optimized to minimize on/off channel
        transitions.  Also, when going on-channel, go ahead and
        re-enable beaconing.  We're going to be there for 200ms,
        so seems like some useful beaconing could happen.
        Always enable offchannel-ps mode when starting software
        scan, and disable it when we are done.
      * Grab local->mtx earlier in __ieee80211_scan_completed_finish
        so that we are protected when calling hw_config(), etc.
      * Pass probe-responses up the stack if scanning on local
        channel, so that mlme can take a look.
      Signed-off-by: default avatarBen Greear <greearb@candelatech.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Felix Fietkau's avatar
      mac80211: do not send duplicate data frames to the cooked monitor interface · b1f93314
      Felix Fietkau authored
      I can't think of a valid use case for this aside from debugging (which can
      also be done with a real monitor interface), and dropping these frames saves
      some precious CPU cycles.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Rajkumar Manoharan's avatar
      mac80211: do not restart ps timer during scan or offchannel · 8c99f691
      Rajkumar Manoharan authored
      While leaving oper channel, STA informs sleep state to AP to
      stop sending data. Till sending ack for the nullfunc, AP
      continues to send the data to STA which restarts ps_timer that
      is causing unnecessary nullfunc exchange on timer expiry
      when the STA was already moved to offchannel. So don't restart ps_timer
      on data reception during scan. This issue was identified by
      the following warning.
      WARNING: at net/mac80211/tx.c:661 invoke_tx_handlers+0xf07/0x1330 [mac80211]
      wlan0: Dropped data frame as no usable bitrate found while scanning and
      associated. Target station: 00:03:7f:0b:a6:1b on 5 GHz band
      Call Trace:
        [<ffffffffa0413ba7>] invoke_tx_handlers+0xf07/0x1330 [mac80211]
        [<ffffffffa0414056>] ieee80211_tx+0x86/0x2c0 [mac80211]
        [<ffffffffa0414345>] ieee80211_xmit+0xb5/0x1d0 [mac80211]
        [<ffffffffa04037e0>] ieee80211_dynamic_ps_enable_work+0x0/0xb0 [mac80211]
        [<ffffffffa04158cf>] ieee80211_tx_skb+0x4f/0x60 [mac80211]
        [<ffffffffa04026e6>] ieee80211_send_nullfunc+0x46/0x60 [mac80211]
        [<ffffffffa0403885>] ieee80211_dynamic_ps_enable_work+0xa5/0xb0 [mac80211]
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarRajkumar Manoharan <rmanoharan@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  22. 03 Feb, 2011 2 commits
  23. 28 Jan, 2011 1 commit
  24. 21 Jan, 2011 1 commit
  25. 19 Jan, 2011 1 commit
    • Felix Fietkau's avatar
      mac80211: drop non-auth 3-addr data frames when running as a 4-addr station · fbb327c5
      Felix Fietkau authored
      When running as a 4-addr station against an AP that has the 4-addr VLAN
      interface and the main 3-addr AP interface bridged together, sometimes
      frames originating from the station were looping back from the 3-addr AP
      interface, causing the bridge code to emit warnings about receiving frames
      with its own source address.
      I'm not sure why this is happening yet, but I think it's a good idea to
      drop all frames (except 802.1x/EAP frames) that do not match the configured
      addressing mode, including 4-address frames sent to a 3-address station.
      User test reports indicate that the problem goes away with this patch.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  26. 04 Jan, 2011 4 commits
  27. 22 Dec, 2010 2 commits
  28. 20 Dec, 2010 1 commit