Linux-Wireless Archive on lore.kernel.org
 help / color / Atom feed
* Flag for detecting 802.11r Fast BSS Transition support
@ 2018-10-04 19:06 Matthew Wang
  2019-04-03 21:02 ` Brian Norris
  0 siblings, 1 reply; 7+ messages in thread
From: Matthew Wang @ 2018-10-04 19:06 UTC (permalink / raw)
  To: linux-wireless; +Cc: Brian Norris, Kirtika Ruchandani

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Flag for detecting 802.11r Fast BSS Transition support
  2018-10-04 19:06 Flag for detecting 802.11r Fast BSS Transition support Matthew Wang
@ 2019-04-03 21:02 ` Brian Norris
  2019-04-08 19:52   ` Johannes Berg
  0 siblings, 1 reply; 7+ messages in thread
From: Brian Norris @ 2019-04-03 21:02 UTC (permalink / raw)
  To: Matthew Wang; +Cc: linux-wireless, Kirtika Ruchandani, Johannes Berg

+ 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Flag for detecting 802.11r Fast BSS Transition support
  2019-04-03 21:02 ` Brian Norris
@ 2019-04-08 19:52   ` Johannes Berg
  2019-08-08 17:15     ` Brian Norris
  0 siblings, 1 reply; 7+ messages in thread
From: Johannes Berg @ 2019-04-08 19:52 UTC (permalink / raw)
  To: Brian Norris, Matthew Wang; +Cc: linux-wireless, Kirtika Ruchandani

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Flag for detecting 802.11r Fast BSS Transition support
  2019-04-08 19:52   ` Johannes Berg
@ 2019-08-08 17:15     ` Brian Norris
  2019-08-16 18:54       ` Marcel Holtmann
  0 siblings, 1 reply; 7+ messages in thread
From: Brian Norris @ 2019-08-08 17:15 UTC (permalink / raw)
  To: Johannes Berg; +Cc: Matthew Wang, linux-wireless, Kirtika Ruchandani, j

+ 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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Flag for detecting 802.11r Fast BSS Transition support
  2019-08-08 17:15     ` Brian Norris
@ 2019-08-16 18:54       ` Marcel Holtmann
  2019-08-16 20:29         ` Brian Norris
  0 siblings, 1 reply; 7+ messages in thread
From: Marcel Holtmann @ 2019-08-16 18:54 UTC (permalink / raw)
  To: Brian Norris
  Cc: Johannes Berg, Matthew Wang, linux-wireless, Kirtika Ruchandani, j

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Flag for detecting 802.11r Fast BSS Transition support
  2019-08-16 18:54       ` Marcel Holtmann
@ 2019-08-16 20:29         ` Brian Norris
  2019-08-17 13:40           ` Marcel Holtmann
  0 siblings, 1 reply; 7+ messages in thread
From: Brian Norris @ 2019-08-16 20:29 UTC (permalink / raw)
  To: Marcel Holtmann
  Cc: Johannes Berg, Matthew Wang, linux-wireless, Kirtika Ruchandani,
	Jouni Malinen

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: Flag for detecting 802.11r Fast BSS Transition support
  2019-08-16 20:29         ` Brian Norris
@ 2019-08-17 13:40           ` Marcel Holtmann
  0 siblings, 0 replies; 7+ messages in thread
From: Marcel Holtmann @ 2019-08-17 13:40 UTC (permalink / raw)
  To: Brian Norris
  Cc: Johannes Berg, Matthew Wang, linux-wireless, Kirtika Ruchandani,
	Jouni Malinen

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


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, back to index

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-04 19:06 Flag for detecting 802.11r Fast BSS Transition support Matthew Wang
2019-04-03 21:02 ` Brian Norris
2019-04-08 19:52   ` Johannes Berg
2019-08-08 17:15     ` Brian Norris
2019-08-16 18:54       ` Marcel Holtmann
2019-08-16 20:29         ` Brian Norris
2019-08-17 13:40           ` Marcel Holtmann

Linux-Wireless Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-wireless/0 linux-wireless/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-wireless linux-wireless/ https://lore.kernel.org/linux-wireless \
		linux-wireless@vger.kernel.org linux-wireless@archiver.kernel.org
	public-inbox-index linux-wireless


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-wireless


AGPL code for this site: git clone https://public-inbox.org/ public-inbox