Since AP_VLAN interfaces are not pushed to the driver, the driver should not
be expected to register iftype data for them.
Map them to the regular AP iftype on lookup.
Fixes: c4cbaf7973a7 ("cfg80211: Add support for HE")
Signed-off-by: Felix Fietkau <[email protected]>
---
include/net/cfg80211.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 7c7d03aa9d06..d6fa7c8767ad 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -562,6 +562,9 @@ ieee80211_get_sband_iftype_data(const struct ieee80211_supported_band *sband,
if (WARN_ON(iftype >= NL80211_IFTYPE_MAX))
return NULL;
+ if (iftype == NL80211_IFTYPE_AP_VLAN)
+ iftype = NL80211_IFTYPE_AP;
+
for (i = 0; i < sband->n_iftype_data; i++) {
const struct ieee80211_sband_iftype_data *data =
&sband->iftype_data[i];
--
2.41.0
On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote:
> Since AP_VLAN interfaces are not pushed to the driver,
>
That's a mac80211 thing though.
> the driver should not
> be expected to register iftype data for them.
> Map them to the regular AP iftype on lookup.
And this is in cfg80211 - not sure that seems right?
OTOH I'd expect no callers with VLAN here, it doesn't really make sense
since they're not a standalone mode that actually has HE/EHT, but still,
seems odd this way?
What's actually calling it? I'm guessing somewhere in mac80211?
johannes
On 22.06.23 18:07, Johannes Berg wrote:
> On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote:
>> Since AP_VLAN interfaces are not pushed to the driver,
>>
> That's a mac80211 thing though.
>
>> the driver should not
>> be expected to register iftype data for them.
>> Map them to the regular AP iftype on lookup.
>
> And this is in cfg80211 - not sure that seems right?
>
> OTOH I'd expect no callers with VLAN here, it doesn't really make sense
> since they're not a standalone mode that actually has HE/EHT, but still,
> seems odd this way?
>
> What's actually calling it? I'm guessing somewhere in mac80211?
Yes, I guess only mac80211 is affected. I put in the cfg80211 prefix
because that's what the header file belongs to.
I made the patch in response to this:
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
I found that there are several calls to ieee80211_get_he_iftype_cap and
ieee80211_get_eht_iftype_cap, which could be affected by this issue.
I thought dealing with this in a single place would be better than playing
whac-a-mole by fixing it at the call sites.
- Felix
On Thu, 2023-06-22 at 18:25 +0200, Felix Fietkau wrote:
> On 22.06.23 18:07, Johannes Berg wrote:
> > On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote:
> > > Since AP_VLAN interfaces are not pushed to the driver,
> > >
> > That's a mac80211 thing though.
> >
> > > the driver should not
> > > be expected to register iftype data for them.
> > > Map them to the regular AP iftype on lookup.
> >
> > And this is in cfg80211 - not sure that seems right?
> >
> > OTOH I'd expect no callers with VLAN here, it doesn't really make sense
> > since they're not a standalone mode that actually has HE/EHT, but still,
> > seems odd this way?
> >
> > What's actually calling it? I'm guessing somewhere in mac80211?
>
> Yes, I guess only mac80211 is affected. I put in the cfg80211 prefix
> because that's what the header file belongs to.
>
> I made the patch in response to this:
> https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
OK, sure, that also doesn't really make sense.
> I found that there are several calls to ieee80211_get_he_iftype_cap and
> ieee80211_get_eht_iftype_cap, which could be affected by this issue.
> I thought dealing with this in a single place would be better than playing
> whac-a-mole by fixing it at the call sites.
>
I replaced almost all of them with ieee80211_get_he_iftype_cap_vif() so
it shouldn't be that bad? Looks like I forgot some though.
johannes
On 22.06.23 18:41, Johannes Berg wrote:
> On Thu, 2023-06-22 at 18:25 +0200, Felix Fietkau wrote:
>> On 22.06.23 18:07, Johannes Berg wrote:
>> > On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote:
>> > > Since AP_VLAN interfaces are not pushed to the driver,
>> > >
>> > That's a mac80211 thing though.
>> >
>> > > the driver should not
>> > > be expected to register iftype data for them.
>> > > Map them to the regular AP iftype on lookup.
>> >
>> > And this is in cfg80211 - not sure that seems right?
>> >
>> > OTOH I'd expect no callers with VLAN here, it doesn't really make sense
>> > since they're not a standalone mode that actually has HE/EHT, but still,
>> > seems odd this way?
>> >
>> > What's actually calling it? I'm guessing somewhere in mac80211?
>>
>> Yes, I guess only mac80211 is affected. I put in the cfg80211 prefix
>> because that's what the header file belongs to.
>>
>> I made the patch in response to this:
>> https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
>
> OK, sure, that also doesn't really make sense.
>
>> I found that there are several calls to ieee80211_get_he_iftype_cap and
>> ieee80211_get_eht_iftype_cap, which could be affected by this issue.
>> I thought dealing with this in a single place would be better than playing
>> whac-a-mole by fixing it at the call sites.
>>
>
> I replaced almost all of them with ieee80211_get_he_iftype_cap_vif() so
> it shouldn't be that bad? Looks like I forgot some though.
I guess one advantage in using my fix would be that it's way easier to
backport.
How about using my fix initially (with a changed prefix if you prefer),
and then replace it once the call sites have been switched over to
ieee80211_get_he_iftype_cap_vif?
- Felix
On Thu, 2023-06-22 at 18:50 +0200, Felix Fietkau wrote:
> On 22.06.23 18:41, Johannes Berg wrote:
> > On Thu, 2023-06-22 at 18:25 +0200, Felix Fietkau wrote:
> > > On 22.06.23 18:07, Johannes Berg wrote:
> > > > On Thu, 2023-06-22 at 18:05 +0200, Felix Fietkau wrote:
> > > > > Since AP_VLAN interfaces are not pushed to the driver,
> > > > >
> > > > That's a mac80211 thing though.
> > > >
> > > > > the driver should not
> > > > > be expected to register iftype data for them.
> > > > > Map them to the regular AP iftype on lookup.
> > > >
> > > > And this is in cfg80211 - not sure that seems right?
> > > >
> > > > OTOH I'd expect no callers with VLAN here, it doesn't really make sense
> > > > since they're not a standalone mode that actually has HE/EHT, but still,
> > > > seems odd this way?
> > > >
> > > > What's actually calling it? I'm guessing somewhere in mac80211?
> > >
> > > Yes, I guess only mac80211 is affected. I put in the cfg80211 prefix
> > > because that's what the header file belongs to.
> > >
> > > I made the patch in response to this:
> > > https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
> >
> > OK, sure, that also doesn't really make sense.
> >
> > > I found that there are several calls to ieee80211_get_he_iftype_cap and
> > > ieee80211_get_eht_iftype_cap, which could be affected by this issue.
> > > I thought dealing with this in a single place would be better than playing
> > > whac-a-mole by fixing it at the call sites.
> > >
> >
> > I replaced almost all of them with ieee80211_get_he_iftype_cap_vif() so
> > it shouldn't be that bad? Looks like I forgot some though.
>
> I guess one advantage in using my fix would be that it's way easier to
> backport.
> How about using my fix initially (with a changed prefix if you prefer),
> and then replace it once the call sites have been switched over to
> ieee80211_get_he_iftype_cap_vif?
>
Actually, I don't even mind the fix itself that much, I just think the
description is a bit misleading :-)
How about just describing it as something like "AP_VLAN is virtual so it
doesn't really exist as a type for capabilities; surely AP was
intended"?
I can kind of see how this might happen too, you have a STA, check the
interface, etc.
johannes