- 05 Oct, 2010 40 commits
-
-
Luis R. Rodriguez authored
Be consistent and use the wk->chan instead of the local->hw.conf.channel for the association done work. This prevents any possible races against channel changes while we run this work. In the case that the race did happen we would be initializing the bit rates for the new AP under the assumption of a wrong channel and in the worst case, wrong band. This could lead to trying to assuming we could use CCK frames on 5 GHz, for example. This patch has a fix for kernels >= v2.6.34 Cc: stable@kernel.org Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Johannes Berg authored
The documentation for NL80211_CMD_REMAIN_ON_CHANNEL isn't accurate, an interface index is required by the command. Update it accordingly. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Gabor Juhos authored
The base_eep_header_4k structure contains information that the device supports high power tx gain table or not. However the ath9k_hw_4k_get_eeprom function does not return that value when it is called with EEP_TXGAIN_TYPE. This leads to that the tx gain initialization will use the init values from the original tx gain table even if the device inidicates that the high power table should be used. Changes-licensed-under: ISC Signed-off-by:
Gabor Juhos <juhosg@openwrt.org> Signed-off-by:
Shu Hwa Shen <shensh@zcomm.com.cn> Signed-off-by:
-
Bruno Randolf authored
We should only wake up queues which mac80211 knows about (queues 0-3). We have another internal queue ("CAB", queue number 6) which we use for power-saved frames. When transmitted frames are processed from this queue, we have to make sure we don't bother mac80211 with waking a queue it doesn't know about. this fixes: WARNING: at /home/br1/ath/wireless-testing/net/mac80211/util.c:275 __ieee80211_wake_queue+0xd6/0xe0 [mac80211]() Signed-off-by:Bruno Randolf <br1@einfach.org> Signed-off-by:
-
Johannes Berg authored
The locking around ieee80211_recalc_smps is buggy -- it cannot acquire another interface's mutex while the iflist mutex is held because another code path could be holding the iface mutex and trying to acquire the iflist mutex. But the locking is also unnecessary, we only check "ifmgd->associated" as a bool, and don't use the pointer (in check_mgd_smps). Reported-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Johannes Berg authored
Consolidate boilerplate code needed for .dumpit calls operating on netdevs. Signed-off-by:
-
Johannes Berg authored
Use a new flag that requires the netdev to be UP and use it to check instead of coding the check into all functions that require it. Signed-off-by:
-
Johannes Berg authored
This makes nl80211 use the new genetlink pre_doit/post_doit hooks for locking and checking the interface/wiphy index. This significantly reduces the code size and the likelihood of locking errors. Signed-off-by:
-
Johannes Berg authored
Each family may have some amount of boilerplate locking code that applies to most, or even all, commands. This allows a family to handle such things in a more generic way, by allowing it to a) include private flags in each operation b) specify a pre_doit hook that is called, before an operation's doit() callback and may return an error directly, c) specify a post_doit hook that can undo locking or similar things done by pre_doit, and finally d) include two private pointers in each info struct passed between all these operations including doit(). (It's two because I'll need two in nl80211 -- can be extended.) Signed-off-by:David S. Miller <davem@davemloft.net> Signed-off-by:
-
Dan Carpenter authored
If kzalloc() fails then return should return with -ENOMEM. Signed-off-by:
Dan Carpenter <error27@gmail.com> Signed-off-by:
-
Bruno Randolf authored
Enable WME QoS in IBSS mode by adding a WME information element to beacons and probe respones and by checking for it and marking stations as WME capable if it is present. Signed-off-by:
-
Helmut Schaa authored
If a frame is not meant to be sent as AMPDU or part of it the hw might still decide to aggregate this frame if a previous frame started an AMPDU. However, this will limit the usefulness of the reported tx rate since the reported rate will be the one specified in the TXWI of the first frame and thus it is not possible to reliably caculate the number of retrys by substracting the reported tx rate from the tx rate in the TXWI. To fix this issue, only report the successful rate for frames that were not meant to be aggregated but ended up in an aggregate. Example: Frame A (MCS7, AMPDU=1) B (MCS7, AMPDU=1) C (MCS12, AMDPU=0, PROBE_RATE) Although frame C shoudn't be aggregated the hw might sill put it into an AMPDU together with A and B. If the transmission succeeds the tx status will contain MCS7 for all three frames. In that case we should only report MCS7 as success rate and avoid reporting MCS12-MCS8 as failed tx attempts as this will affect the future rate control decisions. This oddity might strike us in other scenarious as well but the most common "wrong" report happened for frames used to probe a different tx rate. This improves the rate control decisions notable. Signed-off-by:
Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by:
Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by:
-
Helmut Schaa authored
In order to lower the impact of probe rates don't send a frame as AMPDU if the rate control algorithm sets IEEE80211_TX_CTL_RATE_CTRL_PROBE. Otherwise a whole aggregate would be send with a probe rate which might lead to numerous retries. Signed-off-by:
-
Helmut Schaa authored
When rt2x00lib_enable_radio fails to enable the radio, rt2x00lib_start will call rt2x00queue_uninitialize to uninitialize the queues. Since, the queues are not initialized here but already in rt2x00lib_initialize we shouldn't uninitialize the queues here. Otherwise, a consecutive call to rt2x00lib_start will oops (see below) because it assumes the queues are already initialized. BUG: unable to handle kernel NULL pointer dereference at 00000010 IP: [<f8d2d901>] :rt2800pci:rt2800pci_clear_entry+0x1/0x40 *pde = 00000000 Oops: 0000 [#1] SMP Modules linked in: ... rt2800pci ... Pid: 5995, comm: hostapd Not tainted (2.6.27.8 #1) EIP: 0060:[<f8d2d901>] EFLAGS: 00210246 CPU: 3 EIP is at rt2800pci_clear_entry+0x1/0x40 [rt2800pci] EAX: 00000000 EBX: f698863c ECX: 00200296 EDX: f8d2dee0 ESI: f6988600 EDI: f5b6f000 EBP: 00000000 ESP: f6d75e4c DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process hostapd (pid: 5995, ti=f6d74000 task=f6ce2300 task.ti=f6d74000) Stack: f698863c fa00eaec 00000000 f5b6f000 00000000 f7b67000 f5b6e280 fa00c629 f5b6f000 00000000 fa00ca3d f7b67480 00000001 fa177d4c 01b6e890 f7b67000 00000000 f7b67000 00000001 00001003 00001002 c066c366 f7b67000 c0668ad0 Call Trace: [<fa00eaec>] rt2x00queue_init_queues+0x5c/0x90 [rt2x00lib] [<fa00c629>] rt2x00lib_enable_radio+0x29/0xa0 [rt2x00lib] [<fa00ca3d>] rt2x00lib_start+0x5d/0xd0 [rt2x00lib] [<fa177d4c>] ieee80211_do_open+0x21c/0x510 [mac80211] [<c066c366>] dev_open+0x56/0xb0 [<c0668ad0>] dev_set_rx_mode+0x20/0x40 [<c066a67f>] dev_change_flags+0x7f/0x190 [<c06b1495>] devinet_ioctl+0x515/0x690 [<c0668d24>] __dev_get_by_name+0x74/0x90 [<c065d3f0>] sock_ioctl+0xd0/0x240 [<c065d320>] sock_ioctl+0x0/0x240 [<c018179b>] vfs_ioctl+0x2b/0x90 [<c0181a5b>] do_vfs_ioctl+0x25b/0x2a0 [<c0181af6>] sys_ioctl+0x56/0x70 [<c0103262>] syscall_call+0x7/0xb [<c0700000>] add_card+0xad0/0xba0 ======================= Code: 83 78 08 0e 74 14 8b 02 8b 48 04 85 c9 0f 99 c0 0f b6 c0 c3 8d b6 00 00 00 00 8b 02 8b 40 04 85 c0 0f 99 c0 0f b6 c0 c3 66 90 53 <8b> 48 10 8b 58 08 8b 40 04 83 78 08 0e 74 15 8b 11 83 c2 04 8b EIP: [<f8d2d901>] rt2800pci_clear_entry+0x1/0x40 [rt2800pci] SS:ESP 0068:f6d75e4c ---[ end trace cff9a5c094bb8837 ]--- Reported-by:Joshua Smith <jesmith@kaon.com> Signed-off-by:
-
Helmut Schaa authored
During testing with AMPDUs it turned out that the rt2800 hw will aggregate consecutive frames with the same RA and TID when the first frame in a possible aggregate has set AMPDU=1 in the TXWI. If a following frame has set AMPDU=0 in its TXWI it might sill end up in the aggregate of the previous frame. Update the comment accordingly. Signed-off-by:
-
Helmut Schaa authored
Signed-off-by:
-
Ivo van Doorn authored
The TX_STA_FIFO contains some information for identifying a outgoing frame, however matching by WCID and ACK status is not sufficient to 100% identify the macthing queue_entry structure (containing the SKB buffer) which belongs to the status report. Within TX_STA_FIFO we have a 4-bit field named PACKETID, which is currently used to encode the queue id. The queue ID is however limited to values from 0 to 3, which means 2 bits are sufficient to encode the value. With the remaining 2 bits we can encode a partial queue_entry index number. The value of PACKETID is not allowed to become 0, with the queue ID ranging from 0 to 3, at least one of the bits for the entry identification must be 1. That leaves us with 3 possible values we can still encode in the bits. Altough this doesn't allow 100% accurate matching of the TX_STA_FIFO queue to a queue_entry structure, it at least improves the accuracy. This allows us to better detect if we have missed the TX_STA_FIFO report, which in turn reduces the number of watchdog warnings regarding the TX status timeout. Signed-off-by:
-
Helmut Schaa authored
rt61pci and rt2800 devices can use up to 7 different rates per tx frame. However, the device uses a global fallback table. Hence, the rc algortihm cannot specify multiple rates to try but the device is able to report multiple rates (based on the retry table). Specify that behavior by correctly setting max_report_rates and max_rates. This makes rt2x00 and minstrel play nicer together. Signed-off-by:
-
Helmut Schaa authored
Some drivers cannot handle multiple retry rates specified by the rc algorithm but instead use their own retry table (for example rt2800). However, if such a device registers itself with a max_rates value of 1 the rc algorithm cannot make use of the extended information the device can provide about retried rates. On the other hand, if a device registers itself with a max_rates value > 1 the rc algorithm assumes that the device can handle multi rate retries. Fix this issue by introducing another hw parameter max_report_rates that can be set to a different value then max_rates to indicate if a device is capable of reporting more rates then specified in max_rates. Signed-off-by:
-
Helmut Schaa authored
Since rt2x00 USB devices have no chance to know when a beacon was sent out in AP mode currently all broad- and multicast traffic is buffered in mac80211 but never sent out at all. Unfortunately we have no chance in sending the traffic out after a DTIM beacon due to hw limitations. Hence, instead of never sending the buffered traffic out better send it out immediately. Signed-off-by:
Lauri Hintsala <lauri.hintsala@bluegiga.com> Signed-off-by:
-
Helmut Schaa authored
Signed-off-by:
-
Helmut Schaa authored
Add the register definition CH_BUSY_STA_SEC for reading the busy time on the secondary channel in HT40 mode. Also update the comments about channel busy/idle time registers to express the used unit. Signed-off-by:
-
Ivo van Doorn authored
Signed-off-by:
-
Helmut Schaa authored
Make use of the IEEE80211_TX_RC_DUP_DATA flag to duplicate a transmission with legacy rates to both 20Mhz channels if set. Also update the related comment in rt2800.h to describe the behavior of the BW_40 flag for legacy rates. Signed-off-by:
-
Helmut Schaa authored
During rx, rt2x00lib calls rt2800pci_fill_rxdone to read the RX descriptor. At that time the skb is already dma unmapped but no new skb was dma mapped for this entry again. However, rt2800pci_fill_rxdone also moves the hw rx queue index, marking this entry to be available for reuse. Since no new skb was dma mapped and also the previous skb was unmapped this might lead to strange hw behavior. To fix this issue move the hw rx queue index increment to rt2800pci_clear_entry where a new skb was already dma mapped and can be safely used by the hw. Signed-off-by:
-
Helmut Schaa authored
Since HT protection is now configurable via mac80211 we don't need this special case for PCI devices anymore. The HT protection config will be overwritten as soon as mac80211 sends us a HT operation mode. Hence, bring the HT MM40 protection config in sync with the other HT protection registers and initialize it to no protection. Signed-off-by:
-
Helmut Schaa authored
Update the HT operation mode when mac80211 sends it to us and set the different HT protection modes and rates accordingly. For now only use CTS-to-self with OFDM 24M or CCK 11M when protection is required. Signed-off-by:
-
Helmut Schaa authored
Fix a check for dynamic SM PS mode in the STAs HT caps. Since a value of 3 means "SM PS disabled" the previous check assumed in that case that "dynamic SM PS" was enabled and as such prefixed every MCS>7 frame with a unnecessary RTS/CTS exchange. Also, the bit shift was done in the wrong direction. Signed-off-by:
-
Helmut Schaa authored
This patch changes the way tx status reports are handled by rt2800pci. Previously rt2800pci would sometimes lose tx status reports as the TX_STA_FIFO register is a fifo of 16 entries that can overflow in case we don't read it often/fast enough. Since interrupts are disabled in the device during the execution of the interrupt thread it happend sometimes under high network and CPU load that processing took too long and a few tx status reports were dropped by the hw. To fix this issue the TX_STA_FIFO register is read directly in the interrupt handler and stored in a kfifo which is large enough to hold all status reports of all used tx queues. To process the status reports a new tasklet txstatus_tasklet is used. Using the already used interrupt thread is not possible since we don't want to disable the TX_FIFO_STATUS interrupt while processing them and it is not possible to schedule the interrupt thread multiple times for execution. A tasklet instead can be scheduled multiple times which allows to leave the TX_FIFO_STATUS interrupt enabled while a previously scheduled tasklet is still executing. In short: All other interrupts are handled in the interrupt thread as before. Only the TX_FIFO_STATUS interrupt is partly handled in the interrupt handler and finished in the according tasklet. One drawback of this patch is that it duplicates some code from rt2800lib. However, that can be cleaned up in the future once the rt2800usb and rt2800pci tx status handling converge more. Using this patch on a Ralink RT3052 embedded board gives me a reliable wireless connection even under high CPU and network load. I've transferred several gigabytes without any queue lockups. Signed-off-by:
-
Helmut Schaa authored
Signed-off-by:
-
Helmut Schaa authored
rt2800 devices use parts of the pariwise key table to store the beacon frames for beacon 6 and 7. To not overwrite the beacon frame buffers limit the number of entries we store in the pairwise key table to 222. Also add some descriptive comments about this shared memory usage. Signed-off-by:
-
Christian Lamparter authored
Source: http://www.wikidevi.com/wiki/Intersil/p54/usb/windows Cc: <stable@kernel.org> Signed-off-by:
Christian Lamparter <chunkeey@googlemail.com> Signed-off-by:
-
Ben Greear authored
Includes pkts/bytes that may have had errors, and includes wireless headers when counting bytes. Signed-off-by:
-
Ben Greear authored
This adds counters for tx and rx bytes, including any errored packets as well as all wireless headers. Signed-off-by:
-
Bill Jordan authored
Initialize the rate table for WDS interfaces, and add cases to allow WDS packets to pass the xmit and receive tests. Signed-off-by:
Bill Jordan <bjordan@rajant.com> Signed-off-by:
-
Bill Jordan authored
Added a nl interface to set the peer bssid of a WDS interface. Signed-off-by:
-
Bill Jordan authored
Enable WDS for the ath9k driver. Signed-off-by:
-
Juuso Oikarinen authored
On association to an AP, after receiving beacons, the beacon_crc value is set. The beacon_crc value is not reset in disassociation, but the BSS data may be expired at a later point. When associating again, it's possible that a beacon for the AP is not received, resulting in the beacon_ies to remain NULL. After association, further beacons will not update the beacon data, as the crc value of the beacon has not changed, and the beacon_crc still holds a value matching the beacon. The beacon_ies will remain forever null. One of the results of this is that WLAN power save cannot be entered, the STA will remain foreven in active mode. Fix this by adding a validation flag for the beacon_crc, which is cleared on association. Signed-off-by:
Juuso Oikarinen <juuso.oikarinen@nokia.com> Acked-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Stanislaw Gruszka authored
Move ieee80211_scan_cancel() and all other related code to ieee80211_restart_work() as ieee80211_restart_hw() is intended to be callable from any context. Fix a bug that RTNL lock is not taken during ieee80211_cancel_scan(). Take local->mtx before WARN(test_bit(SCAN_HW_SCANNING, &local->scanning) to prevent the race condition with __ieee80211_start_scan() described here: http://marc.info/?l=linux-wireless&m=128516716810537&w=2Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Mohammed Shafi Shajakhan authored
In the ath9k debugging feature 'wiphy' the current channel used by the station is incorrectly displayed.This is because the channels available are sequentially mapped from numbers 0 to 37.This mapping cannot be changed as the channel number is also used as an array index This fix solves the above problem by calculating the channel number from center frequency. Signed-off-by:Mohammed Shafi Shajakhan <mshajakhan@atheros.com> Signed-off-by:
-
