1. 12 Mar, 2012 1 commit
  2. 31 Oct, 2011 1 commit
  3. 08 Aug, 2011 2 commits
  4. 27 Aug, 2010 1 commit
  5. 07 May, 2010 1 commit
    • Johannes Berg's avatar
      cfg80211/mac80211: better channel handling · f444de05
      Johannes Berg authored
      Currently (all tested with hwsim) you can do stupid
      things like setting up an AP on a certain channel,
      then adding another virtual interface and making
      that associate on another channel -- this will make
      the beaconing to move channel but obviously without
      the necessary IEs data update.
      In order to improve this situation, first make the
      configuration APIs (cfg80211 and nl80211) aware of
      multi-channel operation -- we'll eventually need
      that in the future anyway. There's one userland API
      change and one API addition. The API change is that
      now SET_WIPHY must be called with virtual interface
      index rather than only wiphy index in order to take
      effect for that interface -- luckily all current
      users (hostapd) do that. For monitor interfaces, the
      old setting is preserved, but monitors are always
      slaved to other devices anyway so no guarantees.
      The second userland API change is the introduction
      of a per virtual interface SET_CHANNEL command, that
      hostapd should use going forward to make it easier
      to understand what's going on (it can automatically
      detect a kernel with this command).
      Other than mac80211, no existing cfg80211 drivers
      are affected by this change because they only allow
      a single virtual interface.
      mac80211, however, now needs to be aware that the
      channel settings are per interface now, and needs
      to disallow (for now) real multi-channel operation,
      which is another important part of this patch.
      One of the immediate benefits is that you can now
      start hostapd to operate on a hardware that already
      has a connection on another virtual interface, as
      long as you specify the same channel.
      Note that two things are left unhandled (this is an
      improvement -- not a complete fix):
       * different HT/no-HT modes
         currently you could start an HT AP and then
         connect to a non-HT network on the same channel
         which would configure the hardware for no HT;
         that can be fixed fairly easily
       * CSA
         An AP we're connected to on a virtual interface
         might indicate switching channels, and in that
         case we would follow it, regardless of how many
         other interfaces are operating; this requires
         more effort to fix but is pretty rare after all
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  6. 30 Mar, 2010 1 commit
    • Tejun Heo's avatar
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo authored
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      The script does the followings.
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      * When the script inserts a new include, it looks at the include
  7. 28 Sep, 2009 2 commits
  8. 23 Sep, 2009 1 commit
  9. 14 Aug, 2009 4 commits
    • Johannes Berg's avatar
      cfg80211: fix locking for SIWFREQ · 4b181144
      Johannes Berg authored
      "cfg80211: validate channel settings across interfaces"
      contained a locking bug -- in the managed-mode SIWFREQ
      call it would end up running into a lock recursion.
      This fixes it by not checking that particular interface
      for a channel that it needs to stay on, which is as it
      should be as that's the interface we're setting the
      channel for.
      Reported-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Reported-by: default avatarKalle Valo <kalle.valo@iki.fi>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Tested-by: default avatarKalle Valo <kalle.valo@iki.fi>
      Tested-by: default avatarReinette Chatre <reinette.chatre@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      cfg80211: use reassociation when possible · f401a6f7
      Johannes Berg authored
      With the move of everything related to the SME from
      mac80211 to cfg80211, we lost the ability to send
      reassociation frames. This adds them back, but only
      for wireless extensions. With the userspace SME, it
      shall control assoc vs. reassoc (it already can do
      so with the nl80211 interface).
      I haven't touched the connect() implementation, so
      it is not possible to reassociate with the nl80211
      connect primitive. I think that should be done with
      the NL80211_CMD_ROAM command, but we'll have to see
      how that can be handled in the future, especially
      with fullmac chips.
      This patch addresses only the immediate regression
      we had in mac80211, which previously sent reassoc.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      cfg80211: validate channel settings across interfaces · 59bbb6f7
      Johannes Berg authored
      Currently, there's a problem that affects regulatory
      enforcement and connection stability, in that it is
      possible to switch the channel while connected to a
      network or joined to an IBSS.
      The problem comes from the fact that we only validate
      the channel against the current interface's type, not
      against any other interface. Thus, you have any type
      of interface up, additionally bring up a monitor mode
      interface and switch the channel on the monitor. This
      will obviously also switch the channel on the other
      The problem now is that if you do that while sending
      beacons for IBSS mode, you can switch to a disabled
      channel or a channel that doesn't allow beaconing.
      Combined with a managed mode interface connected to
      an AP instead of an IBSS interface, you can easily
      break the connection that way.
      To fix this, this patch validates any channel change
      with all available interfaces, and disallows such
      changes on secondary interfaces if another interface
      is connected to an AP or joined to an IBSS.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Zhu Yi's avatar
      wireless: display wext SSID when connected by cfg80211 · a42dd7ef
      Zhu Yi authored
      cfg80211 displays correct link info when connected by wext. But if
      the connection is setup by cfg80211, wext cannot display the SSID.
      This patch fixed this issue.
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  10. 29 Jul, 2009 3 commits
  11. 24 Jul, 2009 4 commits
  12. 10 Jul, 2009 3 commits
    • Johannes Berg's avatar
      cfg80211: fix locking · 667503dd
      Johannes Berg authored
      Over time, a lot of locking issues have crept into
      the smarts of cfg80211, so e.g. scan completion can
      race against a new scan, IBSS join can race against
      leaving an IBSS, etc.
      Introduce a new per-interface lock that protects
      most of the per-interface data that we need to keep
      track of, and sprinkle assertions about that lock
      everywhere. Some things now need to be offloaded to
      work structs so that we don't require being able to
      sleep in functions the drivers call. The exception
      to that are the MLME callbacks (rx_auth etc.) that
      currently only mac80211 calls because it was easier
      to do that there instead of in cfg80211, and future
      drivers implementing those calls will, if they ever
      exist, probably need to use a similar scheme like
      mac80211 anyway...
      In order to be able to handle _deauth and _disassoc
      properly, introduce a cookie passed to it that will
      determine locking requirements.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      cfg80211: keep track of BSSes · 19957bb3
      Johannes Berg authored
      In order to avoid problems with BSS structs going away
      while they're in use, I've long wanted to make cfg80211
      keep track of them. Without the SME, that wasn't doable
      but now that we have the SME we can do this too. It can
      keep track of up to four separate authentications and
      one association, regardless of whether it's controlled
      by the cfg80211 SME or the userspace SME.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      cfg80211: managed mode wext compatibility · f2129354
      Johannes Berg authored
      This adds code to make it possible to use the cfg80211
      connect() API with wireless extensions, and because the
      previous patch added emulation of that API with auth()
      and assoc(), by extension also supports wext on that.
      At the same time, removes code from mac80211 for wext,
      but doesn't yet clean up mac80211's mlme code more.
      Signed-off-by: default avatarSamuel Ortiz <samuel.ortiz@intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>