1. 13 Dec, 2010 1 commit
  2. 06 Dec, 2010 1 commit
    • Johannes Berg's avatar
      cfg80211/mac80211: add mesh join/leave commands · 29cbe68c
      Johannes Berg authored
      Instead of tying mesh activity to interface up,
      add join and leave commands for mesh. Since we
      must be backward compatible, let cfg80211 handle
      joining a mesh if a mesh ID was pre-configured
      when the device goes up.
      Note that this therefore must modify mac80211 as
      well since mac80211 needs to lose the logic to
      start the mesh on interface up.
      We now allow querying mesh parameters before the
      mesh is connected, which simply returns defaults.
      Setting them (internally renamed to "update") is
      only allowed while connected. Specify them with
      the new mesh join command instead where needed.
      In mac80211, beaconing must now also follow the
      mesh enabled/not enabled state, which is done
      by testing the mesh ID.
      Signed-off-by: default avatarJavier Cardona <javier@cozybit.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  3. 24 Nov, 2010 1 commit
  4. 06 Oct, 2010 1 commit
  5. 16 Sep, 2010 1 commit
  6. 27 Aug, 2010 1 commit
  7. 24 Aug, 2010 2 commits
  8. 15 Jun, 2010 1 commit
  9. 31 Mar, 2010 1 commit
    • Zhu Yi's avatar
      mac80211: support paged rx SKBs · e3cf8b3f
      Zhu Yi authored
      Mac80211 drivers can now pass paged SKBs to mac80211 via
      ieee80211_rx{_irqsafe}. The implementation currently use
      skb_linearize() in a few places i.e. management frame
      handling, software decryption, defragmentation and A-MSDU
      process. We will optimize them one by one later.
      Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
      Cc: Kalle Valo <kalle.valo@iki.fi>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  10. 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
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
      The conversion was done in the following steps.
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
      6. percpu.h was updated not to include slab.h.
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Guess-its-ok-by: default avatarChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
  11. 22 Jan, 2010 1 commit
  12. 22 Dec, 2009 1 commit
  13. 21 Dec, 2009 1 commit
  14. 19 Nov, 2009 2 commits
    • Johannes Berg's avatar
      cfg80211: disallow bridging managed/adhoc interfaces · ad4bb6f8
      Johannes Berg authored
      A number of people have tried to add a wireless interface
      (in managed mode) to a bridge and then complained that it
      doesn't work. It cannot work, however, because in 802.11
      networks all packets need to be acknowledged and as such
      need to be sent to the right address. Promiscuous doesn't
      help here. The wireless address format used for these
      links has only space for three addresses, the
       * transmitter, which must be equal to the sender (origin)
       * receiver (on the wireless medium), which is the AP in
         the case of managed mode
       * the recipient (destination), which is on the APs local
         network segment
      In an IBSS, it is similar, but the receiver and recipient
      must match and the third address is used as the BSSID.
      To avoid such mistakes in the future, disallow adding a
      wireless interface to a bridge.
      Felix has recently added a four-address mode to the AP
      and client side that can be used (after negotiating that
      it is possible, which must happen out-of-band by setting
      up both sides) for bridging, so allow that case.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Acked-by: default avatarStephen Hemminger <shemminger@vyatta.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      cfg80211: introduce capability for 4addr mode · 9bc383de
      Johannes Berg authored
      It's very likely that not many devices will support
      four-address mode in station or AP mode so introduce
      capability bits for both modes, set them in mac80211
      and check them when userspace tries to use the mode.
      Also, keep track of 4addr in cfg80211 (wireless_dev)
      and not in mac80211 any more. mac80211 can also be
      improved for the VLAN case by not looking at the
      4addr flag but maintaining the station pointer for
      it correctly. However, keep track of use_4addr for
      station mode in mac80211 to avoid all the derefs.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  15. 11 Nov, 2009 1 commit
    • Felix Fietkau's avatar
      mac80211: implement support for 4-address frames for AP and client mode · f14543ee
      Felix Fietkau authored
      In some situations it might be useful to run a network with an
      Access Point and multiple clients, but with each client bridged
      to a network behind it. For this to work, both the client and the
      AP need to transmit 4-address frames, containing both source and
      destination MAC addresses.
      With this patch, you can configure a client to communicate using
      only 4-address frames for data traffic.
      On the AP side you can enable 4-address frames for individual
      clients by isolating them in separate AP VLANs which are configured
      in 4-address mode.
      Such an AP VLAN will be limited to one client only, and this client
      will be used as the destination for all traffic on its interface,
      regardless of the destination MAC address in the packet headers.
      The advantage of this mode compared to regular WDS mode is that it's
      easier to configure and does not require a static list of peer MAC
      addresses on any side.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  16. 28 Aug, 2009 1 commit
    • Johannes Berg's avatar
      cfg80211: clean up properly on interface type change · 3d54d255
      Johannes Berg authored
      When the interface type changes while connected, and the
      driver does not require the interface to be down for a
      type change, it is currently possible to get very strange
      results unless the driver takes special care, which it
      shouldn't have to.
      To fix this, take care to disconnect/leave IBSS when
      changing the interface type -- even if the driver may fail
      the call. Also process all events that may be pending to
      avoid running into a situation where an event is reported
      but only processed after the type has already changed,
      which would lead to missing events and warnings.
      A side effect of this is that you will have disconnected
      or left the IBSS even if the mode change ultimately fails,
      but since the intention was to change it and thus leave or
      disconnect, this is not a problem.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  17. 14 Aug, 2009 1 commit
    • Javier Cardona's avatar
      mac80211: Use 3-address format for mesh broadcast frames. · 3c5772a5
      Javier Cardona authored
      The 11s task group recently changed the frame mesh multicast/broadcast frame
      format to use 3-address.  This was done to avoid interactions with widely
      deployed lazy-WDS access points.
      This patch changes the format of group addressed frames, both mesh-originated
      and proxied, to use the data format defined in draft D2.08 and forward.  The
      address fields used for group addressed frames is:
      In 802.11 header
       ToDS:0  FromDS:1
       addr1: DA  (broadcast/multicast address)
       addr2: TA
       addr3: Mesh SA
      In address extension header:
       addr4: SA  (only present if frame was proxied)
      Note that this change breaks backward compatibility with earlier mesh stack
      Signed-off-by: default avatarAndrey Yurovsky <andrey@cozybit.com>
      Signed-off-by: default avatarJavier Cardona <javier@cozybit.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  18. 24 Jul, 2009 2 commits
    • Zhu Yi's avatar
      cfg80211: avoid setting default_key if add_key fails · 1e056665
      Zhu Yi authored
      In cfg80211_upload_connect_keys(), we call add_key, set_default_key
      and set_default_mgmt_key (if applicable) one by one. If one of these
      operations fails, we should stop calling the following functions.
      Because if the key is not added successfully, we should not set it as
      default key anyway.
      Signed-off-by: default avatarZhu Yi <yi.zhu@intel.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • 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>
  19. 10 Jul, 2009 1 commit
  20. 03 Jun, 2009 2 commits
  21. 22 May, 2009 1 commit
  22. 20 May, 2009 1 commit
  23. 13 May, 2009 1 commit
    • Johannes Berg's avatar
      cfg80211: implement wext key handling · 08645126
      Johannes Berg authored
      Move key handling wireless extension ioctls from mac80211 to cfg80211
      so that all drivers that implement the cfg80211 operations get wext
      Note that this drops the SIOCGIWENCODE ioctl support for getting
      IW_ENCODE_RESTRICTED/IW_ENCODE_OPEN. This means that iwconfig will
      no longer report "Security mode:open" or "Security mode:restricted"
      for mac80211. However, what we displayed there (the authentication
      algo used) was actually wrong -- linux/wireless.h states that this
      setting is meant to differentiate between "Refuse non-encoded packets"
      and "Accept non-encoded packets".
      (Combined with "cfg80211: fix a couple of bugs with key ioctls". -- JWL)
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  24. 22 Apr, 2009 1 commit
    • Johannes Berg's avatar
      cfg80211: clean up includes · d3236553
      Johannes Berg authored
      Trying to separate header files into net/wireless.h and
      net/cfg80211.h has been a source of confusion. Remove
      net/wireless.h (because there also is the linux/wireless.h)
      and subsume everything into net/cfg80211.h -- except the
      definitions for regulatory structures which get moved to
      a new header net/regulatory.h.
      The "new" net/cfg80211.h is now divided into sections.
      There are no real changes in this patch but code shuffling
      and some very minor documentation fixes.
      I have also, to make things reflect reality, put in a
      copyright line for Luis to net/regulatory.h since that
      is probably exclusively written by him but was formerly
      in a file that only had my copyright line.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Cc: Luis R. Rodriguez <lrodriguez@atheros.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
  25. 29 Jan, 2009 1 commit
  26. 10 Nov, 2008 1 commit
  27. 27 Mar, 2008 1 commit
  28. 25 Mar, 2008 1 commit
  29. 29 Feb, 2008 3 commits
    • Ivo van Doorn's avatar
      wireless: Fix WARN_ON() with ieee802.11b · 406f2388
      Ivo van Doorn authored
      When the driver registers a IEEE80211_BAND_2GHZ band,
      it can either be 802.11b or 802.11g. But when 802.11b rates
      are registered "want" will be 3 (since 4 rates are being registered,
      and each of those 4 rates will decrease "want").
      Since this is a correct situation, there is no need to trigger
      a WARN_ON() for this.
      Signed-off-by: default avatarIvo van Doorn <IvDoorn@gmail.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      wireless: fix ERP rate flags · aac09fbf
      Johannes Berg authored
      In the rate API patch I accidentally reverted the test for
      ERP rates, this fixes it. All rates except 1, 2, 5.5 and 11
      MBit are ERP rates, not those.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
    • Johannes Berg's avatar
      cfg80211 API for channels/bitrates, mac80211 and driver conversion · 8318d78a
      Johannes Berg authored
      This patch creates new cfg80211 wiphy API for channel and bitrate
      registration and converts mac80211 and drivers to the new API. The
      old mac80211 API is completely ripped out. All drivers (except ath5k)
      are updated to the new API, in many cases I expect that optimisations
      can be done.
      Along with the regulatory code I've also ripped out the
      IEEE80211_HW_DEFAULT_REG_DOMAIN_CONFIGURED flag, I believe it to be
      unnecessary if the hardware simply gives us whatever channels it wants
      to support and we then enable/disable them as required, which is pretty
      much required for travelling.
      Additionally, the patch adds proper "basic" rate handling for STA
      mode interface, AP mode interface will have to have new API added
      to allow userspace to set the basic rate set, currently it'll be
      empty... However, the basic rate handling will need to be moved to
      the BSS conf stuff.
      I do expect there to be bugs in this, especially wrt. transmit
      power handling where I'm basically clueless about how it should work.
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>