[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