[PATCH V2 0/9] nl80211: add support for PTK/GTK handshake offload
Arend van Spriel
arend.vanspriel at broadcom.com
Mon May 22 03:14:26 PDT 2017
On 5/19/2017 12:21 PM, Johannes Berg wrote:
> On Thu, 2017-05-18 at 14:48 +0200, Arend Van Spriel wrote:
>
>> True. However, we touched this topic a while ago in generic context,
>> ie. preference for ext_features over supported_commands. Right now
>> wpa_supplicant does not check NEW_KEY support so we can go either
>> way.
>
> Right. That's a separate discussion though - whether we add two flags
> here or check NEW_KEY support doesn't really matter, except that we
> need to decide
>
> * if we want to support such an override at all, and
> * if it should be tested at all
> (perhaps we can just live with that failing entirely?)
>
>> I have cleaned up the wpa_supplicant patches for the offloads, but
>> waited with submitting them until the kernel side got applied. So
>> depending on what is decided here I can rework it.
>
> I don't really know. I personally don't think that we need to allow
> both ways, but then I'm coming with a driver that doesn't even support
> the old way.
Ok. I know for sure that I have firmware in linux-firmware that supports
the offload. So for people using that out there things will change from
one way to the other when they change to a newer wpa_supplicant.
> So you should probably decide yourself if you want to keep this
> fallback option, and how well it should work (be rejected if used on a
> driver that doesn't support it, or just fail later?)
There is a (small) chance of regression with older devices as stated
above and I would like to keep the fallback option for that. Also people
may like to have a choice. I am not so sure about whether NEW_KEY
support is enough or a new ext_feature flag is needed. I am inclined to
say the NEW_KEY support is sufficient.
Regards,
Arend
More information about the Hostap
mailing list