Go back –> ath5k kerneldoc
If you see nothing its because there is no kdoc yet for this file.
ath5k_hw_write_ofdm_timings - set OFDM timings on AR5212
int ath5k_hw_write_ofdm_timings (struct ath5k_hw * ah, struct ieee80211_channel * channel)Arguments
- ah
- the struct ath5k_hw
- channel
- the currently set channel upon reset
Description
Write the OFDM timings for the AR5212 upon reset. This is a helper for ath5k_hw_reset. This seems to tune the PLL a specified frequency depending on the bandwidth of the channel.
ath5k_hw_write_rate_duration - set rate duration during hw resets
void ath5k_hw_write_rate_duration (struct ath5k_hw * ah, unsigned int mode)Arguments
- ah
- the struct ath5k_hw
- mode
- one of enum ath5k_driver_mode
Description
Write the rate duration table for the current mode upon hw reset. This is a helper for ath5k_hw_reset. It seems all this is doing is setting an ACK timeout for the hardware for the current mode for each rate. The rates which are capable of short preamble (802.11b rates 2Mbps, 5.5Mbps, and 11Mbps) have another register for the short preamble ACK timeout calculation.
ath5k_hw_set_bssid_mask - set common bits we should listen to
int ath5k_hw_set_bssid_mask (struct ath5k_hw * ah, const u8 * mask)Arguments
- ah
- the struct ath5k_hw
- mask
- the bssid_mask, a u8 array of size ETH_ALEN
Description
Note that this is a simple filter and *does* not filter out all relevant frames. Some non-relevant frames will get through, probability jocks are welcomed to compute.When handling multiple BSSes (or VAPs) you can get the BSSID mask by
Description
Note that this is a simple filter and *does* not filter out all relevant frames. Some non-relevant frames will get through, probability jocks are welcomed to compute.When handling multiple BSSes (or VAPs) you can get the BSSID mask by
computing the set of
~ ( MAC XOR BSSID )
When you do this you are essentially computing the common bits. Later it is assumed the harware will "and" (&) the BSSID mask with the MAC address to obtain the relevant bits which should match on the destination frame.
Simple example
on your card you have have two BSSes you have created with BSSID-01 and BSSID-02. Lets assume BSSID-01 will not use the MAC address. There is another BSSID-03 but you are not part of it. For simplicity's sake,
assuming only 4 bits for a mac address and for BSSIDs you can then have
\
MAC
0001 | BSSID-01: 0100 | --> Belongs to us BSSID-02: 1001 | / ------------------- BSSID-03: 0110 | --> External -------------------
Our bssid_mask would then be
On loop iteration for BSSID-01: ~(0001 ^ 0100) -> ~(0101) -> 1010 bssid_mask = 1010
On loop iteration for BSSID-02: bssid_mask &= ~(0001 ^ 1001) bssid_mask = (1010) & ~(0001 ^ 1001) bssid_mask = (1010) & ~(1001) bssid_mask = (1010) & (0110) bssid_mask = 0010
A bssid_mask of 0010 means "only pay attention to the second least significant bit". This is because its the only bit common amongst the MAC and all BSSIDs we support. To findout what the real common bit is we can simply "&" the bssid_mask now with any BSSID we have or our MAC address (we assume the hardware uses the MAC address).
Now, suppose there's an incoming frame for BSSID-03:
IFRAME-01: 0110
An easy eye-inspeciton of this already should tell you that this frame will not pass our check. This is beacuse the bssid_mask tells the hardware to only look at the second least significant bit and the common bit amongst the MAC and BSSIDs is 0, this frame has the 2nd LSB as 1, which does not match 0.
the hardware will do
allow = (IFRAME-01 & bssid_mask) == (bssid_mask & MAC) ? 1 : 0; --> allow = (0110 & 0010) == (0010 & 0001) ? 1 : 0; --> allow = (0010) == 0000 ? 1 : 0; --> allow = 0
Lets now test a frame that should work
IFRAME-02: 0001 (we should allow)
allow = (0001 & 1010) == 1010
allow = (IFRAME-02 & bssid_mask) == (bssid_mask & MAC) ? 1 : 0; --> allow = (0001 & 0010) == (0010 & 0001) ? 1 :0; --> allow = (0010) == (0010) --> allow = 1
Other examples
IFRAME-03: 0100 --> allowed IFRAME-04: 1001 --> allowed IFRAME-05: 1101 --> allowed but its not for us!!!