i verified that 0 rates also create the same problem in G mode so i removed the reference to A bands.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3015 0192ed92-7a03-0410-a25b-9323aeb14dbd
We were setting this field to 0 as we had no easy way of determining
what TX power was used to transmit a frame. However, by including this
field and setting it to 0dBm we are saying that each frame is being
transmitted at 1mW, which is incorrect. Better to simply not write the
field at all, however this introduces the need for padding in the TX
header to ensure that the TX_FLAGS field is aligned to a 16-bit
boundary.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3014 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Remove comments that merely duplicate the code (i.e., they don't provide information on Why or explain the opaque)
* Rename some variable for consistency
* Line length -> 80 chars
* Reorder non-dependent code blocks in a function to make it more readable (at least to me)
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3003 0192ed92-7a03-0410-a25b-9323aeb14dbd
beacons and management frames.
this includes benoits r2993 (from dfs branch) and the patch i sent to the list
for review a couple of days ago.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3002 0192ed92-7a03-0410-a25b-9323aeb14dbd
Use t->keyix in the ic_encap argument instead of the hardcoded 0. Print
"FAIL" on failure and "PASS" on success. Take an exact copy of struct
tkip_ctx from ieee80211_crypto_tkip.c
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2990 0192ed92-7a03-0410-a25b-9323aeb14dbd
ARRAY_SIZE is present in all kernel versions we support. Use it instead
of other definitions. Define ARRAY_SIZE in the userspace tools as well.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2988 0192ed92-7a03-0410-a25b-9323aeb14dbd
ieee80211_crypto_newkey() will fail if the crypto module for the cipher
is not loaded. ieee80211_crypto_available() will try to load the module
first.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2987 0192ed92-7a03-0410-a25b-9323aeb14dbd
DIRS_MODULES is always used in the context when the Makefile is
processed directly, not from the kernel build system. Therefore, it's
equivalent to obj-y.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2986 0192ed92-7a03-0410-a25b-9323aeb14dbd
The new crypto API uses VAP, so allocate one. Use keys from
vap->iv_nw_keys with the provided key index (0 for TKIP), don't allocate
another key on the stack. Synchronize context structures with the
current code.
Return -ENXIO on failure. It's hard to find a sensible code for crypto
test failure, but -1 (-EPERM) was misleading. Fix TKIP test that was
ignoring failures.
Update module parameters for Linux 2.6. Provide makefiles to facilitate
compilation. Fix all sparse warnings.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2983 0192ed92-7a03-0410-a25b-9323aeb14dbd
Split skb and node debug flags - one ending in _ref tracks minute changes to reference counts, while the non _ref flag trackes more coarse grained debug events.
Fix a node reference leak before skb_orphan detected by the debug destructor.
Fix debug flag display order for athdebug and 80211debug so that the shorter
name comes first and matches, otherwise only the _ref flags match.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2964 0192ed92-7a03-0410-a25b-9323aeb14dbd
ath_key_alloc() was using pointer subtraction to determine the group key
index. This is not optimal, as it's done by dividing a pointer-sized
integer by a number that is generally not a power of two.
Since there are only 4 (IEEE80211_WEP_NKID) keys to try, it's easier to
try them all in a loop. It also makes the code more reliable, as it now
detects the cases when the key pointer is within the valid range, but
doesn't point to the beginning of an array element.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2954 0192ed92-7a03-0410-a25b-9323aeb14dbd
Preprocessor flag now used to toggle printk output prior to blocking on
a spinlock.
There is of course a chance that the spinlock will be taken between the time we check it and print our little message, but this should still be of some assistance troubleshoot locking mistakes that come up in the future.
If you turn on the flag, you can find out what locks are being contended for and from which functions... i.e. ath_intr fights for a particular lock, etc.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2944 0192ed92-7a03-0410-a25b-9323aeb14dbd
The architectures that don't set CONFIG_GENERIC_IOMAP are supposed to
provide replacements for functions in lib/iomap.c, but not all provide
iowrite32be() and ioread32be().
Only MIPS, PARISC and PowerPC implement iowrite32be and ioread32be as
functions, while SH and AVR32 provide macros. Other architectures, in
particular ARM, provide no replacement at all.
This should fix ticket #1539.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2932 0192ed92-7a03-0410-a25b-9323aeb14dbd
Fix inconsistent formatting of the comments. Fix the text along the
way. Run the file through madwifi-indent, but undo some overzealous
formatting.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2931 0192ed92-7a03-0410-a25b-9323aeb14dbd
