- 22 Dec, 2009 24 commits
-
-
Luis R. Rodriguez authored
IEEE-802.11n spec says the RX highest data rate field does not specify the highest supported RX data rate if its not set. Ignore it if not set then. Refer to section 7.3.56.4 Cc: johannes@sipsolutions.net Signed-off-by:
Luis R. Rodriguez <lrodriguez@atheros.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
Luis R. Rodriguez authored
When debugging you want to be lazy and not have to parse bits yourself so let mac80211 debugfs do the parsing for you. This is what I get against my WRT610N: root@tux:~# cat /sys/kernel/debug/ieee80211/phy0/stations/00\:22\:6b\:aa\:bb\:01/ht_capa ht supported cap: 0x000e HT20/HT40 SM Power Save disabled No RX STBC Max AMSDU length: 7935 bytes No DSSS/CCK HT40 ampdu factor/density: 2/6 MCS mask: ff ff 00 00 00 00 00 00 00 00 MCS rx highest: 0 MCS tx params: 0 Cc: johannes@sipsolutions.net Signed-off-by:
-
Luis R. Rodriguez authored
The MCS set is 16 bits so when debugging ensure the full 16 bits are represented. Current reading would make you think its only 8 bits. Cc: johannes@sipsolutions.net Signed-off-by:
-
Luis R. Rodriguez authored
Speaking of 802.11n rates in terms of Mbps doesn't really developers and is just useful for users. To aid debugging add the MCS index back and an HT20/HT40 mode. New screenshot: HT MCS Rate Success Retries XRetries PER 6.0: 0 0 0 0 9.0: 0 0 0 0 12.0: 26 260 0 49 18.0: 80 804 2 58 24.0: 0 0 0 0 36.0: 0 0 0 0 48.0: 0 0 0 0 54.0: 0 0 0 0 HT20 0 6.5: 1368 13660 0 48 HT20 1 13.0: 0 0 0 0 HT20 2 19.5: 0 0 0 0 HT20 3 26.0: 0 0 0 0 HT20 4 39.0: 0 0 0 0 HT20 5 52.0: 55 578 14 43 HT20 6 58.5: 29 306 8 69 HT20 7 65.0: 21 210 0 67 HT20 8 13.0: 21 210 0 56 HT20 9 26.0: 0 0 0 0 HT20 10 39.0: 0 0 0 0 HT20 11 52.0: 0 0 0 0 HT20 12 78.0: 0 0 0 0 HT20 13 104.0: 0 0 0 0 HT20 14 117.0: 0 0 0 0 HT20 15 130.0: 27 290 10 55 HT40 0 13.5: 79 687 16 17 HT40 1 27.5: 60 409 10 17 HT40 2 40.5: 56 381 21 25 HT40 3 54.0: 44 302 21 18 HT40 4 81.5: 19 171 2 14 HT40 5 108.0: 0 0 0 0 HT40 6 121.5: 0 0 0 0 HT40 7 135.0: 0 0 0 0 HT40 7 150.0: 0 0 0 0 HT40 8 27.0: 0 0 0 0 HT40 9 54.0: 0 0 0 0 HT40 10 81.0: 0 0 0 0 HT40 11 108.0: 11 100 0 18 HT40 12 162.0: 23 200 0 22 HT40 13 216.0: 61 580 0 35 HT40 14 243.0: 37 271 0 66 HT40 15 270.0: 65 217 2 73 HT40 15 300.0: 0 0 0 0 Signed-off-by: -
Jouni Malinen authored
Since mac80211_hwsim supports multiple virtual interfaces, we need to iterate through all active interfaces when figuring out whether there is a match during TX Ack status checking. This fixes TX status reporting for cases where secondary interfaces are used. Signed-off-by:
Jouni Malinen <jouni.malinen@atheros.com> Signed-off-by:
-
Johannes Berg authored
When hw rate control is used, these parameters have no meaning because the hardware cannot get at them right now, so disallow setting them. Also clean up the function a bit. Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
-
Joe Perches authored
Determine the offset at compile time. Signed-off-by:
Joe Perches <joe@perches.com> Acked-by:
Zhu Yi <yi.zhu@intel.com> Signed-off-by:
-
Holger Schurig authored
Used to be a write-only-variable :-) Signed-off-by:
Holger Schurig <holgerschurig@gmail.com> Signed-off-by:
-
Holger Schurig authored
This variable was once set to WLAN_CAPABILITY_SHORT_PREAMBLE and there's no code that could change the variable to something else. Therefore it seems this is not necessary :-) Signed-off-by:
-
Holger Schurig authored
Mostly for the embedded people that know beforehand that they don't need MESH at all and want to save some bytes, but also helpful for the upcoming cfg80211 transition. text data bss dec hex filename 114264 2308 140 116712 1c7e8 libertas.ko with mesh 105026 2000 140 107166 1a29e libertas.ko without mesh -------------------------------------------------- -9238 -308 -9546 Signed-off-by:
-
Holger Schurig authored
Signed-off-by:
-
Holger Schurig authored
Signed-off-by:
-
Holger Schurig authored
While it's might be technically true that only MESH-enabled firmwares are also RTAP-enabled, I like to have this decoupled. Signed-off-by:
-
Holger Schurig authored
Signed-off-by:
-
Holger Schurig authored
mesh_autostart_enabled was nowhere set. Rumor is that this is used in the OLPC tree, but they never did submit their code upstream. After removing this code, it turned out that the sync_channel stuff is now also unused, so get rid of that as well. Signed-off-by:
-
Holger Schurig authored
Both variables contained the same information (no mesh, old mesh, new mesh). So we can get rid of one variable. Also move the mesh-version test from cmd.c into mesh.c. Signed-off-by:
-
Johannes Berg authored
Clean out some cruft that could use an already existing sta_info struct -- that case cannot happen. Also, there's a bug there -- if allocation/insertion fails then it is possible that we are left in a lingering state where mac80211 waits for the AP, cfg80211 waits for mac80211, but the AP has already replied. Since there's no way to indicate an internal error, pretend there was a timeout, i.e. that the AP never responded. Signed-off-by:
-
Johannes Berg authored
Before commit ca9034592823e8179511e48a78731f95bfdd766c Author: Holger Schurig <hs4233@mail.mn-solutions.de> Date: Tue Oct 13 13:45:28 2009 +0200 cfg80211: remove warning in deauth case we assumed that drivers never give us spurious deauth frames because they filter them out based on the auth state they keep track of. This turned out to be racy, because userspace might deauth while the AP is also sending a deauth frame, so the warning was removed. However, in that case we should not tell userspace about the AP's frame if it requested deauth "first", where "first" means it came to cfg80211 first. Signed-off-by: -
Johannes Berg authored
In some situations it is required that a system be configured with no support for 40 MHz channels in the 2.4 GHz band. Rather than imposing any such restrictions on everybody, allow configuration a system like that with a module parameter. It is writable at runtime but only takes effect at the time of the next association. Signed-off-by:
-
Johannes Berg authored
Not that we actually ever aggregate anything, but it could potentially be useful anyhow to simulate aggregation sessions. Signed-off-by:
-
Johannes Berg authored
Enable spatial multiplexing in mac80211 by telling the driver what to do and, where necessary, sending action frames to the AP to update the requested SMPS mode. Also includes a trivial implementation for hwsim that just logs the requested mode. For now, the userspace interface is in debugfs only, and let you toggle the requested mode at any time. Signed-off-by:
-
Zhu Yi authored
When the device receives an A-MSDU frame (indicated by flag IWM_RX_TICKET_AMSDU_MSK), use ieee80211_amsdu_to_8023s to convert it to a list of 802.3 frames and handled them to upper layer. Cc: Johannes Berg <johannes@sipsolutions.net> Acked-by:
Samuel Ortiz <samuel@sortiz.org> Signed-off-by:
-
Zhu Yi authored
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 <johannes@sipsolutions.net> Signed-off-by:
-
gregor kowski authored
The mac80211 tkip code won't call update_tkip_key, if rx packets are received without KEY_FLAG_UPLOADED_TO_HARDWARE. This can happen on first packet because the hardware key stuff is called asynchronously with todo workqueue. This patch workaround that by tracking if we sent the key to the driver. Signed-off-by:
Gregor Kowski <gregor.kowski@gmail.com> Signed-off-by:
-
- 21 Dec, 2009 16 commits
-
-
Gertjan van Wingerde authored
Ensure that frames without payload are properly trimmed in rt2x00queue_insert_l2pad. This should fix the bug reported by Benoit Papillault in: http://marc.info/?l=linux-wireless&m=125974773006734&w=2Signed-off-by:
Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by:
-
Benoit Papillault authored
According to Ralink source code, the RX frame format is RXINFO + RXWI + 802.11 frame + RXD, including various padding. Before this patch, we were using RXD + RXWI + 802.11 frame, so RXD was not correct. Doing this, we fix the L2PAD bit which is now correctly set on received frames. Signed-off-by:
Benoit Papillault <benoit.papillault@free.fr> Acked-by:
Ivo van Doorn <ivdoorn@gmail.com> Acked-by:
-
Benoit PAPILLAULT authored
RX aggregation is a way to receive multiple 802.11 frames in one RX buffer. However, we don't know yet how to handle this case in rt2800usb_fill_rxdone and this has probably no impact on RX performance as well, so we disable it Signed-off-by:
-
Gertjan van Wingerde authored
L2 padding will only be present when there is actual payload present. Signed-off-by:
-
Gertjan van Wingerde authored
Simplify the rt2x00queue_insert_l2pad function by handling the alignment operations one by one. Do not special case special circumstances. Basically first perform header alignment, and then perform payload alignment (if any payload does exist). This results in a properly aligned skb. The end result is better readable code, with better results, as now L2 padding is inserted only when a payload is actually present in the frame. Signed-off-by:
-
Gertjan van Wingerde authored
With the improved L2 padding code, this flag is no longer necessary, as the rt2x00queue_remove_l2pad is capable of detecting by itself if L2 padding is applied. For received frames the RX descriptor flag is still being checked. Signed-off-by:
-
Gertjan van Wingerde authored
Fix a couple of more bugs in the L2 padding code: 1. Compute the amount of L2 padding correctly (in 3 places). 2. Trim the skb correctly when the L2 padding has been applied. Also introduce a central macro the compute the L2 padding size. Signed-off-by:
-
Alban Browaeys authored
Otherwise we end up truncating the skb before removing the l2pad thus we might have the truncated part become garbage while getting it back in remove_l2pad. For the same issue: remove the skb_trim from the rt2800 fill_rxdone (it is done after l2pad removal in rt2x00lib_rxdone). Signed-off-by:
Alban Browaeys <prahal@yahoo.com> Acked-by:
-
Alban Browaeys authored
Do not include timestamp for a frame that has been injected through a monitor interface. Signed-off-by:
-
Alban Browaeys authored
The padding is to be added between header and payload for the only header need padding case. Signed-off-by:
-
Alban Browaeys authored
platform rfkill is async thus we may try to read while the device is already off. Signed-off-by:
-
Kenichi HORIO authored
Signed-off-by:
Kenichi HORIO <moattailk1@gmail.com> Acked-by:
-
Wey-Yi Guy authored
Do not need to log error when fail the sensitivity command, driver will send sensitivity write command to uCode after each sensitivity calibration if station is associated with AP. It is a normal case when user unload the module or shutdown the system while still associated with the AP, since uCode already on the way down, it will not reply the sensitivity write request; report error in this case will give misleading information, remove the error checking here to provide a clean shutdown if no other error detected. Signed-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
Reinette Chatre <reinette.chatre@intel.com> Signed-off-by:
-
Wey-Yi Guy authored
This feature enables the on-screen uCode event log dump. The original method will append the event log to syslog; with this capability, we also enable the user to write script to capture the events which provide additional flexibility to help uCode debugging Method 1) change to debugfs directory (sys/kernel/debug/phyX/iwlagn/data) 2) #cat log_event Signed-off-by:
-
Wey-Yi Guy authored
In order to help uCode debugging, adding the capability to provide continuous uCode event logging function. uCode events is located in round-robin event queue and filled by uCode, by enable continuous event logging, driver check the write pointer and log the newly added events in iwl_bg_ucode_trace() timer function. There is still possibility of missing events if event queue being wrapped before next event dump; but with this capability, we can have much better understanding of the uCode behavior during runtime; it can help to debug the uCode related issues. Methods to enable/disable the continuous event log: step 1: enable ucode trace timer "echo 1 > /sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing" step 2: start ftrace sudo ./trace-cmd record -e iwlwifi_ucode:* sleep 1d step 3: stop ftrace sudo ./trace-cmd report trace.dat step 4: disable ucode trace timer "echo 0 > /sys/kernel/debug/ieee80211/phyX/iwlagn/debug/ucode_tracing" use "ucode_tracing" debugfs file to display number of event queue wrapped when driver attempt the continuous event logging. If event queue being wrapped more than once when driver has opportunity to log the event; it indicated there are events missing in the event log trace. This continuous event log function only available for 4965 and newer NICs. Signed-off-by: -
Wey-Yi Guy authored
When uCode HW/SW error detected, dumping important CSR (Control and Status Registers) values. Also add "csr" debugfs file to dump the current values of CSR defined in CSR table to syslog. Signed-off-by:
-
