renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-22 04:03:58 +08:00
Code

[MAC80211]: improve key selection comment

Browse Source 
When I changed the code there I forgot to mention what happens
with multicast frames in a regular BSS and keep wondering myself
if the code is correct. Add appropriate comments.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This commit is contained in:
Johannes Berg 2007-08-28 17:01:55 -04:00 committed by David S. Miller
parent b331615722
commit 8dc06a1c61
1 changed files with 7 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
net/mac80211/rx.c
View File

@ -327,8 +327,15 @@ ieee80211_rx_h_load_key(struct ieee80211_txrx_data *rx)
* frames can also use key indizes like GTKs. Hence, if we don't * frames can also use key indizes like GTKs. Hence, if we don't
* have a PTK/STK we check the key index for a WEP key. * have a PTK/STK we check the key index for a WEP key.
* *
* Note that in a regular BSS, multicast frames are sent by the
* AP only, associated stations unicast the frame to the AP first
* which then multicasts it on their behalf.
*
* There is also a slight problem in IBSS mode: GTKs are negotiated * There is also a slight problem in IBSS mode: GTKs are negotiated
* with each station, that is something we don't currently handle. * with each station, that is something we don't currently handle.
* The spec seems to expect that one negotiates the same key with
* every station but there's no such requirement; VLANs could be
* possible.
*/ */
if (!(rx->fc & IEEE80211_FCTL_PROTECTED)) if (!(rx->fc & IEEE80211_FCTL_PROTECTED))