* Formatting
* Add a function to remove SKB from ath_buf.
* Call aforementioned function early if we are accepting a frame, so that there's not chance the data can get stomped on by DMA. We should probably do this for ignored frames as well, but I got fed up trying to sort out the stack of goto.
* Remove some KASSERT for skb users, as the SKB are always copied.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3594 0192ed92-7a03-0410-a25b-9323aeb14dbd
ieee80211_input can receive cloned skb from the bridge layer, and thus makes copies to modify and use. The original was being freed immediately upon copying. The problem is that when you issue ANY response other than NETDEV_TX_OK the skb is returned to the kernel queue. So, basically there were wild pointers to skb in the skb queue, and these skb were being re-used by other applications and drivers - resulting in crashes all over the place.
With this new logic, we keep the original around until we know whether or not we will requeue it NETDEV_TX_BUSY or consume it NETDEV_TX_OK and we correctly free the skb only when appropriate.
We also get rid of the net80211_input_all function which was doing a bunch of unnecessary (and broken) copies and noe updates.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3501 0192ed92-7a03-0410-a25b-9323aeb14dbd
When CABQ transfer finishes, HAL reports the queue as inactive. Thus, if
we switch modes or change state the CABQ can be left with some ath_buf
referenced by it. The changes in this patch cause the CABQ to be checked
at DTIM even when no multicast is pending for the VAP and if "stalled"
then the queue is drained.
A subsequent patch will fix the tx tasklet logic for CABQ.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3499 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Updated register dump based on ath5k database (refresh the list)
* Added a generic debug iwpriv delegation method to if_ath
* Added some functions to help diagnose lost ath_buf pointers
[resultant fixes will be checked in subsequent commits]
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3497 0192ed92-7a03-0410-a25b-9323aeb14dbd
The convention for this function ieee80211_pwrsave is to consume the SKB and either
queue it or free it. Also switch some SKB_CB(...)->ni to SKB_NI(...)
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3491 0192ed92-7a03-0410-a25b-9323aeb14dbd
1) Move all debug preprocessor flags out into make files
2) Add support for remaining preprocessor flags to be set by ENV variables
3) Add support for HAL tracing to include device name
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3481 0192ed92-7a03-0410-a25b-9323aeb14dbd
The need to use software instead of hardware for beacon timers in AP+STA mode (aka nosbeacon) is now just determined in software, as we always knew whether or not to enable this.
The confusing bssid and -bssid parameters are now deprecated.
The "uniquebssid" flag is equivalent to "bssid" and can be used to force IEEE80211_CLONE_BSSID flag. If this is not specified, then the BSSID used will be the next unused BSSID in the sequence, which could very well be the parent device's MAC address.
"uniquebssid" equates directly to IEEE80211_CLONE_BSSID" flag therefore.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3476 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Restructure one set of control blocks into a more readable form
* Add some additional debug output
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3456 0192ed92-7a03-0410-a25b-9323aeb14dbd
This changeset adds a node statistic. If this is not liked, I encourage it to be fixed; I might learn something.
Thanks nbd.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3334 0192ed92-7a03-0410-a25b-9323aeb14dbd
So, ccmp_attach is called for each new key. Hence, only try to allocate a software context if IEEE80211_KEY_SWCRYPT is specified. Also, if we need a software context and fail, fail immediately; thus, the check in ccmp_setkey can be eleminated, as it is not actually a separate condition.
I think that when I touched this last, I was confused about the purpose of ccmp_attach.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3322 0192ed92-7a03-0410-a25b-9323aeb14dbd
time in ms, or the number of beacons for the
beacon miss alarm. If we haven't had a beacon
in this period, the alarm is sounded and
action (i.e. roaming) is taken.
This patch changes the storage of the beacon
miss threshold to integral beacon count but
corrects the previous intent.
The default beacon miss alarm is going to be
850ms which is half way between the two hard
coded limits that were there before.
The old hard coded limits assumed that the
beacon interval was 100ms and set the limit to
10 (1000ms) for software beacon miss timer
and 7 for hardware beacon miss timer.
The new default is 850ms (the midpoint between
the two previous defaults). This value is rounded
up to the next nearest beacon interval.
There is no upper bound on the beacon miss
threshold specified, since it may need to be
wildly inflated with 25ms beacon interval, or
wildly reduced with 1000ms beacon interval.
The minimum is still 2 beacons, regardless of
the beacon interval.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3314 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Based on patches from nbd
* av_beacon_alloc code has been reimplemented using atomic bit operations; I think this is safe for SMP
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3310 0192ed92-7a03-0410-a25b-9323aeb14dbd
messages from 1000 to 192 and drop the length
needed to display the [atomic] node count.
Slamming this much data on the stack can cause
stack overflows with 4k stacks quite easily,
especially when hard interrupts occur and
extend a stack that is already almost full.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3307 0192ed92-7a03-0410-a25b-9323aeb14dbd
count of the new bss node. The allocation
function gives us a reference. With this extra
reference, every invocation of reset_bss was
causing a leak of one node ~4kb every time the
interface was brought back up (or the BSS was reset
for other reasons).
This fixes ticket #1682. I can run ifconfig down/up
cycle for a long time. I'll run it overnight next
to be sure.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3301 0192ed92-7a03-0410-a25b-9323aeb14dbd
node in the node table. The node reference was
being taken in any path where the wds node was found
and not just when the wds node was first added.
This would have caused wds nodes to get inflated
reference counts, and be leaked on bss reset when
nodes were flushed from the node tables.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3300 0192ed92-7a03-0410-a25b-9323aeb14dbd
copy of the bss node is used to send a message
we need to make sure all code paths release
it when done. This bug combined with repeated
auth failures would cause node references to
grow with every failure. Then, if you were
taking down the interface and bringing it back
up you would leak one page (4kb) every time the
the node table was flushed on transition to UP.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3299 0192ed92-7a03-0410-a25b-9323aeb14dbd
This changes some iwpriv names, because I believe they will be more readily usable and understandable
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3279 0192ed92-7a03-0410-a25b-9323aeb14dbd
symbol names to their corresponding HAL function names (ah.h)
- Add a script to generate a SED script from the current HAL (ah.h)
that will replace instances of obfuscated names with the correct names.
- Add the SED script for cleaning up text containing obfuscated function names for the current HAL
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3244 0192ed92-7a03-0410-a25b-9323aeb14dbd
avoid hitting the size limitations of wireless extensions. wext is a real pain.
Now the values are stored in ic_chan_non_occupy[] instead.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3207 0192ed92-7a03-0410-a25b-9323aeb14dbd
* Lots of coding style and formatting, tedious and annoying
* Quite a few bad merges as far as I can tell; at least one of which was serious - reintroduced a leak
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3202 0192ed92-7a03-0410-a25b-9323aeb14dbd
The symptom would be fragments of 802.11 header showing up in the ethernet header because of skb header offsets being corrupted by MadWifi devices on lower ports which then get forwarded as-is to wired ports.
Sorry for the lame explanation, but the short end of the story is that you have to copy the skb before you modify it if you are going to play nice with bridging.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3146 0192ed92-7a03-0410-a25b-9323aeb14dbd
I've fixed the logic so that multicast is dropped, with an error when disabled. I don't think this is a valid configuration. Also, we don't skip the filtering logic so that our own multicast traffic doesn't come back to us (looking like a bridging loop).
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3132 0192ed92-7a03-0410-a25b-9323aeb14dbd
hard_start_xmit() functions must either return NETDEV_TX_OK or
NETDEV_TX_BUSY (they might also return negative errno values as well,
like -ENETDOWN)
Correct a small missing static reported by sparse
This revert part of r3075
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3123 0192ed92-7a03-0410-a25b-9323aeb14dbd
