On 6/9/2017 11:08 AM, Johannes Berg wrote:
Hi Arend,
Sorry about the delay.
No problem.
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 (*).
yup.
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?
Indeed. I did not state it explicitly, but that is also my understanding
so not going to do that.
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.
Not trying to change your opinion ;-). Just getting it all clear. As a
matter of fact I already have my wpa_s use the offload without any
debug/config option. As brcmfmac can use override to disable firmware
features I also do not need such in wpa_s.
(*) 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
Agree. However, in our firmware they are two modules that can be
compiled in, ie. idsup and idauth.
Regards,
Arend
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
