> 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. Yeah, it should. > 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). Ok, thanks for the explanation. > > 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). Good point about the STA tables there. I guess we really do need to bind the frame to a certain outgoing device to use that sdata state struct. > 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. Yeah, either would work, for per-frame we'd have to extend radiotap but it would probably be better as it would allow hostapd to use the same mon.wlan0 interface for all BSSes. > > 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. Ok. I don't know right now, and it does seem to work correctly here, but maybe it doesn't when the application doesn't explicitly remove the key or something, I'll take a look. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
