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
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap