Linux 2.6.13 introduced Wireless Extension 18 with WPA support. It was
released in August 2005. People making changes to MadWifi should not be
required to be software archeologistists to test their changes.
Use CONFIG_LOCALVERSION as an alternative to check that the
configuration settings have been included.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4134 0192ed92-7a03-0410-a25b-9323aeb14dbd
Allocate all memory at once to simplify error handling. Allocate a
network device and use it both for the master and the VAP. Set a
descriptive name on the network device, as it's used in error and debug
messages.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@4122 0192ed92-7a03-0410-a25b-9323aeb14dbd
Remove kbuild by-products in regression/Makefile. Also allow
regression/tkip/test_tkip.c to compile (too few arguments to function
ieee80211_crypto_demic).
Closes: #1973
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3699 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
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
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
* Counters for total outstanding instances for each resource type (skb, ath_node and ath_buf)
* One pair of acquisition/release functions per resource type in unlocked and one in locked
* Adds some more _debug versions of functions in the call chain that acquire/release resources so that the original func/line in the driver as well as the func/line that affected the resource use can be shown in the trace. Intermediate stack frames aren't necessary to trace the leaks.
* Changes naming convention for "lock-required" functions to suffix _locked for the versions that expect locking, to be consistent with some other places in the code.
* Consolidate debug messages to the helper functions that actually affect the reference count or acquire/release a resource
* Additional sanity checks and leak detection (esp for detecting node ref leaks through skb)
* skb references are nulled out by the new sbk unref/free function.
I've tested these changes extensively and found lots of cases where we didn't get enough node references when cloning skbuff, and where the kernel drops packets due to performance issues and leaks our node references.
With these changes and the tracing enabled I have verified that:
* TX BUF: tx buffers always go down to zero when the tx queue is done, and you can watch tx queue usage ratio go up and down again as the driver is working. There are no leaks here at the moment, although there *are* some in the madwifi-dfs branch during CAC at the moment.
* skbuff leaks in all the common flows are fixed. We were leaking node references in a lot of places where kernel was dropping skb's due to congestion and we were failing to increment node references when cloning skbuffs. These are now detected, as are skbuffs that are reaped by the kernel while still holding a node reference.
* the ath_node count works correctly and on an idle system we get about 5 references per station table node, with 2 node instances per VAP. One for the bss and one for the node in the station table, I believe. The ath_node count goes up and down but always lands back at the stable number based on the vaps you have configured and the number of actual stations in the station table. The point here is that it's pretty constant what you will see over time, despite excessive node creation/release in our code during input (esp input_all). Thank god for the slab allocator.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@2902 0192ed92-7a03-0410-a25b-9323aeb14dbd
Pavel Roskin