1. 29 12月, 2009 1 次提交
  2. 23 12月, 2009 9 次提交
  3. 22 12月, 2009 6 次提交
    • K
      mac80211: remove payload alignment warning · 59d9cb07
      Kalle Valo 提交于
      The payload alignment warning enabled by MAC80211_DEBUG_PACKET_ALIGNMENT is
      difficult. To fix it, a firmware change is needed but in most cases that's
      very difficult. So the benefit from the warning is low and most probably
      it just creates more confusion for people who just enable all warnings
      (like it did for me).
      
      Remove the unaligned IP payload warning and the kconfig option. But
      leave the unaligned packet warning, it will be enabled with
      MAC80211_VERBOSE_DEBUG.
      Signed-off-by: NKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      59d9cb07
    • J
      mac80211: trace interface name · 12375ef9
      Johannes Berg 提交于
      It's not all that useful to have the vif/sdata pointer,
      we'd rather refer to the interfaces by their name.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      12375ef9
    • J
      mac80211: reduce reliance on netdev · 47846c9b
      Johannes Berg 提交于
      For bluetooth 3, we will most likely not have
      a netdev for a virtual interface (sdata), so
      prepare for that by reducing the reliance on
      having a netdev. This patch moves the name
      and address fields into the sdata struct and
      uses them from there all over. Some work is
      needed to keep them sync'ed, but that's not
      a lot of work and in slow paths anyway.
      
      In doing so, this also reduces the number of
      pointer dereferences in many places, because
      of things like sdata->dev->dev_addr becoming
      sdata->vif.addr.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      47846c9b
    • J
      mac80211: make station management completely depend on vif · abe60632
      Johannes Berg 提交于
      The station management currently uses the virtual
      interface, but you cannot add the same station to
      multiple virtual interfaces if you're communicating
      with it in multiple ways.
      
      This restriction should be lifted so that in the
      future we can, for instance, support bluetooth 3
      with an access point that mac80211 is already
      associated to.
      
      We can do that by requiring all sta_info_get users
      to provide the virtual interface and making the RX
      code aware that an address may match more than one
      station struct. Thanks to the previous patches this
      one isn't all that large and except for the RX and
      TX status paths changes has low complexity.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      abe60632
    • J
      mac80211: fix WMM AP settings application · 0183826b
      Johannes Berg 提交于
      My
        commit 77fdaa12
        Author: Johannes Berg <johannes@sipsolutions.net>
        Date:   Tue Jul 7 03:45:17 2009 +0200
      
            mac80211: rework MLME for multiple authentications
      
      inadvertedly broke WMM because it removed, along with
      a bunch of other now useless initialisations, the line
      initialising sdata->u.mgd.wmm_last_param_set to -1
      which would make it adopt any WMM parameter set. If,
      as is usually the case, the AP uses WMM parameter set
      sequence number zero, we'd never update it until the
      AP changes the sequence number.
      
      Add the missing initialisation back to get the WMM
      settings from the AP applied locally.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Cc: stable@kernel.org [2.6.31+]
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0183826b
    • J
      mac80211: fix peer HT capabilities · 9a418af5
      Johannes Berg 提交于
      I noticed yesterday, because Jeff had noticed
      a speed regression, cf. bug
      http://bugzilla.intellinuxwireless.org/show_bug.cgi?id=2138
      that the SM PS settings for peers were wrong.
      Instead of overwriting the SM PS settings with
      the local bits, we need to keep the remote bits.
      
      The bug was part of the original HT code from
      over two years ago, but unfortunately nobody
      noticed that it makes no sense -- we shouldn't
      be overwriting the peer's setting with our own
      but rather keep it intact when masking the peer
      capabilities with our own.
      
      While fixing that, I noticed that the masking of
      capabilities is completely useless for most of
      the bits, so also fix those other bits.
      
      Finally, I also noticed that PSMP_SUPPORT no
      longer exists in the final 802.11n version, so
      also remove that.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      9a418af5
  4. 15 12月, 2009 1 次提交
  5. 11 12月, 2009 3 次提交
  6. 10 12月, 2009 1 次提交
  7. 08 12月, 2009 3 次提交
  8. 05 12月, 2009 2 次提交
  9. 01 12月, 2009 2 次提交
    • J
      mac80211: fix spurious delBA handling · 827d42c9
      Johannes Berg 提交于
      Lennert Buytenhek noticed that delBA handling in mac80211
      was broken and has remotely triggerable problems, some of
      which are due to some code shuffling I did that ended up
      changing the order in which things were done -- this was
      
        commit d75636ef
        Author: Johannes Berg <johannes@sipsolutions.net>
        Date:   Tue Feb 10 21:25:53 2009 +0100
      
          mac80211: RX aggregation: clean up stop session
      
      and other parts were already present in the original
      
        commit d92684e6
        Author: Ron Rindjunsky <ron.rindjunsky@intel.com>
        Date:   Mon Jan 28 14:07:22 2008 +0200
      
            mac80211: A-MPDU Tx add delBA from recipient support
      
      The first problem is that I moved a BUG_ON before various
      checks -- thereby making it possible to hit. As the comment
      indicates, the BUG_ON can be removed since the ampdu_action
      callback must already exist when the state is != IDLE.
      
      The second problem isn't easily exploitable but there's a
      race condition due to unconditionally setting the state to
      OPERATIONAL when a delBA frame is received, even when no
      aggregation session was ever initiated. All the drivers
      accept stopping the session even then, but that opens a
      race window where crashes could happen before the driver
      accepts it. Right now, a WARN_ON may happen with non-HT
      drivers, while the race opens only for HT drivers.
      
      For this case, there are two things necessary to fix it:
       1) don't process spurious delBA frames, and be more careful
          about the session state; don't drop the lock
      
       2) HT drivers need to be prepared to handle a session stop
          even before the session was really started -- this is
          true for all drivers (that support aggregation) but
          iwlwifi which can be fixed easily. The other HT drivers
          (ath9k and ar9170) are behaving properly already.
      Reported-by: NLennert Buytenhek <buytenh@marvell.com>
      Cc: stable@kernel.org
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      827d42c9
    • J
      mac80211: fix two remote exploits · 4253119a
      Johannes Berg 提交于
      Lennert Buytenhek noticed a remotely triggerable problem
      in mac80211, which is due to some code shuffling I did
      that ended up changing the order in which things were
      done -- this was in
      
        commit d75636ef
        Author: Johannes Berg <johannes@sipsolutions.net>
        Date:   Tue Feb 10 21:25:53 2009 +0100
      
          mac80211: RX aggregation: clean up stop session
      
      The problem is that the BUG_ON moved before the various
      checks, and as such can be triggered.
      
      As the comment indicates, the BUG_ON can be removed since
      the ampdu_action callback must already exist when the
      state is OPERATIONAL.
      
      A similar code path leads to a WARN_ON in
      ieee80211_stop_tx_ba_session, which can also be removed.
      
      Cc: stable@kernel.org [2.6.29+]
      Cc: Lennert Buytenhek <buytenh@marvell.com>
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4253119a
  10. 30 11月, 2009 1 次提交
  11. 29 11月, 2009 4 次提交
  12. 26 11月, 2009 1 次提交
  13. 24 11月, 2009 3 次提交
  14. 20 11月, 2009 3 次提交