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 <[email protected]>
---
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(-)
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;
--
2.7.4
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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