1. 06 May, 2009 10 commits
    • Luis R. Rodriguez's avatar
      mac80211: Fix sparse warning for ssid_len on ieee80211_sta_config_auth() · 6cfe62cd
      Luis R. Rodriguez authored
      net/mac80211/mlme.c:2079:28: warning: symbol 'ssid_len' shadows an earlier one
      net/mac80211/mlme.c:2022:12: originally declared here
      
      ssid_len is already being declared and checked above so there is
      no need for it again.
      Signed-off-by: default avatarLuis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6cfe62cd
    • 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: fix probe response processing · 16cf438a
      Johannes Berg authored
      Due to the use of a _REQ_DIRECT_PROBE bit, which is
      unnecessary (and I wonder why it was done that way),
      an interesting situation can arise:
       1) we try to probe an access point
       2) the AP doesn't response in time
       3) we tell userspace that we gave up
       4) the AP suddenly responds
       5) we auth/assoc with the AP
      
      I've seen 4) happen in testing with hostapd SIGSTOPped,
      and when SIGCONTinued it processes the probe requests
      that came in and send responses. But 5) is not supposed
      to happen after we tell everybody we've given up on the
      AP.
      
      To fix this, remove the _REQ_DIRECT_PROBE request bit,
      and process probe responses when we're in the relevant
      MLME state, namely IEEE80211_STA_MLME_DIRECT_PROBE.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      16cf438a
    • Jouni Malinen's avatar
      nl80211: Send timeout event on failed direct probe · e61f2340
      Jouni Malinen authored
      If the direct probe times out, we need to send the authentication
      timeout event to notify SME in the same way as we notify on timeout
      with authentication frames since the direct probe is run as part of
      the authentication attempt.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      e61f2340
    • 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: rename max_sleep_interval to max_sleep_period · 9ccebe61
      Johannes Berg authored
      Kalle points out that max_sleep_interval is somewhat confusing
      because the value is measured in beacon intervals, and not in
      TU. Rename it to max_sleep_period to be consistent with things
      like DTIM period that are also measured in beacon intervals.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      9ccebe61
    • Johannes Berg's avatar
      mac80211: fix PS vs. scan race · d5edaedc
      Johannes Berg authored
      When somebody changes the PS parameters while scanning
      is in progress, we enable PS -- during the scan. This
      is clearly not desirable, and we can just abort enabling
      PS when scanning since when the scan finishes it will
      be taken care of.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Reviewed-by: default avatarKalle Valo <kalle.valo@iki.fi>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      d5edaedc
  2. 22 Apr, 2009 12 commits
  3. 20 Apr, 2009 2 commits
  4. 17 Apr, 2009 2 commits
  5. 16 Apr, 2009 1 commit
    • Michael Buesch's avatar
      mac80211: quiet beacon loss messages · a860402d
      Michael Buesch authored
      On Sunday 05 April 2009 11:29:38 Michael Buesch wrote:
      > On Sunday 05 April 2009 11:23:59 Jaswinder Singh Rajput wrote:
      > > With latest linus tree I am getting, .config file attached:
      > >
      > > [   22.895051] r8169: eth0: link down
      > > [   22.897564] ADDRCONF(NETDEV_UP): eth0: link is not ready
      > > [   22.928047] ADDRCONF(NETDEV_UP): wlan0: link is not ready
      > > [   22.982292] libvirtd used greatest stack depth: 4200 bytes left
      > > [   63.709879] wlan0: authenticate with AP 00:11:95:9e:df:f6
      > > [   63.712096] wlan0: authenticated
      > > [   63.712127] wlan0: associate with AP 00:11:95:9e:df:f6
      > > [   63.726831] wlan0: RX AssocResp from 00:11:95:9e:df:f6 (capab=0x471 status=0 aid=1)
      > > [   63.726855] wlan0: associated
      > > [   63.730093] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
      > > [   74.296087] wlan0: no IPv6 routers present
      > > [   79.349044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  119.358200] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  179.354292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  259.366044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  359.348292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  361.953459] packagekitd used greatest stack depth: 4160 bytes left
      > > [  478.824258] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  598.813343] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  718.817292] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  838.824567] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [  958.815402] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1078.848434] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1198.822913] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1318.824931] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1438.814157] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1558.827336] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1678.823011] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1798.830589] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 1918.828044] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2038.827224] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2116.517152] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2158.840243] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      > > [ 2278.827427] wlan0: beacon loss from AP 00:11:95:9e:df:f6 - sending probe request
      >
      >
      > I think this message should only show if CONFIG_MAC80211_VERBOSE_DEBUG is set.
      > It's kind of expected that we lose a beacon once in a while, so we shouldn't print
      > verbose messages to the kernel log (even if they are KERN_DEBUG).
      >
      > And besides that, I think one can easily remotely trigger this message and flood the logs.
      > So it should probably _also_ be ratelimited.
      
      Something like this:
      Signed-off-by: default avatarMichael Buesch <mb@bu3sch.de>
      a860402d
  6. 27 Mar, 2009 11 commits
    • Kalle Valo's avatar
      mac80211: add beacon filtering support · 04de8381
      Kalle Valo authored
      Add IEEE80211_HW_BEACON_FILTERING flag so that driver inform that it supports
      beacon filtering. Drivers need to call the new function
      ieee80211_beacon_loss() to notify about beacon loss.
      Signed-off-by: default avatarKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      04de8381
    • Kalle Valo's avatar
      mac80211: track beacons separately from the rx path activity · 15b7b062
      Kalle Valo authored
      Separate beacon and rx path tracking in preparation for the beacon filtering
      support. At the same time change ieee80211_associated() to look a bit simpler.
      
      Probe requests are now sent only after IEEE80211_PROBE_IDLE_TIME, which
      is now set to 60 seconds.
      Signed-off-by: default avatarKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      15b7b062
    • Kalle Valo's avatar
      mac80211: decrease execution of the associated timer · 3cf335d5
      Kalle Valo authored
      Currently the timer is triggering every two seconds
      (IEEE80211_MONITORING_INTERVAL). Decrease the timer to only trigger during
      data idle periods to avoid waking up CPU unnecessary. The timer will
      still trigger during idle periods, that needs to be fixed later.
      
      There's also a functional change that probe requests are sent only when the
      data path is idle, earlier they were sent also while there was activity
      on the data path.
      
      This is also preparation for the beacon filtering support. Thanks to
      Johannes Berg for the idea.
      Signed-off-by: default avatarKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      3cf335d5
    • Johannes Berg's avatar
      mac80211: remove mixed-cell and userspace MLME code · 7986cf95
      Johannes Berg authored
      Neither can currently be set from userspace, so there's no
      regression potential, and neither will be supported from
      userspace since the new userspace APIs allow the SME, which
      is in userspace, to control all we need.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      7986cf95
    • Jouni Malinen's avatar
      nl80211: Remove NL80211_CMD_SET_MGMT_EXTRA_IE · 65fc73ac
      Jouni Malinen authored
      The functionality that NL80211_CMD_SET_MGMT_EXTRA_IE provided can now
      be achieved with cleaner design by adding IE(s) into
      NL80211_CMD_TRIGGER_SCAN, NL80211_CMD_AUTHENTICATE,
      NL80211_CMD_ASSOCIATE, NL80211_CMD_DEAUTHENTICATE, and
      NL80211_CMD_DISASSOCIATE.
      
      Since this is a very recently added command and there are no known (or
      known planned) applications using NL80211_CMD_SET_MGMT_EXTRA_IE and
      taken into account how much extra complexity it adds to the IE
      processing we have now (and need to add in the future to fix IE order
      in couple of frames), it looks like the best option is to just remove
      the implementation of this command for now. The enum values themselves
      are left to avoid changing the nl80211 command or attribute numbers.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      65fc73ac
    • Jouni Malinen's avatar
      nl80211: Add MLME primitives to support external SME · 636a5d36
      Jouni Malinen authored
      This patch adds new nl80211 commands to allow user space to request
      authentication and association (and also deauthentication and
      disassociation). The commands are structured to allow separate
      authentication and association steps, i.e., the interface between
      kernel and user space is similar to the MLME SAP interface in IEEE
      802.11 standard and an user space application takes the role of the
      SME.
      
      The patch introduces MLME-AUTHENTICATE.request,
      MLME-{,RE}ASSOCIATE.request, MLME-DEAUTHENTICATE.request, and
      MLME-DISASSOCIATE.request primitives. The authentication and
      association commands request the actual operations in two steps
      (assuming the driver supports this; if not, separate authentication
      step is skipped; this could end up being a separate "connect"
      command).
      
      The initial implementation for mac80211 uses the current
      net/mac80211/mlme.c for actual sending and processing of management
      frames and the new nl80211 commands will just stop the current state
      machine from moving automatically from authentication to association.
      Future cleanup may move more of the MLME operations into cfg80211.
      
      The goal of this design is to provide more control of authentication and
      association process to user space without having to move the full MLME
      implementation. This should be enough to allow IEEE 802.11r FT protocol
      and 802.11s SAE authentication to be implemented. Obviously, this will
      also bring the extra benefit of not having to use WEXT for association
      requests with mac80211. An example implementation of a user space SME
      using the new nl80211 commands is available for wpa_supplicant.
      
      This patch is enough to get IEEE 802.11r FT protocol working with
      over-the-air mechanism (over-the-DS will need additional MLME
      primitives for handling the FT Action frames).
      Signed-off-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      636a5d36
    • Jouni Malinen's avatar
      nl80211: Event notifications for MLME events · 6039f6d2
      Jouni Malinen authored
      Add new nl80211 event notifications (and a new multicast group, "mlme")
      for informing user space about received and processed Authentication,
      (Re)Association Response, Deauthentication, and Disassociation frames in
      station and IBSS modes (i.e., MLME SAP interface primitives
      MLME-AUTHENTICATE.confirm, MLME-ASSOCIATE.confirm,
      MLME-REASSOCIATE.confirm, MLME-DEAUTHENTICATE.indicate, and
      MLME-DISASSOCIATE.indication). The event data is encapsulated as the 802.11
      management frame since we already have the frame in that format and it
      includes all the needed information.
      
      This is the initial step in providing MLME SAP interface for
      authentication and association with nl80211. In other words, kernel code
      will act as the MLME and a user space application can control it as the
      SME.
      Signed-off-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      6039f6d2
    • Jouni Malinen's avatar
      mac80211: Fix reassociation by not clearing previous BSSID · a299542e
      Jouni Malinen authored
      We must not clear the previous BSSID when roaming to another AP within
      the same ESS for reassociation to be used properly. It is fine to
      clear this when the SSID changes, so let's move the code into
      ieee80211_sta_set_ssid().
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a299542e
    • Jouni Malinen's avatar
    • Helmut Schaa's avatar
      mac80211: start pending scan after probe/auth/assoc timed out · 11432379
      Helmut Schaa authored
      If a scan is queued in STA mode while the interface is in state direct
      probe, authenticate or associate the scan is delayed until the interface
      enters disabled or associated state. But in case of direct probe-,
      authentication- or association- timeout sta_work will not be scheduled
      anymore (without external trigger) and thus the pending scan is not
      executed and prevents a new scan from being triggered (-EBUSY).
      
      Fix this by queueing the sta work again after direct probe-, authentication-
      and association- timeout.
      Signed-off-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      11432379
    • Johannes Berg's avatar
      mac80211: remove ieee80211_num_regular_queues · 176be728
      Johannes Berg authored
      This inline is useless and actually makes the code _longer_
      rather than shorter.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      176be728
  7. 16 Mar, 2009 2 commits
    • Helmut Schaa's avatar
      mac80211: handle failed scan requests in STA mode · af88b907
      Helmut Schaa authored
      If cfg80211 requests a scan it awaits either a return code != 0 from
      the scan function or the cfg80211_scan_done to be called. In case of
      a STA mac80211's scan function ever returns 0 and queues the scan request.
      If ieee80211_sta_work is executed and ieee80211_start_scan fails for
      some reason cfg80211_scan_done will never be called but cfg80211 still
      thinks the scan was triggered successfully and will refuse any future
      scan requests due to drv->scan_req not being cleaned up.
      
      If a scan is triggered from within the MLME a similar problem appears. If
      ieee80211_start_scan returns an error, local->scan_req will not be reset
      and mac80211 will refuse any future scan requests.
      
      Hence, in both cases call ieee80211_scan_failed (which notifies cfg80211
      and resets local->scan_req) if ieee80211_start_scan returns an error.
      Signed-off-by: default avatarHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      af88b907
    • Jouni Malinen's avatar
      mac80211: Fix WMM ACM parsing and AC downgrade operation · 0eeb59fe
      Jouni Malinen authored
      Incorrect local->wmm_acm bits were set for AC_BK and AC_BE. Fix this
      and add some comments to make it easier to understand the AC-to-UP(pair)
      mapping. Set the wmm_acm bits (and show WMM debug) even if the driver
      does not implement conf_tx() handler.
      
      In addition, fix the ACM-based AC downgrade code to not use the
      highest priority in error cases. We need to break the loop to get the
      correct AC_BK value (3) instead of returning 0 (which would indicate
      AC_VO). The comment here was not really very useful either, so let's
      provide somewhat more helpful description of the situation.
      
      Since it is very unlikely that the ACM flag would be set for AC_BK and
      AC_BE, these bugs are not likely to be seen in real life networks.
      Anyway, better do these things correctly should someone really use
      silly AP configuration (and to pass some functionality tests, too).
      
      Remove the TODO comment about handling ACM. Downgrading AC is
      perfectly valid mechanism for ACM. Eventually, we may add support for
      WMM-AC and send a request for a TS, but anyway, that functionality
      won't be here at the location of this TODO comment.
      Signed-off-by: default avatarJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      0eeb59fe