1. 27 Oct, 2009 1 commit
    • Reinette Chatre's avatar
      mac80211: fix ibss joining · d419b9f0
      Reinette Chatre authored
      Recent commit "mac80211: fix logic error ibss merge bssid check" fixed
      joining of ibss cell when static bssid is provided. In this case
      ifibss->bssid is set before the cell is joined and comparing that address
      to a bss should thus always succeed. Unfortunately this change broke the
      other case of joining a ibss cell without providing a static bssid where
      the value of ifibss->bssid is not set before the cell is joined.
      
      Since ifibss->bssid may be set before or after joining the cell we do not
      learn anything by comparing it to a known bss. Remove this check.
      Signed-off-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d419b9f0
  2. 12 Oct, 2009 2 commits
  3. 04 Aug, 2009 1 commit
    • Luis R. Rodriguez's avatar
      mac80211: redefine usage of the mac80211 workqueue · 42935eca
      Luis R. Rodriguez authored
      The mac80211 workqueue exists to enable mac80211 and drivers
      to queue their own work on a single threaded workqueue. mac80211
      takes care to flush the workqueue during suspend but we never
      really had requirements on drivers for how they should use
      the workqueue in consideration for suspend.
      
      We extend mac80211 to document how the mac80211 workqueue should
      be used, how it should not be used and finally move raw access to
      the workqueue to mac80211 only. Drivers and mac80211 use helpers
      to queue work onto the mac80211 workqueue:
      
        * ieee80211_queue_work()
        * ieee80211_queue_delayed_work()
      
      These helpers will now warn if mac80211 already completed its
      suspend cycle and someone is trying to queue work. mac80211
      flushes the mac80211 workqueue prior to suspend a few times,
      but we haven't taken the care to ensure drivers won't add more
      work after suspend. To help with this we add a warning when
      someone tries to add work and mac80211 already completed the
      suspend cycle.
      
      Drivers should ensure they cancel any work or delayed work
      in the mac80211 stop() callback.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      42935eca
  4. 27 Jul, 2009 1 commit
  5. 24 Jul, 2009 1 commit
    • Johannes Berg's avatar
      cfg80211: rework key operation · fffd0934
      Johannes Berg authored
      This reworks the key operation in cfg80211, and now only
      allows, from userspace, configuring keys (via nl80211)
      after the connection has been established (in managed
      mode), the IBSS been joined (in IBSS mode), at any time
      (in AP[_VLAN] modes) or never for all the other modes.
      
      In order to do shared key authentication correctly, it
      is now possible to give a WEP key to the AUTH command.
      To configure static WEP keys, these are given to the
      CONNECT or IBSS_JOIN command directly, for a userspace
      SME it is assumed it will configure it properly after
      the connection has been established.
      
      Since mac80211 used to check the default key in IBSS
      mode to see whether or not the network is protected,
      it needs an update in that area, as well as an update
      to make use of the WEP key passed to auth() for shared
      key authentication.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      fffd0934
  6. 10 Jul, 2009 1 commit
    • Johannes Berg's avatar
      mac80211: push rx status into skb->cb · f1d58c25
      Johannes Berg authored
      Within mac80211, we often need to copy the rx status into
      skb->cb. This is wasteful, as drivers could be building it
      in there to start with. This patch changes the API so that
      drivers are expected to pass the RX status in skb->cb, now
      accessible as IEEE80211_SKB_RXCB(skb). It also updates all
      drivers to pass the rx status in there, but only by making
      them memcpy() it into place before the call to the receive
      function (ieee80211_rx(_irqsafe)). Each driver can now be
      optimised on its own schedule.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f1d58c25
  7. 20 May, 2009 2 commits
  8. 13 May, 2009 2 commits
  9. 06 May, 2009 7 commits
    • Johannes Berg's avatar
      mac80211: tell driver when idle · 5cff20e6
      Johannes Berg authored
      When we aren't doing anything in mac80211, we can turn off
      much of the hardware, depending on the driver/hw. Not doing
      anything, aka being idle, means:
      
       * no monitor interfaces
       * no AP/mesh/wds interfaces
       * any station interfaces are in DISABLED state
       * any IBSS interfaces aren't trying to be in a network
       * we aren't trying to scan
      
      By creating a new function that verifies these conditions and calling
      it at strategic points where the states of those conditions change,
      we can easily make mac80211 tell the driver when we are idle to save
      power.
      
      Additionally, this fixes a small quirk where a recalculated powersave
      state is passed to the driver even if the hardware is about to stopped
      completely.
      
      This patch intentionally doesn't touch radio_enabled because that is
      currently implemented to be a soft rfkill which is inappropriate here
      when we need to be able to wake up with low latency.
      
      One thing I'm not entirely sure about is this:
      
        phy0: device no longer idle - in use
        wlan0: direct probe to AP 00:11:24:91:07:4d try 1
        wlan0 direct probe responded
        wlan0: authenticate with AP 00:11:24:91:07:4d
        wlan0: authenticated
      > phy0: device now idle
      > phy0: device no longer idle - in use
        wlan0: associate with AP 00:11:24:91:07:4d
        wlan0: RX AssocResp from 00:11:24:91:07:4d (capab=0x401 status=0 aid=1)
        wlan0: associated
      
      Is it appropriate to go into idle state for a short time when we have
      just authenticated, but not associated yet? This happens only with the
      userspace SME, because we cannot really know how long it will wait
      before asking us to associate. Would going idle after a short timeout
      be more appropriate? We may need to revisit this, depending on what
      happens.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5cff20e6
    • Johannes Berg's avatar
      mac80211: add driver ops wrappers · 24487981
      Johannes Berg authored
      In order to later add tracing or verifications to the driver
      calls mac80211 makes, this patch adds static inline wrappers
      for all operations.
      
      All calls are now written as
      
      	drv_<op>(local, ...);
      
      instead of
      
      	local->ops-><op>(&local->hw, ...);
      
      Where necessary, the wrappers also do existence checking and
      return default values as appropriate.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      24487981
    • Johannes Berg's avatar
      mac80211: unify config_interface and bss_info_changed · 2d0ddec5
      Johannes Berg authored
      The config_interface method is a little strange, it contains the
      BSSID and beacon updates, while bss_info_changed contains most
      other BSS information for each interface. This patch removes
      config_interface and rolls all the information it previously
      passed to drivers into bss_info_changed.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2d0ddec5
    • Johannes Berg's avatar
      mac80211: clean up beacon interval settings · 57c4d7b4
      Johannes Berg authored
      We currently have two beacon interval configuration knobs:
      hw.conf.beacon_int and vif.bss_info.beacon_int. This is
      rather confusing, even though the former is used when we
      beacon ourselves and the latter when we are associated to
      an AP.
      
      This just deprecates the hw.conf.beacon_int setting in favour
      of always using vif.bss_info.beacon_int. Since it touches all
      the beaconing IBSS code anyway, we can also add support for
      the cfg80211 IBSS beacon interval configuration easily.
      
      NOTE: The hw.conf.beacon_int setting is retained for now due
            to drivers still using it -- I couldn't untangle all
            drivers, some are updated in this patch.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      57c4d7b4
    • Johannes Berg's avatar
      mac80211: fix scan races and rework scanning · f3b85252
      Johannes Berg authored
      There are some places marked
      	/* XXX maybe racy? */
      and they really are racy because there's no locking.
      
      This patch reworks much of the scan code, and introduces proper
      locking for the scan request as well as the internal scanning
      (which is necessary for IBSS/managed modes). Helper functions
      are added to call the scanning code whenever necessary. The
      scan deferring is changed to simply queue the scanning work
      instead of trying to start the scan in place, the scanning work
      will then take care of the rest.
      
      Also, currently when internal scans are requested for an interface
      that is trying to associate, we reject such scans. This was not
      intended, the mlme code has provisions to scan twice when it can't
      find the BSS to associate with right away; this has never worked
      properly. Fix this by not rejecting internal scan requests for an
      interface that is associating.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      f3b85252
    • Johannes Berg's avatar
      mac80211: internally clear failed scans properly · 2d722890
      Johannes Berg authored
      When the IBSS code wants to scan, but that fails, we can
      get stuck in a situation where you can never scan again.
      Fix this by properly notifying ourselves when the scan
      request has failed.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      2d722890
    • Johannes Berg's avatar
      mac80211: fix various problems in ibss code · 0e41f715
      Johannes Berg authored
      There are a few problems in the IBSS code:
       a) it tries to activate interfaces that are down after scanning
       b) it crashes after scanning on an IBSS iface that isn't active
       c) since the ssid_len is used as a flag, need to make it visible
          only after all other settings are set, this helps protect
          against b)
      
      For b), we get a system crash:
      
      wlan0: Creating new IBSS network, BSSID ce:f9:88:76:1e:4d
      BUG: unable to handle kernel NULL pointer dereference at (null)
      IP: [<...>] ieee80211_sta_find_ibss+0x294/0x37d [mac80211]
      Call Trace:
       [<...>] ieee80211_ibss_notify_scan_completed+0x0/0x88 [mac80211]
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0e41f715
  10. 22 Apr, 2009 2 commits
  11. 27 Mar, 2009 1 commit
  12. 05 Mar, 2009 1 commit
  13. 27 Feb, 2009 4 commits