Hi Arend, Sorry about the delay. > > Then you have to support NEW_KEY (AP case) and then using NEW_KEY > > to > > detect whether or not a wpa_s configuration option to not use > > offloaded > > 4-way-HS can be used will not work correctly. > > > > I don't really see that this is a sensible configuration, but I > > could > > imagine it existing if somebody "bolted on" AP functionality for a > > client-side chipset or something like that. > So I want to get back to this as to assure we have the same > understanding. First off, the proposed offloads are STA-only. Right. But we at least also want to have them for AP mode, which answers your below question. > So if a > driver supports STA and AP mode and the 4-way-HS offload, we could > already have the case you describe here. So not really a "bolted on" > scenario I would say. But if you say you don't have it in AP mode, or you didn't even think about it in AP mode yet, then I think you're right and the "bolted on" part doesn't really apply (*). However, this does mean that checking for NEW_KEY support _isn't_ sufficient to understand whether or not the device also supports doing the 4-way-HS in the host, because the device might _not_ support that in client mode, yet implement NEW_KEY for AP mode, right? In any case - I don't think this changes much my opinion. I think that newer wpa_s should always use the offload where available, and if there's a debug option to turn that off, and that debug option causes failures because the driver rejects the NEW_KEY command, rather than causing an up-front configuration failure because wpa_s knows that the NEW_KEY wouldn't be supported, then I don't think for a debug option that makes a big difference. For something that higher layers might need to set, it would make a difference - but that's not at stake here. johannes (*) my line of thinking was that if you have the necessary state machine for client in the firmware, then it's not a huge step to also have it for AP, since you have the crypto primitives for it _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
