On Mon, 2008-06-16 at 17:33 +0300, Jouni Malinen wrote: > I'm working on IEEE 802.11w support for mac80211 and my current code is > in a state that allows both unicast and multicast/broadcast management > frames to be protected (with CCMP and BIP/AES-CMAC, respectively). I'll > clean up the patches a bit and send the first version for commenting in > the near future. However, even before the patches are available, there > is one area that could benefit from comments. Neat. > hostapd is currently using a monitor interface to inject management > frames. This seems to work fine for unencrypted frames, but at least BIP > protection of broadcast/multicast management frames does not work > without some hacks.. The problem here is that the default TX key is > configured for the main data interface (wlan0) while the injected frame > is coming from the monitor interface (mon.wlan0). > ieee80211_tx_h_select_key() does not find the default key for management > frames and consequently, the frame ends up going out without BIP > processing. So just for me, BIP processing is done with the same IGTK? Unicast frames are handled by the per-station key, and as such work correctly, I'd guess? > My current workaround is to configure IGTK for both wlan0 and mon.wlan0 > in hostapd. This works, but is somewhat undesirable.. Would there be a > better way for configuring the default keys (this could apply also for > data frames, but at least for IGTK and management frames for the time > being), so that they would apply both to frames generated by MLME code > in mac80211 (if any; currently there is no broadcast/multicast > management frames used and actually, no management frames generated in > mac80211 MLME code in AP mode) and monitor interfaces (or something that > would replace them for packet injection)? Yeah that sounds like a hack. I guess it should work just like when we submit a unicast frame via monitor with the radiotap flag to indicate that we want encryption, only we should add logic to look up the default key to use if there is no peer/unicast key by the outgoing MAC address? OTOH, that would break for multi-SSID/single-BSSID scenarios I guess, so we probably need a way to indicate "this frame belongs to interface index N"? > I'm not sure whether this is a bug somewhere in my changes or whether > the configuration of default keys for monitor interfaces triggered this, > but mac80211 is now leaving behind almost empty debugfs ieee80211/phy# > directories. The only thing remaining in that directory is an empty > netdev:mon.wlan0 subdirectory, so it looks like something fails to > remove said subdirectory and then the phy# directory. I don't see any such problems, but if I were to venture a guess it's because of configuring keys on a monitor interface. It sounds like something sticks around within the netdev:mon.wlan0 subdirectory, then the code tries to delete the directory and only afterwards is the entry removed, leaving the directory (and the parent, of course) hanging there. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
