in "11.1.2.2 Beacon generation in an IBSS" the IEEE802.11 standard says, each
STA should...
"b) Calculate a random delay uniformly distributed in the range between zero
and twice aCWmin × aSlotTime,"
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3232 0192ed92-7a03-0410-a25b-9323aeb14dbd
Dollar signs should be written as two dollar signs to be interpreted by
the shell rather than by the make.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3225 0192ed92-7a03-0410-a25b-9323aeb14dbd
Signed-off-by: Russell Harmon <eatnumber1@gmail.com>
Switch from `` to POSIX preferred (and more readable) $()
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3224 0192ed92-7a03-0410-a25b-9323aeb14dbd
Since r3076 ath_tx_capture no longer exists, and ath_capture no longer frees the SKB because it was a confusing place to do that. The reverted changeset has been tested to cause leaks, and once reverted the code operates correctly.i
*fwap*
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3222 0192ed92-7a03-0410-a25b-9323aeb14dbd
ath_tx_capture, for each frame in the list we have already freed the skb but the original pointer to
the list of skbs is still in bf->bf_skb. So when bf is returned with ath_return_txbuf it tries to
double-free, resuilting a spew of backtraces/warnings when reference debugging is enabled.
Not to mention the fact that the skb is double-freed.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3220 0192ed92-7a03-0410-a25b-9323aeb14dbd
whether or not beacons were going to be reconfigured. Add logic so that
any time a STA on an AP mode radio comes back to RUN state we will
reconfigure beacons. Also reconfigure beacons on AP return to RUN state
in a AP+STA configuration. In this AP+STA mode, we need to be careful to update the beacons any time a STA or AP comes online to make sure the APs start beaconing. This fixes issues where beacons are not restarted correctly after the station returns from SCAN/ASSOC/AUTH/INIT to RUN state while APs are pending completation of the STAs activity.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3213 0192ed92-7a03-0410-a25b-9323aeb14dbd
On requeue, stop the kernel queue and flag the fact that we stopped it in sc_dev_stopped so that it can be restarted automatically when resources become available. This is already done in the case of taking a txbuf, but can/should be done for every code path leading to requeuing.
git-svn-id: http://madwifi-project.org/svn/madwifi/trunk@3208 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
