- 10 Oct, 2007 40 commits
-
-
Holger Schurig authored
adhoc_rates_b is only used locally, so make it static Signed-off-by:
Holger Schurig <hs4233@mail.mn-solutions.de> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Holger Schurig authored
Firmware download is quite different for different hardware. The SDIO and CF cards have two flat files that need to be downloaded, whereas the USB driver needs only one file, but with an internal structure. The code that handles this (USB only) structured file is currently in fw.c. This patch moves this code into if_usb.c. The remaining functions in fw.c have not much to do with firmware, they are various card- and network-stack initialisation functions. I've moved them into main.c. Signed-off-by:
-
Dan Williams authored
Remove unused/duplicated fields and consolidate static data rate arrays, for example the libertas_supported_rates[] and datarates[] arrays in the bss_descriptor structure, and the libertas_supported_rates field in the wlan_adapter structure. Introduce libertas_fw_index_to_data_rate and libertas_data_rate_to_fw_index functions and use them everywhere firmware requires a rate index rather than a rate array. The firmware requires the 4 basic rates to have the MSB set, but most other stuff doesn't, like WEXT and mesh ioctls. Therefore, only set the MSB on basic rates when pushing rate arrays to firmware instead of doing a ton of (rate & 0x7f) everywhere. Signed-off-by:
Dan Williams <dcbw@redhat.com> Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
It's not USB specific, so move it out of the USB interface code. Signed-off-by:
-
Dan Williams authored
Mistakently introduced by a previous patch to upper-case all command constants. Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
Support for new mesh control knobs on firmware 5.220.11.p4: Signed-off-by:
Luis Carlos Cobo <luisca@cozybit.com> Signed-off-by:
-
Dan Williams authored
Remove the thread.h abstractions and opencode kthread stuff to make it clearer. Signed-off-by:
-
Dan Williams authored
Missed when fixing mixed-case structure field names. Signed-off-by:
-
Dan Williams authored
For readability. Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
Move the only function in it to if_usb.c, which was its only user anyway. Signed-off-by:
-
Luis Carlos Cobo authored
With this patch, scanning with mshX interface will only return mesh networks. To differentiate them, a specific mesh IE in beacons/probe responses is used. This IE has been introduced in firmware release 5.110.14. Note: Even though there can be at most a single mesh per channel, this scan might return several networks in the same channel. If all nodes in a mesh network are associated to an AP, they won't produce beacons/probe responses, thus the network will not be listed. This will be fixed in future firmware releases. Scan on ethX interface is not filtered, so it will list both mesh and non-mesh networks. Signed-off-by:
-
Dan Williams authored
Remove struct IE_WPA and just use direct checking of the IE bytes like ipw. Remove WLAN_802_11_VARIABLE_IEs because it's unused. Kill ieeetypes_elementid enum and just use MFIE_* from ieee80211.h. Also use struct ieee80211_info_element for scan buffer processing to simplify pointer usage. Signed-off-by:
-
Dan Williams authored
Signed-off-by:
-
Dan Williams authored
It doesn't touch hardware and therefore doesn't need endian notations either. Signed-off-by:
-
Dan Williams authored
Use standard BSS capability field constants from ieee80211.h. Signed-off-by:
-
Yoann Padioleau authored
Replacing accesses to dev->priv to netdev_priv(dev). The replacment is safe when netdev_priv is used to access a private structure that is right next to the net_device structure in memory. Cf http://groups.google.com/group/comp.os.linux.development.system/browse_thread/thread/de19321bcd94dbb8/0d74a4adcd6177bd This is the case when the net_device structure was allocated with a call to alloc_netdev or one of its derivative. Signed-off-by:
Yoann Padioleau <padator@wanadoo.fr> Cc: mcgrof@gmail.com Cc: linux-wireless@vger.kernel.org Cc: akpm@linux-foundation.org Signed-off-by:
-
Mariusz Kozlowski authored
Signed-off-by:
Mariusz Kozlowski <m.kozlowski@tuxland.pl> Acked-by:
Luis R. Rodriguez <mcgrof@gmail.com> Signed-off-by:
-
Matthias Kaehlcke authored
The Host AP driver uses a semaphore as mutex. Use the mutex API instead of the (binary) semaphore. Signed-off-by:
Matthias Kaehlcke <matthias.kaehlcke@gmail.com> Acked-by:
Satyam Sharma <satyam@infradead.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Bill Nottingham authored
Currently the modinfo looks like: description: Support for Cisco/Aironet 802.11 wireless ethernet cards. Direct support for ISA/PCI/MPI cards and support for PCMCIA when used with airo_cs. Arguably, it should be cut at the end of the first sentence. This at least makes it somewhat more legible. Signed-off-by:
Bill Nottingham <notting@redhat.com> Signed-off-by:
-
Faidon Liambotis authored
pcmcia-cs/cardmgr is deprecated and mentioning it in the help text is misleading. Signed-off-by:
Faidon Liambotis <paravoid@debian.org> Signed-off-by:
-
Faidon Liambotis authored
Reorder the Atmel options so that the menu appears saner. Before: < > Hermes chipset 802.11b support (Orinoco/Prism2/Symbol) <*> Atmel at76c50x chipset 802.11b support < > Atmel at76c506 PCI cards (NEW) < > Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards < > Atmel at76c502/at76c504 PCMCIA cards (NEW) After: < > Hermes chipset 802.11b support (Orinoco/Prism2/Symbol) <*> Atmel at76c50x chipset 802.11b support < > Atmel at76c506 PCI cards (NEW) < > Atmel at76c502/at76c504 PCMCIA cards (NEW) < > Cisco/Aironet 34X/35X/4500/4800 PCMCIA cards Signed-off-by:
-
Ulrich Kunitz authored
While in monitor mode the zd1211rw received only a limited set of packets. This patch forwards now all packets the device receives. Notify that while monitoring no FCS checks are done; so strange packets might appear in the network sniffer of your choice. ATTENTION: Support for multiple interfaces on a single ZD1211 device is currently broken. So this code works only on the first interface. Here is an example to put the device in monitor mode. iwconfig wlan0 mode monitor ifconfig wlan0 up iwconfig wlan0 channel 10 [dsd@gentoo.org: backport to mainline] Signed-off-by:
Ulrich Kunitz <kune@deine-taler.de> Signed-off-by:
Daniel Drake <dsd@gentoo.org> Signed-off-by:
-
Michael Wu authored
This patch adds a mac80211 wireless driver for ADMtek ADM8211 based wireless cards. Signed-off-by:
Michael Wu <flamingice@sourmilk.net> Signed-off-by:
-
Johannes Berg authored
There are a few TODO comments in the mac80211 sources regarding hardware offload for Michael MIC verification. Those items are, however, better handled in the driver instead of the stack, if any device requires such hand-holding. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Tomas Winkler authored
tx.mode must be set also for buffered frames. It is used in the tx hanlders Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Stephen Hemminger authored
Stats are now available for device usage inside network_device Signed-off-by:
Stephen Hemminger <shemminger@linux-foundation.org> Acked-by:
-
warmcat authored
Johannes Berg noticed that in __ieee80211_tx_prepare() we try to get the STA from addr1 of the ieee80211 header when the radiotap header is actually still at the front of the packet. This patch defers doing that until the radiotap header is gone. Signed-off-by:
Andy Green <andy@warmcat.com> Signed-off-by:
-
Volker Braun authored
Work-around for broken APs that use a non-zero key index for WEP pairwise keys. With this patch, WEP encryption only is exempt from providing a zero key index. Signed-off-by:
Volker Braun <volker.braun@physik.hu-berlin.de> Signed-off-by:
-
Johannes Berg authored
The TKIP mixing code was added for the benefit of Intel's ipw3945 chipset but that code ended up not using it. We have previously identified many problems with this code and it crystallized that library functions for mixing are likely to handle this in much more generality and might allow b43 to take advantage of hardware acceleration for TKIP. Due to these reasons, remove the TKIP mixing for hardware accelerated crypto operations. Signed-off-by:
Michael Buesch <mb@bu3sch.de> Acked-by:
-
Johannes Berg authored
This patch makes the mac80211/driver interface rely only on the IEEE80211_TXCTL_DO_NOT_ENCRYPT flag to signal to the driver whether a frame should be encrypted or not, since mac80211 internally no longer relies on HW_KEY_IDX_INVALID either this removes it, changes the key index to be a u8 in all places and makes the full range of the value available to drivers. Signed-off-by:
-
Johannes Berg authored
This patch formats some documentation in mac80211.h into kerneldoc and also adds some more explanations for hardware crypto. Signed-off-by:
-
Johannes Berg authored
No existing drivers use this callback, hence there's no telling how it might be used. In fact, it is unlikely to be of much use as-is because the default key index isn't something that the driver can do much with without knowing which interface it was for etc. And if it needs the key index for the transmitted frame, it can get it by keeping a reference to the key_conf structure and looking it up by hw_key_idx. Signed-off-by:
-
Johannes Berg authored
This patch reworks the various hardware crypto related flags to make them more local, i.e. put them with each key or each packet instead of into the hw struct. Signed-off-by:
-
Johannes Berg authored
This patch removes all mention of the atheros turbo modes that can't possibly work properly anyway since in some places we don't check for them when we should. I have no idea what the iwlwifi drivers were doing with these but it can't possibly have been correct. Cc: Zhu Yi <yi.zhu@intel.com> Signed-off-by:
-
Johannes Berg authored
During receive processing, we select the key long before using it and because there's no locking it is possible that we kfree() the key after having selected it but before using it for crypto operations. Obviously, this is bad. Secondly, during transmit processing, there are two possible races: We have a similar race between select_key() and using it for encryption, but we also have a race here between select_key() and hardware encryption (both when a key is removed.) This patch solves these issues by using RCU: when a key is to be freed, we first remove the pointer from the appropriate places (sdata->keys, sdata->default_key, sta->key) using rcu_assign_pointer() and then synchronize_rcu(). Then, we can safely kfree() the key and remove it from the hardware. There's a window here where the hardware may still be using it for decryption, but we can't work around that without having two hardware callbacks, one to disable the key for RX and one to disable it for TX; but the worst thing that will happen is that we receive a packet decrypted that we don't find a key for any more and then drop it. When we add a key, we first need to upload it to the hardware and then, using rcu_assign_pointer() again, link it into our structures. In the code using keys (TX/RX paths) we use rcu_dereference() to get the key and enclose the whole tx/rx section in a rcu_read_lock() ... rcu_read_unlock() block. Because we've uploaded the key to hardware before linking it into internal structures, we can guarantee that it is valid once get to into tx(). One possible race condition remains, however: when we have hardware acceleration enabled and the driver shuts down the queues, we end up queueing the frame. If now somebody removes the key, the key will be removed from hwaccel and then then driver will be asked to encrypt the frame with a key index that has been removed. Hence, drivers will need to be aware that the hw_key_index they are passed might not be under all circumstances. Most drivers will, however, simply ignore that condition and encrypt the frame with the selected key anyway, this only results in a frame being encrypted with a wrong key or dropped (rightfully) because the key was not valid. There isn't much we can do about it unless we want to walk the pending frame queue every time a key is removed and remove all frames that used it. This race condition, however, will most likely be solved once we add multiqueue support to mac80211 because then frames will be queued further up the stack instead of after being processed. Signed-off-by:
-
