19 Jun, 2009

3 commits

  • When I disallowed interfering with stations on non-AP interfaces,
    I not only forget mesh but also managed interfaces which need
    this for the authorized flag. Let's actually validate everything
    properly.

    This fixes an nl80211 regression introduced by the interfering,
    under which wpa_supplicant -Dnl80211 could not properly connect.

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

    Johannes Berg
     
  • Mesh Point interfaces can also set parameters, for example plink_open is
    used to manually establish peer links from user-space (currently via
    iw). Add Mesh Point to the check in nl80211_set_station.

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

    Andrey Yurovsky
     
  • Commit b2a151a288 added a check that prevents adding or deleting
    stations on non-AP interfaces. Adding and deleting stations is
    supported for Mesh Point interfaces, so add Mesh Point to that check as
    well.

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

    Andrey Yurovsky
     

11 Jun, 2009

2 commits

  • rfkill currently requires a global lock within the
    rfkill_register() function, and holds that lock over
    calls to the set_block() methods. This means that we
    cannot hold a lock around rfkill_register() that we
    also require in set_block(), directly or indirectly.
    Fix cfg80211 to register rfkill outside the block
    locked by its global lock. Much of what cfg80211 does
    in the locked block doesn't need to be locked anyway.

    Reported-by: Vasanthakumar Thiagarajan
    Signed-off-by: Johannes Berg
    Signed-off-by: John W. Linville

    Johannes Berg
     
  • As Pavel puts userspace can be stupid and should not
    cause kernel crashes. In this case Pavel was able to
    find a crash here but unable to reproduce. Either way
    lets deal with this.

    This should fix:

    ------------[ cut here ]------------
    kernel BUG at /home/proski/src/linux-2.6/net/wireless/reg.c:2132!
    Oops: Exception in kernel mode, sig: 5 [#1]
    PowerMac
    Modules linked in: ath5k ath [last unloaded: scsi_wait_scan]
    NIP: c02f3eac LR: c02f3d08 CTR: 00000000
    REGS: ef107aa0 TRAP: 0700 Not tainted (2.6.30-rc8-wl)
    MSR: 00029032 CR: 88002442 XER: 20000000
    TASK = ef84acb0[834] 'crda' THREAD: ef106000
    GPR00: ef953840 ef107b50 ef84acb0 ef1380bc 00000006 c035a5c8 ef107b90 c035a5c8
    GPR08: 00080005 efb68980 c0445628 ef130004 28002422 10019ce0 10012d3c 00000001
    GPR16: 1070b2ac 00000005 48023558 1070b380 4802304c 00000000 ef107ddc c035a5c8
    GPR24: ef107b78 c0443350 ef8bcb00 00000005 ef138080 c04a6a70 c04a0000 ef8bcb00
    NIP [c02f3eac] set_regdom+0x4c4/0x4ec
    LR [c02f3d08] set_regdom+0x320/0x4ec
    Call Trace:
    [ef107b50] [c02f3d08] set_regdom+0x320/0x4ec (unreliable)
    [ef107b70] [c02f9d10] nl80211_set_reg+0x140/0x2d0
    [ef107bc0] [c02aa2b8] genl_rcv_msg+0x204/0x228
    [ef107c10] [c02a97cc] netlink_rcv_skb+0xe8/0x10c
    [ef107c30] [c02aa094] genl_rcv+0x3c/0x5c
    [ef107c40] [c02a9050] netlink_unicast+0x308/0x36c
    [ef107c80] [c02a92bc] netlink_sendmsg+0x208/0x2f0
    [ef107cd0] [c0282048] sock_sendmsg+0xac/0xe4
    [ef107db0] [c02822b4] sys_sendmsg+0x234/0x2d8
    [ef107f00] [c0283a88] sys_socketcall+0x108/0x258
    [ef107f40] [c0012790] ret_from_syscall+0x0/0x38

    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     

04 Jun, 2009

9 commits

  • Fixes spares warning:
    net/wireless/util.c:261:5: warning:
    symbol 'ieee80211_get_mesh_hdrlen' was not declared. Should it be static?

    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • To be easier on drivers and users, have cfg80211 register an
    rfkill structure that drivers can access. When soft-killed,
    simply take down all interfaces; when hard-killed the driver
    needs to notify us and we will take down the interfaces
    after the fact. While rfkilled, interfaces cannot be set UP.

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

    Johannes Berg
     
  • This patch introduces new cfg80211 API to set the TX power
    via cfg80211, puts the wext code into cfg80211 and updates
    mac80211 to use all that. The -ENETDOWN bits are a hack but
    will go away soon.

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

    Johannes Berg
     
  • nl80211_michael_mic_failure can be called in atomic context but
    does a GFP_KERNEL allocation. Fixes the error below:

    [ 126.793225] BUG: sleeping function called from invalid context at mm/slab.c:3055
    [ 126.793234] in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
    [ 126.793241] 2 locks held by swapper/0:
    [ 126.793246] #0: (&sc->rxbuflock){+.-.+.}, at: [] ath5k_tasklet_rx+0x34/0x55e [ath5k]
    [ 126.793294] #1: (rcu_read_lock){.+.+.+}, at: [] __ieee80211_rx+0x7e/0x563 [mac80211]
    [ 126.793342] Pid: 0, comm: swapper Not tainted 2.6.30-rc7-wl #124
    [ 126.793347] Call Trace:
    [ 126.793361] [] ? __debug_show_held_locks+0x1e/0x20
    [ 126.793380] [] __might_sleep+0x100/0x107
    [ 126.793386] [] kmem_cache_alloc+0x35/0x170
    [ 126.793393] [] ? __alloc_skb+0x2e/0x117
    [ 126.793397] [] ? mark_held_locks+0x43/0x5b
    [ 126.793402] [] __alloc_skb+0x2e/0x117
    [ 126.793419] [] nl80211_michael_mic_failure+0x2a/0x1fa [cfg80211]
    [ 126.793425] [] ? trace_hardirqs_on_caller+0xf6/0x130
    [ 126.793430] [] ? trace_hardirqs_on+0xb/0xd
    [ 126.793444] [] cfg80211_michael_mic_failure+0x30/0x38 [cfg80211]
    [ 126.793463] [] mac80211_ev_michael_mic_failure+0xfd/0x108 [mac80211]
    [ 126.793480] [] ieee80211_rx_h_michael_mic_verify+0xd4/0x117 [mac80211]
    [ 126.793499] [] ieee80211_invoke_rx_handlers+0xdde/0x1963 [mac80211]
    [ 126.793505] [] ? sched_clock+0x3f/0x64
    [ 126.793511] [] ? sched_clock+0x3f/0x64
    [ 126.793516] [] ? trace_hardirqs_off+0xb/0xd
    [ 126.793521] [] ? sched_clock+0x3f/0x64
    [ 126.793526] [] ? __lock_acquire+0x62c/0x1271
    [ 126.793545] [] __ieee80211_rx_handle_packet+0x543/0x564 [mac80211]
    [ 126.793564] [] __ieee80211_rx+0x4e2/0x563 [mac80211]
    [ 126.793577] [] ath5k_tasklet_rx+0x4e4/0x55e [ath5k]
    [ 126.793583] [] ? restore_nocheck_notrace+0x0/0xe
    [ 126.793589] [] tasklet_action+0x92/0xe5
    [ 126.793594] [] __do_softirq+0xb1/0x182
    [ 126.793599] [] do_softirq+0x30/0x48
    [ 126.793603] [] irq_exit+0x3d/0x74
    [ 126.793609] [] do_IRQ+0x76/0x8c
    [ 126.793613] [] common_interrupt+0x2e/0x34
    [ 126.793618] [] ? timer_list_show+0x277/0x939
    [ 126.793630] [] ? acpi_idle_enter_bm+0x266/0x291 [processor]
    [ 126.793636] [] cpuidle_idle_call+0x6a/0x9c
    [ 126.793640] [] cpu_idle+0x53/0x87
    [ 126.793645] [] rest_init+0x6c/0x6e
    [ 126.793651] [] start_kernel+0x286/0x28b
    [ 126.793656] [] __init_begin+0x37/0x3c

    Signed-off-by: Bob Copeland
    Signed-off-by: John W. Linville

    Bob Copeland
     
  • This fixes an incorrect assumption (BUG_ON) made in
    cfg80211 when handling country IE regulatory requests.
    The assumption was that we won't try to call_crda()
    twice for the same event and therefore we will not
    recieve two replies through nl80211 for the regulatory
    request. As it turns out it is true we don't call_crda()
    twice for the same event, however, kobject_uevent_env()
    *might* send the udev event twice and/or userspace can
    simply process the udev event twice. We remove the BUG_ON()
    and simply ignore the duplicate request.

    For details refer to this thread:

    http://marc.info/?l=linux-wireless&m=124149987921337&w=2

    Cc: stable@kernel.org
    Reported-by: Maxim Levitsky
    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • On non-AP interfaces userspace has no business interfering with
    the station management, this can confuse mac80211 (and other
    drivers probably wouldn't support it anyway). Allow adding and
    removing stations only on AP interfaces.

    (Reconcile this w/ previous version of patch posted with same
    subject... -- JWL)

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

    Johannes Berg
     
  • Instead of hardcoding the key length for validation, use the
    constants Zhu Yi recently added and add one for AES_CMAC too.

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

    Johannes Berg
     
  • When a scan finishes only the program that asked for it
    knows what kind of scan it was; let's tell everybody else
    about the scan parameters as well so they can evaluate
    the result of the scan better. Also helps with debugging.

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

    Johannes Berg
     
  • We have some validation code in mac80211 but said code will
    force an invalid AID to 0 which isn't a valid AID either;
    instead require a valid AID (1-2007) to be passed in from
    userspace in cfg80211 already. Also move the code before
    the race comment since it can only be executed during STA
    addition and thus is not racy.

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

    Johannes Berg
     

27 May, 2009

1 commit


25 May, 2009

2 commits


23 May, 2009

2 commits

  • 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
     
  • The requirement for wireless stats to be atomic is now mostly
    artificial since we hold the rtnl _and_ the dev_base_lock for
    iterating the device list. Doing that is not required, just the
    rtnl is sufficient (and the rtnl is required for other reasons
    outlined in commit "wext: fix get_wireless_stats locking").

    This will fix http://bugzilla.kernel.org/show_bug.cgi?id=13344
    and make things easier for drivers.

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

    Johannes Berg
     

22 May, 2009

1 commit


21 May, 2009

15 commits

  • Device drivers using wiphy_apply_custom_regulatory() want some
    regulatory settings applied to their wiphy, if no bands were
    configured on the wiphy then something went wrong.

    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • If CONFIG_CFG80211_DEBUGFS is enabled and CONFIG_MAC80211_DEBUGFS is
    not, compilation fails in net/wireless/debugfs.c:

    net/wireless/debugfs.c: In function 'cfg80211_debugfs_drv_add':
    net/wireless/debugfs.c:117: error: 'struct cfg80211_registered_device'
    has no member named 'debugfs'

    The debugfs filed is needed if and only if CONFIG_CFG80211_DEBUGFS is
    enabled, so use that instead of CONFIG_MAC80211_DEBUGFS.

    Signed-off-by: Pavel Roskin
    Signed-off-by: John W. Linville

    Pavel Roskin
     
  • There is a race on access to last_request and its alpha2
    through reg_is_valid_request() and us possibly processing
    first another regulatory request on another CPU. We avoid
    this improbably race by locking with the cfg80211_mutex as
    we should have done in the first place. While at it add
    the assert on locking on reg_is_valid_request().

    Cc: stable@kernel.org
    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • This has no functional change, but it will make the race
    fix easier to spot in my next patch.

    Cc: stable@kernel.org
    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • This has no functional change except we save a kfree(rd) and
    allows us to clean this code up a bit after this. We do
    avoid an unnecessary kfree(NULL) but calling that was OK too.

    Cc: stable@kernel.org
    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • Some applications using wireless extensions expect to be able to
    remove a key that doesn't exist. One example is wpa_supplicant
    which doesn't actually change behaviour when running into an
    error while trying to do that, but it prints an error message
    which users interpret as wpa_supplicant having problems.

    The safe thing to do is not change the behaviour of wireless
    extensions any more, so when the driver reports -ENOENT let
    the wext bridge code return success to userspace. To guarantee
    this, also document that drivers should return -ENOENT when the
    key doesn't exist.

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

    Johannes Berg
     
  • This allows drivers to mark their cfg80211_ops tables const.

    Signed-off-by: David Kilroy
    Acked-by: Johannes Berg
    Signed-off-by: John W. Linville

    David Kilroy
     
  • Validate RSC (NL80211_ATTR_KEY_SEQ) length in nl80211/cfg80211 instead
    of having to do this in all the drivers.

    Signed-off-by: Jouni Malinen
    Signed-off-by: John W. Linville

    Jouni Malinen
     
  • Here's a screenshot of what this looks like with ath9k:

    mcgrof@pogo /debug/ieee80211/phy0 $ cat ht40allow_map
    2412 HT40 +
    2417 HT40 +
    2422 HT40 +
    2427 HT40 +
    2432 HT40 -+
    2437 HT40 -+
    2442 HT40 -+
    2447 HT40 -
    2452 HT40 -
    2457 HT40 -
    2462 HT40 -
    2467 Disabled
    2472 Disabled
    2484 Disabled
    5180 HT40 +
    5200 HT40 -+
    5220 HT40 -+
    5240 HT40 -+
    5260 HT40 -+
    5280 HT40 -+
    5300 HT40 -+
    5320 HT40 -
    5500 HT40 +
    5520 HT40 -+
    5540 HT40 -+
    5560 HT40 -+
    5580 HT40 -+
    5600 HT40 -+
    5620 HT40 -+
    5640 HT40 -+
    5660 HT40 -+
    5680 HT40 -+
    5700 HT40 -
    5745 HT40 +
    5765 HT40 -+
    5785 HT40 -+
    5805 HT40 -+
    5825 HT40 -

    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • This moves the cfg80211 specific stuff to new cfg80211 debugfs
    entries. Non-mac80211 will also get these entries now. There were
    only 4 which we take:

    rts_threshold
    fragmentation_threshold
    short_retry_limit
    long_retry_limit

    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • Thanks to nl80211 userspace can be very specific upon device
    configuration. Before processing the request for the new HT40
    channel types (HT40- or HT40+) we need to ensure we can use them
    regulatory-wise. This wasn't required with wireless extensions as
    specifying the channel type wasn't not available and configuration
    was done towards the end implicitly upon association or reception
    of beacons from the AP. For the new nl80211 we have to check this
    when configuring the interfaces explicitly.

    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • This is more consistent with our nl80211 naming convention
    for HT40-/+.

    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • We are not correctly listening to the regulatory max bandwidth
    settings. To actually make use of it we need to redesign things
    a bit. This patch does the work for that. We do this to so we
    can obey to regulatory rules accordingly for use of HT40.

    We end up dealing with HT40 by having two passes for each channel.

    The first check will see if a 20 MHz channel fits into the channel's
    center freq on a given frequency range. We check for a 20 MHz
    banwidth channel as that is the maximum an individual channel
    will use, at least for now. The first pass will go ahead and
    check if the regulatory rule for that given center of frequency
    allows 40 MHz bandwidths and we use this to determine whether
    or not the channel supports HT40 or not. So to support HT40 you'll
    need at a regulatory rule that allows you to use 40 MHz channels
    but you're channel must also be enabled and support 20 MHz by itself.

    The second pass is done after we do the regulatory checks over
    an device's supported channel list. On each channel we'll check
    if the control channel and the extension both:

    o exist
    o are enabled
    o regulatory allows 40 MHz bandwidth on its frequency range

    This work allows allows us to idependently check for HT40- and
    HT40+.

    Signed-off-by: Luis R. Rodriguez
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • Its possible for cfg80211 to have scheduled the work and for
    the global workqueue to not have kicked in prior to a cfg80211
    driver's regulatory hint or wiphy_apply_custom_regulatory().

    Although this is very unlikely its possible and should fix
    this race. When this race would happen you are expected to have
    hit a null pointer dereference panic.

    Cc: stable@kernel.org
    Signed-off-by: Luis R. Rodriguez
    Tested-by: Alan Jenkins
    Signed-off-by: John W. Linville

    Luis R. Rodriguez
     
  • Another design flaw in wireless extensions (is anybody
    surprised?) in the way it handles the iw_encode_ext
    structure: The structure is part of the 'extra' memory
    but contains the key length explicitly, instead of it
    just being the length of the extra buffer - size of
    the struct and using the explicit key length only for
    the get operation (which only writes it).

    Therefore, we have this layout:

    extra: +-------------------------+
    | struct iw_encode_ext { |
    | ... |
    | u16 key_len; |
    | u8 key[0]; |
    | }; |
    +-------------------------+
    | key material |
    +-------------------------+

    Now, all drivers I checked use ext->key_len without
    checking that both key_len and the struct fit into the
    extra buffer that has been copied from userspace. This
    leads to a buffer overrun while reading that buffer,
    depending on the driver it may be possible to specify
    arbitrary key_len or it may need to be a proper length
    for the key algorithm specified.

    Thankfully, this is only exploitable by root, but root
    can actually cause a segfault or use kernel memory as
    a key (which you can even get back with siocgiwencode
    or siocgiwencodeext from the key buffer).

    Fix this by verifying that key_len fits into the buffer
    along with struct iw_encode_ext.

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

    Johannes Berg
     

20 May, 2009

1 commit

  • nlmsg_new() adds the size of the netlink header to the value
    that has been passed as parameter. If NLMSG_GOODSIZE is selected,
    we request an allocation of one memory page plus the size of the
    header. Instead, NLMSG_DEFAULT_SIZE should be used since it
    already substracts the size of the Netlink header.

    I have the impression that the similar naming in both constant
    is error prone when using it with nlmsg_new(). This is already
    documented in include/net/netlink.h

    Signed-off-by: Pablo Neira Ayuso
    Signed-off-by: David S. Miller

    Pablo Neira Ayuso
     

14 May, 2009

4 commits

  • Even though they are true, they cause sparse to complain
    because it doesn't see the __acquires(dev_base_lock) on
    dev_seq_start() because it is only added to the function
    in net/core/dev.c, not the header file. To keep track of
    the nesting correctly we should probably annotate those
    functions publically, but for now let's just remove the
    annotation I added to wext.

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

    Johannes Berg
     
  • When setting a key with NL80211_CMD_NEW_KEY, we should allow the key
    sequence number (RSC) to be set in order to allow replay protection to
    work correctly for group keys. This patch documents this use for
    nl80211 and adds the couple of missing pieces in nl80211/cfg80211 and
    mac80211 to support this. In addition, WEXT SIOCSIWENCODEEXT compat
    processing in cfg80211 is extended to handle the RSC (this was already
    specified in WEXT, but just not implemented in cfg80211/mac80211).

    Signed-off-by: Jouni Malinen
    Signed-off-by: John W. Linville

    Jouni Malinen
     
  • Add a new NL80211_ATTR_CONTROL_PORT flag for NL80211_CMD_ASSOCIATE to
    allow user space to indicate that it will control the IEEE 802.1X port
    in station mode. Previously, mac80211 was always marking the port
    authorized in station mode. This was enough when drop_unencrypted flag
    was set. However, drop_unencrypted can currently be controlled only
    with WEXT and the current nl80211 design does not allow fully secure
    configuration. Fix this by providing a mechanism for user space to
    control the IEEE 802.1X port in station mode (i.e., do the same that
    we are already doing in AP mode).

    Signed-off-by: Jouni Malinen
    Signed-off-by: John W. Linville

    Jouni Malinen
     
  • It is currently not possible to modify station flags, but that
    capability would be very useful. This patch introduces a new
    nl80211 attribute that contains a set/mask for station flags,
    and updates the internal API (and mac80211) to mirror that.

    The new attribute is parsed before falling back to the old so
    that userspace can specify both (if it can) to work on all
    kernels.

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

    Johannes Berg