Flag for detecting 802.11r Fast BSS Transition support

Flag for detecting 802.11r Fast BSS Transition support

[Matthew Wang]

Hi,

I'm wondering if there is a flag for detecting firmware/driver support
for FT. It seems like checking for SME support is a pretty good proxy
for this, but there is a non-mac80211 driver that can do FT as well
(ath/wil6210). It would be great if anyone knows of a feature flag
specifically for FT.

Thanks,
Matthew

Re: Flag for detecting 802.11r Fast BSS Transition support

[Brian Norris]

+ Johannes

On Thu, Oct 04, 2018 at 12:06:50PM -0700, Matthew Wang wrote:
> Hi,
> 
> I'm wondering if there is a flag for detecting firmware/driver support
> for FT. It seems like checking for SME support is a pretty good proxy
> for this, but there is a non-mac80211 driver that can do FT as well
> (ath/wil6210). It would be great if anyone knows of a feature flag
> specifically for FT.

I chatted with Johannes, and he agreed that there was no such flag
today. It also sounded like he was open to adding one, even if it's
several years too late. I don't think there's any useful way people
could (generically) use FT support today.

Brian

Re: Flag for detecting 802.11r Fast BSS Transition support

[Johannes Berg]

On Wed, 2019-04-03 at 14:02 -0700, Brian Norris wrote:
> + Johannes
> 
> On Thu, Oct 04, 2018 at 12:06:50PM -0700, Matthew Wang wrote:
> > Hi,
> > 
> > I'm wondering if there is a flag for detecting firmware/driver support
> > for FT. It seems like checking for SME support is a pretty good proxy
> > for this, but there is a non-mac80211 driver that can do FT as well
> > (ath/wil6210). It would be great if anyone knows of a feature flag
> > specifically for FT.
> 
> I chatted with Johannes, and he agreed that there was no such flag
> today. It also sounded like he was open to adding one, even if it's
> several years too late. I don't think there's any useful way people
> could (generically) use FT support today.

I guess I'm not really sure if the flag is needed, but I guess like the
original question says, it'd be more about non-mac80211 drivers.

So I guess you'd have to figure out what operations the drivers need to
support then? I'm not even sure how wpa_s would handle this for SME
offload devices.

johannes

Re: Flag for detecting 802.11r Fast BSS Transition support

[Brian Norris]

+ Jouni

I forgot this was dangling:

On Mon, Apr 8, 2019 at 12:52 PM Johannes Berg <johannes@sipsolutions.net> wrote:
> So I guess you'd have to figure out what operations the drivers need to
> support then? I'm not even sure how wpa_s would handle this for SME
> offload devices.

I'm not intimately familiar with FT, but it looks like the only thing
wpa_supplicant is asking for is NL80211_CMD_UPDATE_FT_IES. I see
exactly one driver that implements this, but there's no flag for it.
Well, I guess we could just run the command and look for EOPNOTSUPP...

Jouni also claims [1] that there are plenty of out-of-tree non-SME
drivers that support FT. Android drivers may not be directly relevant
to upstream, but this topic does affect our ability to use
wpa_supplicant generically.

Brian

[1] http://lists.infradead.org/pipermail/hostap/2019-April/039951.html

Re: Flag for detecting 802.11r Fast BSS Transition support

[Marcel Holtmann]

Hi Brian,

>> So I guess you'd have to figure out what operations the drivers need to
>> support then? I'm not even sure how wpa_s would handle this for SME
>> offload devices.
> 
> I'm not intimately familiar with FT, but it looks like the only thing
> wpa_supplicant is asking for is NL80211_CMD_UPDATE_FT_IES. I see
> exactly one driver that implements this, but there's no flag for it.
> Well, I guess we could just run the command and look for EOPNOTSUPP...

this kind of API design and usage is bad. Try-and-error approach is just not sustainable. Even while it is late to add a proper flag that indicates support, we need to do this to make nl80211 better for the future.

Regards

Marcel

Re: Flag for detecting 802.11r Fast BSS Transition support

[Brian Norris]

Hi Marcel,

On Fri, Aug 16, 2019 at 11:54 AM Marcel Holtmann <marcel@holtmann.org> wrote:
> > Well, I guess we could just run the command and look for EOPNOTSUPP...
>
> this kind of API design and usage is bad. Try-and-error approach is just not sustainable.

Sure. That "suggestion" was quite literally an afterthought. Not
really a proper suggestion.

> Even while it is late to add a proper flag that indicates support, we need to do this to make nl80211 better for the future.

I suppose. I'm not quite sure how I would make use of that properly
though, given the corpus of kernels out there where the flag doesn't
exist (but the feature does). Some other heurestic for determining
kernel recency? Compile-time flags for the relevant user space, such
that one builds it for "new kernel API (w/ flag)" vs. "old kernel API"
(with the latter not even trying to look for the flag)?

Or I guess a more proactive approach: implement both a "supported" and
an "unsupported" flag, so user space can figure out a tristate: flag
not available (old kernel -- user space is left to guess) vs. command
supported flag vs. command not supported flag.

That seems a bit awkward though.

Brian

Re: Flag for detecting 802.11r Fast BSS Transition support

[Marcel Holtmann]

Hi Brian,

>>> Well, I guess we could just run the command and look for EOPNOTSUPP...
>> 
>> this kind of API design and usage is bad. Try-and-error approach is just not sustainable.
> 
> Sure. That "suggestion" was quite literally an afterthought. Not
> really a proper suggestion.
> 
>> Even while it is late to add a proper flag that indicates support, we need to do this to make nl80211 better for the future.
> 
> I suppose. I'm not quite sure how I would make use of that properly
> though, given the corpus of kernels out there where the flag doesn't
> exist (but the feature does). Some other heurestic for determining
> kernel recency? Compile-time flags for the relevant user space, such
> that one builds it for "new kernel API (w/ flag)" vs. "old kernel API"
> (with the latter not even trying to look for the flag)?
> 
> Or I guess a more proactive approach: implement both a "supported" and
> an "unsupported" flag, so user space can figure out a tristate: flag
> not available (old kernel -- user space is left to guess) vs. command
> supported flag vs. command not supported flag.
> 
> That seems a bit awkward though.

I would not make it this complicated. Add the flag for future kernels and the move on with life. Trying to workaround older versions is something I would not bother with. It is always possible to backport the feature to older kernels. And if you have a distribution or an OEM that cares, then that is what is going to happen.

Regards

Marcel

Re: Flag for detecting 802.11r Fast BSS Transition support

[Brian Norris]

On Sat, Aug 17, 2019 at 6:40 AM Marcel Holtmann <marcel@holtmann.org> wrote:
> And if you have a distribution or an OEM that cares, then that is what is going to happen.

I can see where you might not be particularly sympathetic to this
concern, but where I re-started this thread, I added in Jouni, due to
his mention of:

"There are such drivers [supporting FT] especially in number of
Android devices and I'd
rather not break those use cases.." [1]

That doesn't exactly sound like a case where he's willing to break
compatibility with older kernels in new wpa_supplicant. But maybe I
shouldn't put words in his mouth. (On the other hand, Android systems
are likely to not ever get either kernel *or* wpa_supplicant version
upgrades, so maybe it's not really a problem at all!)

Anyway, I'll just cook a patch, and then figure out whether/how I can
teach wpa_supplicant to respect it. (Or, continue forking
wpa_supplicant as we have been wont to do...)

Brian

[1] http://lists.infradead.org/pipermail/hostap/2019-April/039951.html

Re: Flag for detecting 802.11r Fast BSS Transition support

[Marcel Holtmann]

Hi Brian,

>> And if you have a distribution or an OEM that cares, then that is what is going to happen.
> 
> I can see where you might not be particularly sympathetic to this
> concern, but where I re-started this thread, I added in Jouni, due to
> his mention of:
> 
> "There are such drivers [supporting FT] especially in number of
> Android devices and I'd
> rather not break those use cases.." [1]
> 
> That doesn't exactly sound like a case where he's willing to break
> compatibility with older kernels in new wpa_supplicant. But maybe I
> shouldn't put words in his mouth. (On the other hand, Android systems
> are likely to not ever get either kernel *or* wpa_supplicant version
> upgrades, so maybe it's not really a problem at all!)
> 
> Anyway, I'll just cook a patch, and then figure out whether/how I can
> teach wpa_supplicant to respect it. (Or, continue forking
> wpa_supplicant as we have been wont to do...)

it would be beneficial for iwd and not just wpa_supplicant.

The try-and-error method is not really working for iwd since we are 100% event driven. It is important that we get told what is supported and what not before trying to connect or roam.

Regards

Marcel

Re: Flag for detecting 802.11r Fast BSS Transition support

[Johannes Berg]

On Wed, 2019-04-03 at 14:02 -0700, Brian Norris wrote:
> + Johannes
> 
> On Thu, Oct 04, 2018 at 12:06:50PM -0700, Matthew Wang wrote:
> > Hi,
> > 
> > I'm wondering if there is a flag for detecting firmware/driver support
> > for FT. It seems like checking for SME support is a pretty good proxy
> > for this, but there is a non-mac80211 driver that can do FT as well
> > (ath/wil6210). It would be great if anyone knows of a feature flag
> > specifically for FT.
> 
> I chatted with Johannes, and he agreed that there was no such flag
> today. It also sounded like he was open to adding one, even if it's
> several years too late.

Yeah, well, hindsight is 20/20. I think I've tried to do better in
reviews wrt. feature flags or some other way of discovering it, but I
guess it's never going to be perfect.

Can you submit a patch?

johannes