1. 05 12月, 2008 1 次提交
  2. 26 11月, 2008 2 次提交
  3. 22 11月, 2008 1 次提交
  4. 19 11月, 2008 1 次提交
    • J
      mac80211: remove ieee80211_notify_mac · 8e3bad65
      Johannes Berg 提交于
      Before ieee80211_notify_mac() was added, it was presented with the
      use case of using it to tell mac80211 that the association may
      have been lost because the firmware crashed/reset.
      
      Since then, it has also been used by iwlwifi to (slightly) speed
      up re-association after resume, a workaround around the fact that
      mac80211 has no suspend/resume handling yet. It is also not used
      by any other drivers, so clearly it cannot be necessary for "good
      enough" suspend/resume.
      
      Unfortunately, the callback suffers from a severe problem: It only
      works for station mode. If suspend/resume happens while in IBSS or
      any other mode (but station), then the callback is pointless.
      
      Recently, it has created a number of locking issues, first because
      it required rtnl locking rather than RCU due to calling sleeping
      functions within the critical section, and now because it's called
      by iwlwifi from the mac80211 workqueue that may not use the rtnl
      because it is flushed under rtnl.
      (cf. http://bugzilla.kernel.org/show_bug.cgi?id=12046)
      
      I think, therefore, that we should take a step back, remove it
      entirely for now and add the small feature it provided properly.
      For suspend and resume we will need to introduce new hooks, and for
      the case where the firmware was reset the driver will probably
      simply just pretend it has done a suspend/resume cycle to get
      mac80211 to reprogram the hardware completely, not just try to
      connect to the current AP again in station mode. When doing so, we
      will need to take into account locking issues and possibly defer
      to schedule_work from within mac80211 for the resume operation,
      while the suspend operation must be done directly.
      
      Proper suspend/resume should also not necessarily try to reconnect
      to the current AP, the time spent in suspend may have been short
      enough to not be disconnected from the AP, mac80211 will detect
      that the AP went out of range quickly if it did, and if the
      association is lost then the AP will disassoc as soon as a data
      frame is sent. We might also take into account WWOL then, and
      have mac80211 program the hardware into such a mode where it is
      available and requested.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      8e3bad65
  5. 13 11月, 2008 1 次提交
  6. 11 11月, 2008 3 次提交
  7. 01 11月, 2008 7 次提交
    • R
      mac80211: check return value of dev_alloc_skb() in ieee80211_sta_join_ibss(). · e2ef12d3
      Rami Rosen 提交于
      This patch add a check on the return value of dev_alloc_skb() in
      ieee80211_sta_join_ibss() in net/mac80211/mlme.c.
      Signed-off-by: NRami Rosen <ramirose@gmail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e2ef12d3
    • J
      mac80211: insert AP sta entry after filling it · ddf4ac53
      Johannes Berg 提交于
      We never clearly defined the semantics of the sta_notify callback
      and it was originally posted for iwlwifi which still doesn't use
      it at all. With the recent HT rework ath9k started relying on it,
      but I made a mistake there in that I made ath9k assume the HT
      information has already been filled in at sta_notify time. This
      isn't a hard thing to do, so do it.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ddf4ac53
    • J
      mac80211: inform userspace of probe/auth/assoc timeout · 4a68ec53
      Johannes Berg 提交于
      I noticed that when for some reason [1] the probe or auth times
      out, wpa_supplicant doesn't realise this and only tries the next
      AP when it runs into its own timeout, which is ten seconds, and
      that's quite long. Fix this by making mac80211 notify userspace
      that it didn't associate.
      
      [1] my wrt350n in mixed B/G/HT mode often runs into this, maybe
      it's because one of the antennas is broken off and for whatever
      reason it decides to use that antenna to transmit the response
      frames (auth, probe); I do see beacons fine so it's not totally
      broken. Works fine in pure-G mode.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      4a68ec53
    • J
      mac80211: rewrite HT handling · ae5eb026
      Johannes Berg 提交于
      The HT handling has the following deficiencies, which I've
      (partially) fixed:
       * it always uses the AP info even if there is no AP,
         hence has no chance of working as an AP
       * it pretends to be HW config, but really is per-BSS
       * channel sanity checking is left to the drivers
       * it generally lets the driver control too much
      
      HT enabling is still wrong with this patch if you have more than
      one virtual STA mode interface, but that never happens currently.
      Once WDS, IBSS or AP/VLAN gets HT capabilities, it will also be
      wrong, see the comment in ieee80211_enable_ht().
      
      Additionally, this fixes a number of bugs:
       * mac80211: ieee80211_set_disassoc doesn't notify the driver any
                   more since the refactoring
       * iwl-agn-rs: always uses the HT capabilities from the wrong stuff
                     mac80211 gives it rather than the actual peer STA
       * ath9k: a number of bugs resulting from the broken HT API
      
      I'm not entirely happy with putting the HT capabilities into
      struct ieee80211_sta as restricted to our own HT TX capabilities,
      but I see no cleaner solution for now.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ae5eb026
    • J
      mac80211: move bss_conf into vif · bda3933a
      Johannes Berg 提交于
      Move bss_conf into the vif struct so that drivers can
      access it during ->tx without having to store it in
      the private data or similar. No driver updates because
      this is only for when they want to start using it.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      bda3933a
    • J
      802.11: clean up/fix HT support · d9fe60de
      Johannes Berg 提交于
      This patch cleans up a number of things:
       * the unusable definition of the HT capabilities/HT information
         information elements
       * variable names that are hard to understand
       * mac80211: move ieee80211_handle_ht to ht.c and remove the unused
                   enable_ht parameter
       * mac80211: fix bug with MCS rate 32 in ieee80211_handle_ht
       * mac80211: fix bug with casting the result of ieee80211_bss_get_ie
                   to an information element _contents_ rather than the
                   whole element, add size checking (another out-of-bounds
                   access bug fixed!)
       * mac80211: remove some unused return values in favour of BUG_ON
                   checking
       * a few minor other things
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      d9fe60de
    • J
      mac80211: fix short slot handling · 7a5158ef
      Johannes Berg 提交于
      This patch makes mac80211 handle short slot requests from the AP
      properly. Also warn about uses of IEEE80211_CONF_SHORT_SLOT_TIME
      and optimise out the code since it cannot ever be hit anyway.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7a5158ef
  8. 28 10月, 2008 1 次提交
  9. 15 10月, 2008 1 次提交
  10. 07 10月, 2008 2 次提交
    • J
      mac80211: avoid "Wireless Event too big" message for assoc response · ad788b5e
      John W. Linville 提交于
      The association response IEs are sent to userland with an IWEVCUSTOM
      event, which unfortunately is limited to a little more than 100 bytes
      of IE information with the encoding used.  Many APs send so much
      IE information that this message overflows.  When the IWEVCUSTOM
      event is too large, the kernel doesn't send it to userland anyway --
      better just not to send it.
      
      An attempt was made by Jouni Malinen to correct this issue by
      converting to use IWEVASSOCREQIE and IWEVASSOCRESPIE messages instead
      ("mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM").  Unfortunately,
      that caused a problem due to 32-/64-bit interactions on some systems and
      was reverted after the 'userland ABI' rule was invoked.  That leaves
      us with this option instead of a proper fix, at least until we move
      to a cfg80211-based solution.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      ad788b5e
    • L
      wireless: restore revert lost to merge damage · 74af0250
      Linus Torvalds 提交于
      Restore revert "mac80211: Use IWEVASSOCREQIE instead of IWEVCUSTOM",
      originally reverted in commit bf7394cc.
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      74af0250
  11. 25 9月, 2008 3 次提交
  12. 16 9月, 2008 12 次提交
  13. 12 9月, 2008 5 次提交