| Message ID | 1557307533-5795-1-git-send-email-mpubbise@codeaurora.org (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Johannes Berg |
| Headers | show |
| Series | [v3] {nl,mac}80211: allow 4addr AP operation on crypto controlled devices | expand |
On Wed, 2019-05-08 at 14:55 +0530, Manikanta Pubbisetty wrote: > > +++ b/net/mac80211/util.c > @@ -3795,7 +3795,9 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata, > } > > /* Always allow software iftypes */ > - if (local->hw.wiphy->software_iftypes & BIT(iftype)) { > + if (local->hw.wiphy->software_iftypes & BIT(iftype) || > + (iftype == NL80211_IFTYPE_AP_VLAN && > + local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) { > if (radar_detect) > return -EINVAL; Shouldn't this check if 4addr is actually enabled too, like here: > case NETDEV_PRE_UP: > - if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype))) > + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) && > + !(wdev->iftype == NL80211_IFTYPE_AP_VLAN && > + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP && > + wdev->use_4addr)) > return notifier_from_errno(-EOPNOTSUPP); ? Or is there some reason it doesn't matter? > @@ -3439,6 +3438,11 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info) > return err; > } > > + if (!(rdev->wiphy.interface_modes & (1 << type)) && > + !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr && > + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP)) > + return -EOPNOTSUPP; > + I also wonder if we shouldn't go "all in" and actually make the check something like check_interface_allowed(iftype, 4addr): if (iftype == AP_VLAN && 4addr) return wiphy.flags & WIPHY_FLAG_4ADDR_AP; else return wiphy.interface_modes & BIT(iftype); i.e. make it "you must have WIPHY_FLAG_4ADDR_AP to use 4-addr AP_VLAN interfaces", rather than "also allow it in this case". That would seem like the clearer semantics to me? johannes
On 5/14/2019 2:08 PM, Johannes Berg wrote: > On Wed, 2019-05-08 at 14:55 +0530, Manikanta Pubbisetty wrote: >> +++ b/net/mac80211/util.c >> @@ -3795,7 +3795,9 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata, >> } >> >> /* Always allow software iftypes */ >> - if (local->hw.wiphy->software_iftypes & BIT(iftype)) { >> + if (local->hw.wiphy->software_iftypes & BIT(iftype) || >> + (iftype == NL80211_IFTYPE_AP_VLAN && >> + local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) { >> if (radar_detect) >> return -EINVAL; > Shouldn't this check if 4addr is actually enabled too, like here: Sure Johannes, I'll look into it. >> case NETDEV_PRE_UP: >> - if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype))) >> + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) && >> + !(wdev->iftype == NL80211_IFTYPE_AP_VLAN && >> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP && >> + wdev->use_4addr)) >> return notifier_from_errno(-EOPNOTSUPP); > ? > Or is there some reason it doesn't matter? > >> @@ -3439,6 +3438,11 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info) >> return err; >> } >> >> + if (!(rdev->wiphy.interface_modes & (1 << type)) && >> + !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr && >> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP)) >> + return -EOPNOTSUPP; >> + > I also wonder if we shouldn't go "all in" and actually make the check > something like > > check_interface_allowed(iftype, 4addr): > if (iftype == AP_VLAN && 4addr) > return wiphy.flags & WIPHY_FLAG_4ADDR_AP; > > else return wiphy.interface_modes & BIT(iftype); > > i.e. make it "you must have WIPHY_FLAG_4ADDR_AP to use 4-addr AP_VLAN > interfaces", rather than "also allow it in this case". > > That would seem like the clearer semantics to me? Yeah, it can be better; I'll check if this is feasible. Thanks, Manikanta
On 31/05/2019, Manikanta Pubbisetty <mpubbise@codeaurora.org> wrote: > > On 5/14/2019 2:08 PM, Johannes Berg wrote: >> On Wed, 2019-05-08 at 14:55 +0530, Manikanta Pubbisetty wrote: >>> +++ b/net/mac80211/util.c >>> @@ -3795,7 +3795,9 @@ int ieee80211_check_combinations(struct >>> ieee80211_sub_if_data *sdata, >>> } >>> >>> /* Always allow software iftypes */ >>> - if (local->hw.wiphy->software_iftypes & BIT(iftype)) { >>> + if (local->hw.wiphy->software_iftypes & BIT(iftype) || >>> + (iftype == NL80211_IFTYPE_AP_VLAN && >>> + local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) { >>> if (radar_detect) >>> return -EINVAL; >> Shouldn't this check if 4addr is actually enabled too, like here: > > > Sure Johannes, I'll look into it. > > >>> case NETDEV_PRE_UP: >>> - if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype))) >>> + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) && >>> + !(wdev->iftype == NL80211_IFTYPE_AP_VLAN && >>> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP && >>> + wdev->use_4addr)) >>> return notifier_from_errno(-EOPNOTSUPP); >> ? >> Or is there some reason it doesn't matter? >> >>> @@ -3439,6 +3438,11 @@ static int nl80211_new_interface(struct sk_buff >>> *skb, struct genl_info *info) >>> return err; >>> } >>> >>> + if (!(rdev->wiphy.interface_modes & (1 << type)) && >>> + !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr && >>> + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP)) >>> + return -EOPNOTSUPP; >>> + >> I also wonder if we shouldn't go "all in" and actually make the check >> something like >> >> check_interface_allowed(iftype, 4addr): >> if (iftype == AP_VLAN && 4addr) >> return wiphy.flags & WIPHY_FLAG_4ADDR_AP; >> >> else return wiphy.interface_modes & BIT(iftype); >> >> i.e. make it "you must have WIPHY_FLAG_4ADDR_AP to use 4-addr AP_VLAN >> interfaces", rather than "also allow it in this case". >> >> That would seem like the clearer semantics to me? > > > Yeah, it can be better; I'll check if this is feasible. > > > Thanks, > > Manikanta > > Hi Applying this patch instead of v1 broke WDS operation between two Litebeam AC Gen2 devices: Thu Jun 6 19:38:43 2019 kern.info kernel: [ 625.840896] device wlan0.sta1 left promiscuous mode Thu Jun 6 19:38:43 2019 kern.info kernel: [ 625.846146] br-lan: port 3(wlan0.sta1) entered disabled state Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.854349] ------------[ cut here ]------------ Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.859253] WARNING: CPU: 0 PID: 1417 at backports-4.19.32-1/net/mac80211/key.c:907 ieee80211_free_keys+0x170/0x228 [mac80211] Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.870871] Modules linked in: ath9k ath9k_common pppoe ppp_async ath9k_hw ath10k_pci ath10k_core ath pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD x_tables thermal_sys slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_log_common nf_flow_table_hw nf_flow_table nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack hwmon crc_ccitt compat ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.930674] CPU: 0 PID: 1417 Comm: hostapd Not tainted 4.14.118 #0 Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.936958] Stack : 804d0000 80489150 00000000 00000000 80460fc0 82e79a9c 82e9d35c 804b1307 Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.945494] 8045d190 00000589 80603670 0000038b 804838a0 00000001 82e79a50 688195c4 Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.954197] 00000000 00000000 80600000 00003dd0 00000000 00000000 00000008 00000000 Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.962745] 000000c8 d9e4e916 000000c7 00000000 80000000 00000000 83266130 83234cfc Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.971247] 00000009 0000038b 804838a0 00000100 00000001 8026bd44 00000000 80600000 Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.979754] ... Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.982249] Call Trace: Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.984764] [<8006a9ec>] show_stack+0x58/0x100 Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.989305] [<80085080>] __warn+0xe4/0x118 Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.993492] [<80085144>] warn_slowpath_null+0x1c/0x28 Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 625.998793] [<83234cfc>] ieee80211_free_keys+0x170/0x228 [mac80211] Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 626.005308] [<8321611c>] ieee80211_ibss_leave+0xa70/0x1940 [mac80211] Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 626.011970] [<802f4998>] rollback_registered_many+0x2dc/0x414 Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 626.017813] [<802f60b0>] unregister_netdevice_queue+0x94/0xec Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 626.023762] [<8321fd8c>] ieee80211_nan_func_match+0x2894/0x29a0 [mac80211] Thu Jun 6 19:38:43 2019 kern.warn kernel: [ 626.030795] ---[ end trace 5309fee2cf0ee39d ]--- Thu Jun 6 19:38:43 2019 daemon.notice hostapd: wlan0: WDS-STA-INTERFACE-REMOVED ifname=wlan0.sta1 sta_addr=18:e8:29:30:9b:2c Thu Jun 6 19:38:48 2019 daemon.info hostapd: wlan0: STA 18:e8:29:30:9b:2c IEEE 802.11: authenticated Thu Jun 6 19:38:48 2019 daemon.info hostapd: wlan0: STA 18:e8:29:30:9b:2c IEEE 802.11: associated (aid 1) Thu Jun 6 19:38:48 2019 kern.info kernel: [ 631.114522] br-lan: port 3(wlan0.sta1) entered blocking state Thu Jun 6 19:38:48 2019 kern.info kernel: [ 631.120364] br-lan: port 3(wlan0.sta1) entered disabled state Thu Jun 6 19:38:48 2019 kern.info kernel: [ 631.126603] device wlan0.sta1 entered promiscuous mode Thu Jun 6 19:38:48 2019 daemon.notice hostapd: wlan0: WDS-STA-INTERFACE-ADDED ifname=wlan0.sta1 sta_addr=18:e8:29:30:9b:2c Thu Jun 6 19:38:48 2019 daemon.err hostapd: Could not set interface wlan0.sta1 flags (UP): Invalid argument Thu Jun 6 19:38:48 2019 daemon.err hostapd: nl80211: Failed to set WDS STA interface wlan0.sta1 up Thu Jun 6 19:38:48 2019 daemon.err hostapd: nl80211: NL80211_ATTR_STA_VLAN (addr=18:e8:29:30:9b:2c ifname=wlan0.sta1 vlan_id=0) failed: -127 (Network is down) Thu Jun 6 19:38:48 2019 daemon.notice hostapd: wlan0: AP-STA-CONNECTED 18:e8:29:30:9b:2c Thu Jun 6 19:38:48 2019 daemon.info hostapd: wlan0: STA 18:e8:29:30:9b:2c WPA: pairwise key handshake completed (RSN) Reverting v1 of the patch restored connection. Regards, Tom
On Thu, 2019-06-06 at 20:41 +0200, Tom Psyborg wrote: > > Applying this patch instead of v1 broke WDS operation between two > Litebeam AC Gen2 devices: I'm confused, and not even sure which version I applied now. Manikanta, can you please check this and which version I have and which changes I might need? Thanks, Johannes
On 12/06/2019, Johannes Berg <johannes@sipsolutions.net> wrote: > On Thu, 2019-06-06 at 20:41 +0200, Tom Psyborg wrote: >> >> Applying this patch instead of v1 broke WDS operation between two >> Litebeam AC Gen2 devices: > > I'm confused, and not even sure which version I applied now. > > Manikanta, can you please check this and which version I have and which > changes I might need? > > Thanks, > Johannes > > > Never got reply. So I checked and definitely wrong version is applied (v2 or v3). Try to reproduce this yourself, I've posted details here: https://forum.openwrt.org/t/wds-client-wont-stay-connected-prev-auth-not-valid-using-recent-snapshot-builds/38194/20?u=psyborg
On Fri, 2019-06-14 at 19:45 +0200, Tom Psyborg wrote: > > Never got reply. So I checked and definitely wrong version is applied > (v2 or v3). Why would that be wrong? I shouldn't apply v1 when v2 and v3 fix comments I had ... > Try to reproduce this yourself, I've posted details here: > https://forum.openwrt.org/t/wds-client-wont-stay-connected-prev-auth-not-valid-using-recent-snapshot-builds/38194/20?u=psyborg I might even have the requisite hardware, but not the required time now, sorry. I'm also not convinced how this patch would affect *staying* connected... it should affect connecting to start with? johannes
On 14/06/2019, Johannes Berg <johannes@sipsolutions.net> wrote: > I'm also not convinced how this patch would affect *staying* > connected... it should affect connecting to start with? > > johannes > > If you don't want to read posts but only topic title, in short, no data pass thorugh with v2/v3 of this patch. Only v1 works.
On Fri, 2019-06-14 at 22:27 +0200, Tom Psyborg wrote: > > If you don't want to read posts but only topic title, in short, no > data pass thorugh with v2/v3 of this patch. Only v1 works. I can read what you're saying, but I cannot understand it. This patch doesn't modify any TX/RX path in any way. It only affects whether you can or can not create certain interfaces. johannes
Hi On 2019-06-12, Johannes Berg wrote: > On Thu, 2019-06-06 at 20:41 +0200, Tom Psyborg wrote: > > > > Applying this patch instead of v1 broke WDS operation between two > > Litebeam AC Gen2 devices: > > I'm confused, and not even sure which version I applied now. > > Manikanta, can you please check this and which version I have and which > changes I might need? I've tested (and left it running/ monitored) for two days without any problems between QCA9984 (ZyXEL nbg6817/ ipq8065, WDS-AP, affected before 33d915d9e8ce811d8958915ccd18d71a66c7c495 "{nl,mac}80211: allow 4addr AP operation on crypto controlled devices" went in) and AR9340 (TP-Link TL-WDR3600/ AR9344, WDS-Client, not affected by this issue), both under current (~2 days old) OpenWrt master[1] (ipq806x/ ath79, respectively). This patch is working fine and fixes the previous problems with 4addr on ath10k (QCA9984). Thank you a lot for looking into this! Regards Stefan Lippers-Hollmann -- [1] Loading modules backported from Linux version v4.19.32-0-g3a2156c839c7 Backport generated by backports.git v4.19.32-1-0-g1c4f7569 with this version of the patch applied, instead of v1 as currently present in OpenWrt/ master HEAD.
On Mon, 2019-06-17 at 07:07 +0200, Stefan Lippers-Hollmann wrote: > Hi > > On 2019-06-12, Johannes Berg wrote: > > On Thu, 2019-06-06 at 20:41 +0200, Tom Psyborg wrote: > > > > > > Applying this patch instead of v1 broke WDS operation between two > > > Litebeam AC Gen2 devices: > > > > I'm confused, and not even sure which version I applied now. > > > > Manikanta, can you please check this and which version I have and which > > changes I might need? > > I've tested (and left it running/ monitored) for two days without > any problems between QCA9984 (ZyXEL nbg6817/ ipq8065, WDS-AP, affected > before 33d915d9e8ce811d8958915ccd18d71a66c7c495 "{nl,mac}80211: allow > 4addr AP operation on crypto controlled devices" went in) and AR9340 > (TP-Link TL-WDR3600/ AR9344, WDS-Client, not affected by this issue), > both under current (~2 days old) OpenWrt master[1] (ipq806x/ ath79, > respectively). This patch is working fine and fixes the previous > problems with 4addr on ath10k (QCA9984). "This patch" is v3 then, presumably? I just checked, and it looks like I indeed applied v3. So basically you're saying it works as affected, since you were previously affected by the unavailability of 4addr interfaces on ath10k hardware, which are now available, right? Tom, I notice you're using a very old base kernel ("backports-4.19.32- 1") - are you sure you were even able to apply this patch correctly? johannes
Hi On 2019-06-17, Johannes Berg wrote: > On Mon, 2019-06-17 at 07:07 +0200, Stefan Lippers-Hollmann wrote: [...] > > I've tested (and left it running/ monitored) for two days without > > any problems between QCA9984 (ZyXEL nbg6817/ ipq8065, WDS-AP, affected > > before 33d915d9e8ce811d8958915ccd18d71a66c7c495 "{nl,mac}80211: allow > > 4addr AP operation on crypto controlled devices" went in) and AR9340 > > (TP-Link TL-WDR3600/ AR9344, WDS-Client, not affected by this issue), > > both under current (~2 days old) OpenWrt master[1] (ipq806x/ ath79, > > respectively). This patch is working fine and fixes the previous > > problems with 4addr on ath10k (QCA9984). > > "This patch" is v3 then, presumably? I just checked, and it looks like I > indeed applied v3. I've tested: https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git/commit/?id=33d915d9e8ce811d8958915ccd18d71a66c7c495 And applied it to OpenWrt's (v4.19 based) backports package: https://github.com/openwrt/openwrt/pull/2139/commits/425ab52a0d451938c87ebafdf247b86fa563ad36 > So basically you're saying it works as affected, since you were > previously affected by the unavailability of 4addr interfaces on ath10k > hardware, which are now available, right? Yes, QCA9984/ ath10k[1] as 4addr/ WDS-AP was affected starting with (backports-) kernel 4.18 and above. I've tested v1 and the version you merged with https://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211.git/commit/?id=33d915d9e8ce811d8958915ccd18d71a66c7c495 both versions of this patch fix the problem for me and survived a slightly over 2 day stress test. Regards Stefan Lippers-Hollmann [1] ath10k_pci 0001:01:00.0: firmware ver 10.4-3.9.0.2-00044 api 5 features no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps crc32 c3e1b393
Hi Checked out r10011 from openwrt git on May, 15; built images and flashed devices; tried to set up WDS (AP) + WDS (Client); got this in logs: https://forum.openwrt.org/t/ath10k-wds-support-missing/30346/15?u=psyborg Saw this patch in my inbox and checked openwrt sources, to find out there was v1 used: https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/mac80211/patches/subsys/390-nl-mac-80211-allow-4addr-AP-operation-on-crypto-cont.patch Reverted v1 of the patch and patched manually to v3 (double checked), did not help. Found patch that fixes problem and applied; https://github.com/openwrt/openwrt/pull/2048 Now I got this in logs: https://forum.openwrt.org/t/wds-client-wont-stay-connected-prev-auth-not-valid-using-recent-snapshot-builds/38194/20?u=psyborg Reverted again v3 of this patch to v1, and the connection worked as expected. v4.19.32 is current in openwrt master, and testing against ath9k devices may not reveal exact issue. notice in one of my posts on forums that i was able to bridge it with archer c7 running tp-link fw without any of these patches
Hi Tom, > Checked out r10011 from openwrt git on May, 15; built images and > flashed devices; tried to set up WDS (AP) + WDS (Client); got this in > logs: https://forum.openwrt.org/t/ath10k-wds-support-missing/30346/15?u=psyborg I'm not sure ... this is saying -ENOENT?? > Saw this patch in my inbox and checked openwrt sources, to find out > there was v1 used: > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=package/kernel/mac80211/patches/subsys/390-nl-mac-80211-allow-4addr-AP-operation-on-crypto-cont.patch > > Reverted v1 of the patch and patched manually to v3 (double checked), > did not help. > > Found patch that fixes problem and applied; > https://github.com/openwrt/openwrt/pull/2048 I don't see how that's related. > Now I got this in logs: > https://forum.openwrt.org/t/wds-client-wont-stay-connected-prev-auth-not-valid-using-recent-snapshot-builds/38194/20?u=psyborg Again, I don't see how that's related. This is telling you something about keys etc. All this stuff about openwrt etc. is very confusing. Can you at least collect some tracing (trace-cmd) to show what's going on? johannes
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 87dae86..9481396 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -3839,7 +3839,8 @@ struct cfg80211_ops { * on wiphy_new(), but can be changed by the driver if it has a good * reason to override the default * @WIPHY_FLAG_4ADDR_AP: supports 4addr mode even on AP (with a single station - * on a VLAN interface) + * on a VLAN interface). This flag also serves an extra purpose of + * supporting 4ADDR AP mode on devices which do not support AP/VLAN iftype. * @WIPHY_FLAG_4ADDR_STATION: supports 4addr mode even as a station * @WIPHY_FLAG_CONTROL_PORT_PROTOCOL: This device supports setting the * control port protocol ethertype. The device also honours the diff --git a/net/mac80211/util.c b/net/mac80211/util.c index cba4633..1c8384f 100644 --- a/net/mac80211/util.c +++ b/net/mac80211/util.c @@ -3795,7 +3795,9 @@ int ieee80211_check_combinations(struct ieee80211_sub_if_data *sdata, } /* Always allow software iftypes */ - if (local->hw.wiphy->software_iftypes & BIT(iftype)) { + if (local->hw.wiphy->software_iftypes & BIT(iftype) || + (iftype == NL80211_IFTYPE_AP_VLAN && + local->hw.wiphy->flags & WIPHY_FLAG_4ADDR_AP)) { if (radar_detect) return -EINVAL; return 0; diff --git a/net/wireless/core.c b/net/wireless/core.c index b36ad8e..4e83892 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -1396,8 +1396,12 @@ static int cfg80211_netdev_notifier_call(struct notifier_block *nb, } break; case NETDEV_PRE_UP: - if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype))) + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype)) && + !(wdev->iftype == NL80211_IFTYPE_AP_VLAN && + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP && + wdev->use_4addr)) return notifier_from_errno(-EOPNOTSUPP); + if (rfkill_blocked(rdev->rfkill)) return notifier_from_errno(-ERFKILL); break; diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index fffe4b3..4b3c528 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -3419,8 +3419,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info) if (info->attrs[NL80211_ATTR_IFTYPE]) type = nla_get_u32(info->attrs[NL80211_ATTR_IFTYPE]); - if (!rdev->ops->add_virtual_intf || - !(rdev->wiphy.interface_modes & (1 << type))) + if (!rdev->ops->add_virtual_intf) return -EOPNOTSUPP; if ((type == NL80211_IFTYPE_P2P_DEVICE || type == NL80211_IFTYPE_NAN || @@ -3439,6 +3438,11 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info) return err; } + if (!(rdev->wiphy.interface_modes & (1 << type)) && + !(type == NL80211_IFTYPE_AP_VLAN && params.use_4addr && + rdev->wiphy.flags & WIPHY_FLAG_4ADDR_AP)) + return -EOPNOTSUPP; + err = nl80211_parse_mon_options(rdev, type, info, ¶ms); if (err < 0) return err;
As per the current design, in the case of sw crypto controlled devices, it is the device which advertises the support for AP/VLAN iftype based on it's ability to tranmsit packets encrypted in software (In VLAN functionality, group traffic generated for a specific VLAN group is always encrypted in software). Commit db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto controlled devices") has introduced this change. Since 4addr AP operation also uses AP/VLAN iftype, this conditional way of advertising AP/VLAN support has broken 4addr AP mode operation on crypto controlled devices which do not support VLAN functionality. In the case of ath10k driver, not all firmwares have support for VLAN functionality but all can support 4addr AP operation. Because AP/VLAN support is not advertised for these devices, 4addr AP operations are also blocked. Fix this by allowing 4addr operation on devices which do not support AP/VLAN iftype but can support 4addr AP operation (decision is based on the wiphy flag WIPHY_FLAG_4ADDR_AP). Fixes: db3bdcb9c3ff ("mac80211: allow AP_VLAN operation on crypto controlled devices") Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org> --- v3: - Fixes line correction v2: - Commit message changes - Squashed two if conditions into one include/net/cfg80211.h | 3 ++- net/mac80211/util.c | 4 +++- net/wireless/core.c | 6 +++++- net/wireless/nl80211.c | 8 ++++++-- 4 files changed, 16 insertions(+), 5 deletions(-)