On Mon, Jun 16, 2008 at 04:53:11PM +0200, Johannes Berg wrote: > 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? Yes, as long as the STA entry is found (and it should, in this case), the pairwise CCMP key is used both for data and management frames. I haven't done full testing yet, but I would expect this to work even when the unicast management frames comes from hostapd. Broadcast/multicast management frames are protected with BIP using IGTK. This is similar to how GTK is used with TKIP/CCMK for broadcast data frames, i.e., there is a default TX key index that the AP uses for the frames. Indexes 1..3 are used for data frames and 802.11w is using 4..5 for BIP (even though the key index space is actually completely separate from the one used with data frames). > 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? Yes, we already look for STA entry for unicast and that should work as long as the STA table is not per netdev, i.e., both data and monitor interface end using the same STA table. If no STA entry is found (multicast/broadcast), we look for a default TX key, but this is only done for the netdev that was used to send the frame (which is different between normal data interface and packet injection via monitor interface). If the monitor interface were to look for the default key (or well, keys, since there are now two; one for data, one for mgmt) from the data interface (somehow bound to the monitor iface?), that should work here. > 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"? Yes, either the frame or maybe more easily the monitor interface would need to be bound to the interface that is used for key configuration. > 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. Yes, that sounds likely since the changes I did for debugfs were very trivial copies from CCMP/data-default-key processing. I'll debug this more and try to figure if there is need to re-order something or make the debugfs entry removal able to handle such a case. -- Jouni Malinen PGP id EFC895FA -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
