- 15 Sep, 2008 40 commits
-
-
Abhijeet Kolekar authored
When monitor mode is changed to BSS or IBSS, data trasnfer can not happen because proper transmit function is not assigend for BSS ,IBSS mode. This patch fixes this problem by assigning the ieee80211_subif_start_xmit to device's hard_start_xmit function. Signed-off-by: Abhijeet Kolekar <abhijeet.kolekar@intel.com> Acked-by: Zhu Yi <yi.zhu@intel.com> Acked-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
You can just pull up a monitor interface to get much more detailed information, or, when debugging a driver, insert dump code into the driver (which usually you will have to do anyway to dump the driver-specific information). Hence this option is useless. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The beacon counters mac80211 keeps are only used for debugfs, unfortunately, they are incorrect for many hardware designs, namely any design that has a beacon template. Hence, remove the counters so we don't create the impression they are usable. This also allows removing the beacon MESH #ifdef again. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
A few errors sneaked in over time, some functions no longer exist, for some alternatives exist. This changes the docbook template to include the right things. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Sorry, forgot to run kernel-doc and just got the output from the nightly run by email, this fixes a warning which I introduced when doing the first RC API cleanups. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This paves the way for dynamic radio additions while the module is loaded. Also restrict the number of radios to 100 because creating that many already takes forever. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Currently, virtual interface pointers passed to drivers might be from monitor interfaces and as such completely uninitialised because we do not tell the driver about monitor interfaces when those are created. Instead of passing them, we should therefore indicate to the driver that there is no information; do that by passing a NULL value and adjust drivers to cope with it. As a result, some mac80211 API functions also need to cope with a NULL vif pointer so drivers can still call them unconditionally. Also, when injecting frames we really don't want to pass NULL all the time, if we know we are the source address of a frame and have a local interface for that address, we can to use that interface. This also helps with processing the frame correctly for that interface which will help the 802.11w implementation. It's not entirely correct for VLANs or WDS interfaces because there the MAC address isn't unique, but it's already a lot better than what we do now. Finally, when injecting without a matching local interface, don't assign sequence numbers at all. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Javier Cardona authored
WPA requires that the PTK is installed immediately after the 4-way handshake in order to properly decrypt the subsequent incoming EAPOL-GTK frame. If the PTK is not enabled by the time the EAPOL-GTK frame arrives, the frame is dropped and the supplicant does not receive the group key. This will happen with fast Access Points that send the EAPOL-GTK frame before the suplicant has successfully installed and enabled the PTK. To mitigate this situation, this patch simplifies and accelerates the SIOCSIWENCODEEXT execution. This patch resolves OLPC ticket 7825 (http://dev.laptop.org/ticket/7825) Signed-off-by: Javier Cardona <javier@cozybit.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Henrique de Moraes Holschuh authored
Currently, rfkill would stand in the way of properly supporting wireless devices that are capable of waking the system up from sleep or hibernation when they receive a special wireless message. It would also get in the way of mesh devices that need to remain operational even during platform suspend. To avoid that, stop trying to block the transmitters on the rfkill class suspend handler. Drivers that need rfkill's older behaviour will have to implement it by themselves in their own suspend handling. Do note that rfkill *will* attempt to restore the transmitter state on resume in any situation. This happens after the driver's resume method is called by the suspend core (class devices resume after the devices they are attached to have been resumed). The following drivers need to check if they need to explicitly block their transmitters in their own suspend handlers (maintainers Cc'd): arch/arm/mach-pxa/tosa-bt.c drivers/net/usb/hso.c drivers/net/wireless/rt2x00/* (USB might need it?) drivers/net/wireless/b43/ (SSB over USB might need it?) drivers/misc/hp-wmi.c eeepc-laptop w/rfkill support (not in mainline yet) Compal laptop w/rfkill support (not in mainline yet) toshiba-acpi w/rfkill support (not in mainline yet) Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> Cc: Ivo van Doorn <IvDoorn@gmail.com> Cc: Matthew Garrett <mjg@redhat.com> Cc: Andrew Bird <ajb@spheresystems.co.uk> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Cezary Jackiewicz <cezary.jackiewicz@gmail.com> Cc: Philip Langdale <philipl@overt.org> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Lorenzo Nava authored
This fixes the initialization of QoS parameters. Reported-by: Lorenzo Nava, Francesco Gringoli Signed-off-by: Francesco Gringoli <francesco.gringoli@ing.unibs.it> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Zhu Yi authored
This patch adds MODULE_FIRMWARE statement for 3945 HW. Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch adds MODULE_FIRMWARE statement for 5000 HW. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Tomas Winkler authored
This patch updates PCI IDs for 5350 Wifi/WiMax. Signed-off-by: Tomas Winkler <tomas.winkler@intel.com> Signed-off-by: Zhu Yi <yi.zhu@intel.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
We cannot pass a VLAN vif pointer to the driver since those are entirely virtual and we never tell the driver. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
There really is no need, at worst ieee80211_start_tx_ba_session will log a message when debugging is enabled, and poking such internals of mac80211 definitely doesn't belong into an RC algorithm. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Rate control algorithms may need access to a station's HT capabilities, so share the ht_info struct in the public station API. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The sta_info->txrate_idx member isn't used by all RC algorithms in the way it was intended to be used, move it into those that require it (only PID) and keep track in the core code of which rate was last used for reporting to userspace and the mesh MLME. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
As more preparation for a saner rate control algorithm API, share the supported rates bitmap in the public API. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This variable in sta_info is only used in a meaningful way by the Intel RC algorithms, so move it into those. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This patch fixes mac80211 to not rely on the rate control algorithm to update sta->tx_retry_failed and sta->tx_retry_count (even if we don't currently use them), removes a number of completely unused values we don't even show in debugfs and changes the code in ieee80211_tx_status() to not look up the sta_info repeatedly. The only behaviour change here would be not calling the rate control function rate_control_tx_status() when no sta_info is found, but all rate control algorithms ignore such calls anyway. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
In analogy with the previous patch to make mac80211-hwsim verify that the virtual interface pointers are correct, this makes it very that it knows about all station structs. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This patch changes mac80211 to share some more data about stations with drivers. Should help iwlwifi and ath9k when they get around to updating, and might also help with implementing rate control algorithms without internals. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Cc: Sujith Manoharan <Sujith.Manoharan@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
mac80211-hwsim is a debugging tool for mac80211, and as such it can very well verify that mac80211 isn't passing junk to drivers, especially the vif pointer is prone to this because for vlan interfaces the AP interface pointer needs to be passed. This makes mac80211-hwsim add a magic cookie to the private vif area and verify it whenever an operation is called that gets a vif pointer. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
These should never happen, but better warn about them than crashing a driver, the fact that they never happen is rather subtle throughout mac80211. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Move the code to handle regular interfaces out of main.c and into iface.c, keep only the master interface stuff in main.c. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
There's really no reason for mac80211 to be using its own interface type defines. Use the nl80211 types and simplify the configuration code a bit: there's no need to translate them any more now. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Drivers need to know the basic rateset to be able to configure the ACK/CTS programming in hardware correctly. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Some comments refer to 80211.o or similar; also remove a comment about implementing fragments better, we really have better things to do. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
Most of the scan functions are called ieee80211_sta_scan_* or similar, make clean it up so they are all just called ieee80211_scan_*. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The bridge_packets configuration really should be per virtual interface (theoretically per AP/VLAN, but this is much easier); there currently is no way to set it yet though. Also invert the option to "NO_BRIDGE_PACKETS" so the default is to bridge. While at it, also document the flags properly. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
It really doesn't belong into the wireless extensions code. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This way all the utility functions are at the top, then the state machine and externally callable functions are moved to the bottom. Also clean up ieee80211_i.h a bit and add a few comments about which functions are called from where. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When we remove an interface, we can currently end up having a pointer to it left in local->scan_sdata after it has been set down, and then with a hardware scan the scan completion can try to access it which is a bug. Alternatively, a scan that started as a hardware scan may terminate as though it was a software scan, if the timing is just right. On SMP systems, software scan also has a similar problem, just canceling the delayed work and setting a flag isn't enough since it may be running concurrently; in this case we would also never restore state of other interfaces. This patch hopefully fixes the problems by always invoking ieee80211_scan_completed or requiring it to be invoked by the driver, I suspect the drivers that have ->hw_scan() are buggy. The bug will not manifest itself unless you remove the interface while hw-scanning which will also turn off the hw, and then add a new interface which will be unusable until you scan once. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
When we stop an interface, the work on it may still be pending or running. We do cancel the timer, but we do not currently protect against the work struct. The race is very unlikely to hit -- it'll happen only when the driver is using mac80211's workqueue to run long-running tasks and the sta/mesh works are delayed for quite a bit. This patch fixes it by cancelling the work explicitly. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This patch splits off mesh handling from the STA/IBSS. Unfortunately it increases mesh code size a bit, but I think it makes things clearer. The patch also reduces per-interface run-time memory usage. Also clean up a few places where ifdef is not required. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The timer restart is done wrongly, we shouldn't set the REQ_RUN bit when the scan has finished if it hadn't been set before the scan started. If the timer fires during the scan, it will set REQ_RUN and then we can run the work for it, if it didn't fire then we shouldn't run its work either. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
This I shouldn't have moved to the scan implementation, move it back to the MLME where it belongs, to the notification. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
ieee80211_sta_expire uses the internal __sta_info_unlink function which can become static if this function is moved to sta_info.c. Signed-off-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Dan Williams authored
And support setting both long and short retries independently. Signed-off-by: Dan Williams <dcbw@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-
Vasanthakumar Thiagarajan authored
RF kill support is enabled when CONFIG_RFKILL is set. Signed-off-by: Vasanthakumar Thiagarajan <vasanth@atheros.com> Signed-off-by: John W. Linville <linville@tuxdriver.com>
-