16 Apr, 2010

1 commit


01 Apr, 2010

1 commit

  • 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: Zhu Yi
    Cc: Kalle Valo
    Cc: Johannes Berg
    Signed-off-by: John W. Linville

    Zhu Yi
     

30 Mar, 2010

1 commit

  • …it 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.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    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
    file.

    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
    files.

    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
    necessary.

    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: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

23 Jan, 2010

1 commit

  • ieee80211_hdrlen() should account account new HT Control field in 802.11
    data frame header introduced by IEEE 802.11n standard.

    According to 802.11n-2009 HT Control field is present in data frames
    when both of following are met:

    1. It is QoS data frame.
    2. Order bit is set in Frame Control field.

    The change might be totally compatible with legacy non-11n aware frames,
    because 802.11-2007 standard states that "all QoS STAs set this subfield
    to 0".

    Signed-off-by: Andriy V. Tkachuk
    Acked-by : Benoit Papillault
    Signed-off-by: John W. Linville

    Andriy Tkachuk
     

23 Dec, 2009

1 commit

  • Move the A-MSDU handling code from mac80211 to cfg80211 so that more
    drivers can use it. The new created function ieee80211_amsdu_to_8023s
    converts an A-MSDU frame to a list of 802.3 frames.

    Cc: Johannes Berg
    Signed-off-by: Zhu Yi
    Signed-off-by: John W. Linville

    Zhu Yi
     

22 Dec, 2009

1 commit

  • Previously, cfg80211 had reported "0" for MCS (i.e. 802.11n) bitrates
    through the wireless extensions interface. However, nl80211 was
    converting MCS rates into a reasonable bitrate number. This patch moves
    the nl80211 code to cfg80211 where it is now shared between both the
    nl80211 interface and the wireless extensions interface.

    Signed-off-by: John W. Linville

    John W. Linville
     

20 Nov, 2009

2 commits

  • 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: Johannes Berg
    Acked-by: Stephen Hemminger
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • 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: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

12 Nov, 2009

1 commit

  • 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: Felix Fietkau
    Signed-off-by: John W. Linville

    Felix Fietkau
     

29 Aug, 2009

1 commit

  • 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: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

14 Aug, 2009

1 commit

  • 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
    versions.

    Signed-off-by: Andrey Yurovsky
    Signed-off-by: Javier Cardona
    Signed-off-by: John W. Linville

    Javier Cardona
     

25 Jul, 2009

2 commits

  • 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: Zhu Yi
    Signed-off-by: John W. Linville

    Zhu Yi
     
  • 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: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

11 Jul, 2009

1 commit


04 Jun, 2009

2 commits


23 May, 2009

1 commit

  • The patch moves some utility functions from mac80211 to cfg80211.
    Because these functions are doing generic 802.11 operations so they
    are not mac80211 specific. The moving allows some fullmac drivers
    to be also benefit from these utility functions.

    Signed-off-by: Zhu Yi
    Signed-off-by: Samuel Ortiz
    Signed-off-by: John W. Linville

    Zhu Yi
     

21 May, 2009

1 commit


14 May, 2009

1 commit

  • Move key handling wireless extension ioctls from mac80211 to cfg80211
    so that all drivers that implement the cfg80211 operations get wext
    compatibility.

    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: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

23 Apr, 2009

1 commit

  • 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: Johannes Berg
    Cc: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Johannes Berg
     

30 Jan, 2009

1 commit

  • Since the standards only define 12 legacy rates, 32 is certainly
    a sane upper limit and we don't need to use u64 everywhere. Add
    sanity checking that no more than 32 rates are registered and
    change the variables to u32 throughout.

    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     

11 Nov, 2008

1 commit


28 Mar, 2008

1 commit

  • This patch makes ieee80211_get_channel a static inline defined in
    cfg80211's header file which simply calls __ieee80211_get_channel
    to avoid symbol clashes with the ieee80211 code.

    The problem was pointed out by David Miller, thanks!

    Signed-off-by: Johannes Berg
    Cc: David Miller
    Signed-off-by: John W. Linville

    Johannes Berg
     

26 Mar, 2008

1 commit


01 Mar, 2008

3 commits

  • 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: Ivo van Doorn
    Signed-off-by: John W. Linville

    Ivo van Doorn
     
  • 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: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • 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: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg