提交 8dc06a1c 编写于 作者: J Johannes Berg 提交者: David S. Miller

[MAC80211]: improve key selection comment

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: NJohannes Berg <johannes@sipsolutions.net>
Acked-by: NMichael Wu <flamingice@sourmilk.net>
Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
上级 b3316157
...@@ -327,8 +327,15 @@ ieee80211_rx_h_load_key(struct ieee80211_txrx_data *rx) ...@@ -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))
......
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册