1. 07 5月, 2009 2 次提交
  2. 23 4月, 2009 12 次提交
  3. 21 4月, 2009 2 次提交
  4. 18 4月, 2009 2 次提交
  5. 16 4月, 2009 1 次提交
    • M
      mac80211: quiet beacon loss messages · a860402d
      Michael Buesch 提交于
      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: NMichael Buesch <mb@bu3sch.de>
      a860402d
  6. 28 3月, 2009 11 次提交
    • K
      mac80211: add beacon filtering support · 04de8381
      Kalle Valo 提交于
      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: NKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      04de8381
    • K
      mac80211: track beacons separately from the rx path activity · 15b7b062
      Kalle Valo 提交于
      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: NKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      15b7b062
    • K
      mac80211: decrease execution of the associated timer · 3cf335d5
      Kalle Valo 提交于
      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: NKalle Valo <kalle.valo@nokia.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      3cf335d5
    • J
      mac80211: remove mixed-cell and userspace MLME code · 7986cf95
      Johannes Berg 提交于
      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: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      7986cf95
    • J
      nl80211: Remove NL80211_CMD_SET_MGMT_EXTRA_IE · 65fc73ac
      Jouni Malinen 提交于
      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: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      65fc73ac
    • J
      nl80211: Add MLME primitives to support external SME · 636a5d36
      Jouni Malinen 提交于
      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: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      636a5d36
    • J
      nl80211: Event notifications for MLME events · 6039f6d2
      Jouni Malinen 提交于
      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: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      6039f6d2
    • J
      mac80211: Fix reassociation by not clearing previous BSSID · a299542e
      Jouni Malinen 提交于
      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: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      a299542e
    • J
    • H
      mac80211: start pending scan after probe/auth/assoc timed out · 11432379
      Helmut Schaa 提交于
      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: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      11432379
    • J
      mac80211: remove ieee80211_num_regular_queues · 176be728
      Johannes Berg 提交于
      This inline is useless and actually makes the code _longer_
      rather than shorter.
      Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      176be728
  7. 17 3月, 2009 2 次提交
    • H
      mac80211: handle failed scan requests in STA mode · af88b907
      Helmut Schaa 提交于
      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: NHelmut Schaa <helmut.schaa@googlemail.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      af88b907
    • J
      mac80211: Fix WMM ACM parsing and AC downgrade operation · 0eeb59fe
      Jouni Malinen 提交于
      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: NJouni Malinen <jouni.malinen@atheros.com>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      0eeb59fe
  8. 06 3月, 2009 2 次提交
  9. 28 2月, 2009 4 次提交
  10. 14 2月, 2009 2 次提交