* EAP AP/VLAN: multicast not send to client
@ 2021-02-01 20:54 Sven Eckelmann
2021-02-02 7:04 ` Sebastian Gottschall
0 siblings, 1 reply; 14+ messages in thread
From: Sven Eckelmann @ 2021-02-01 20:54 UTC (permalink / raw)
To: ath10k
[-- Attachment #1.1.1: Type: text/plain, Size: 3093 bytes --]
Hi,
I was just testing EAP with dynamic_vlan=2 (and a radius server which returns
the VLANID 112 for this client). This worked perfectly fine with ath9k. But
for some reason, the client was not able to receive any multicast/broadcast
packets with ath10k.
The used OpenWrt 19.07 config was:
config wifi-iface 'eap_radio0'
option device 'radio0'
option mode 'ap'
option ssid 'MyEAPSSID'
option encryption 'wpa2'
option ieee80211r '1'
option server '192.168.178.123'
option key 'testing123'
option dynamic_vlan '2'
option vlan_bridge 'br-lan'
Which creates following hostapd configuration:
driver=nl80211
logger_syslog=127
logger_syslog_level=2
logger_stdout=127
logger_stdout_level=2
country_code=DE
ieee80211d=1
hw_mode=g
supported_rates=60 90 120 180 240 360 480 540
basic_rates=60 120 240
beacon_int=1000
dtim_period=2
channel=acs_survey
chanlist=11
ieee80211n=1
ht_coex=0
ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]
interface=wlan0
ctrl_interface=/var/run/hostapd
bss_load_update_period=60
chan_util_avg_period=600
disassoc_low_ack=1
skip_inactivity_poll=0
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
utf8_ssid=1
multi_ap=0
auth_server_addr=192.168.178.123
auth_server_port=1812
auth_server_shared_secret=testing123
eapol_key_index_workaround=1
ieee8021x=1
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=MyEAPSSID
mobility_domain=3bf3
ft_psk_generate_local=0
ft_over_ds=1
reassociation_deadline=1000
nas_identifier=ac86749f4dc2
r0_key_lifetime=10000
pmk_r1_push=0
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-EAP FT-EAP
okc=0
disable_pmksa_caching=1
dynamic_vlan=2
vlan_naming=1
vlan_bridge=br-lan
vlan_file=/var/run/hostapd-wlan0.vlan
bssid=ac:86:74:9f:4d:c2
The client connected and then following was tested to send some data to the
client (which had wireshark running to check for incoming packets):
ping ff02::1%wlan0.112
With the ath9k AP, I could see the packets. With ath10k, I wasn't able to see
anything in the air. So for some reason something (firmware?) is dropping the
packets. Btw. unicast seems to work fine - but little bit hard to use when ARP
or ICMPv6 multicast packets are not working.
And there were various reports already in the past which seem to suggest that
this a problem since a long time:
* https://forum.openwrt.org/t/802-1x-with-dynamic-vlans-5ghz-and-mdns-strange-behaviour/50180
* https://bugs.openwrt.org/index.php?do=details&task_id=3266&pagenum=3
* https://forum.openwrt.org/t/multicast-not-working-over-bridged-ap/69059
I have also added the output of
`perf ftrace ping -c 1 -I wlan0.112 255.255.255.255` in case somebody wants to
check the trace
Kind regards,
Sven
[-- Attachment #1.1.2: ftrace.log.zip --]
[-- Type: application/zip, Size: 113524 bytes --]
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-01 20:54 EAP AP/VLAN: multicast not send to client Sven Eckelmann
@ 2021-02-02 7:04 ` Sebastian Gottschall
2021-02-02 8:23 ` Sven Eckelmann
0 siblings, 1 reply; 14+ messages in thread
From: Sebastian Gottschall @ 2021-02-02 7:04 UTC (permalink / raw)
To: Sven Eckelmann, ath10k
the standard ath10k firmware für qca988x chipsets does filter vlans.
the only option for you is using the CT firmware by candelatech, which
does not suffer from this issue.
Sebastian
Am 01.02.2021 um 21:54 schrieb Sven Eckelmann:
> Hi,
>
> I was just testing EAP with dynamic_vlan=2 (and a radius server which returns
> the VLANID 112 for this client). This worked perfectly fine with ath9k. But
> for some reason, the client was not able to receive any multicast/broadcast
> packets with ath10k.
>
> The used OpenWrt 19.07 config was:
>
> config wifi-iface 'eap_radio0'
> option device 'radio0'
> option mode 'ap'
> option ssid 'MyEAPSSID'
> option encryption 'wpa2'
> option ieee80211r '1'
> option server '192.168.178.123'
> option key 'testing123'
> option dynamic_vlan '2'
> option vlan_bridge 'br-lan'
>
> Which creates following hostapd configuration:
>
>
> driver=nl80211
> logger_syslog=127
> logger_syslog_level=2
> logger_stdout=127
> logger_stdout_level=2
> country_code=DE
> ieee80211d=1
> hw_mode=g
> supported_rates=60 90 120 180 240 360 480 540
> basic_rates=60 120 240
> beacon_int=1000
> dtim_period=2
> channel=acs_survey
> chanlist=11
>
>
> ieee80211n=1
> ht_coex=0
> ht_capab=[LDPC][SHORT-GI-20][SHORT-GI-40][TX-STBC][RX-STBC1][MAX-AMSDU-7935][DSSS_CCK-40]
>
> interface=wlan0
> ctrl_interface=/var/run/hostapd
> bss_load_update_period=60
> chan_util_avg_period=600
> disassoc_low_ack=1
> skip_inactivity_poll=0
> preamble=1
> wmm_enabled=1
> ignore_broadcast_ssid=0
> uapsd_advertisement_enabled=1
> utf8_ssid=1
> multi_ap=0
> auth_server_addr=192.168.178.123
> auth_server_port=1812
> auth_server_shared_secret=testing123
> eapol_key_index_workaround=1
> ieee8021x=1
> auth_algs=1
> wpa=2
> wpa_pairwise=CCMP
> ssid=MyEAPSSID
> mobility_domain=3bf3
> ft_psk_generate_local=0
> ft_over_ds=1
> reassociation_deadline=1000
> nas_identifier=ac86749f4dc2
> r0_key_lifetime=10000
> pmk_r1_push=0
> wpa_disable_eapol_key_retries=0
> wpa_key_mgmt=WPA-EAP FT-EAP
> okc=0
> disable_pmksa_caching=1
> dynamic_vlan=2
> vlan_naming=1
> vlan_bridge=br-lan
> vlan_file=/var/run/hostapd-wlan0.vlan
> bssid=ac:86:74:9f:4d:c2
>
>
> The client connected and then following was tested to send some data to the
> client (which had wireshark running to check for incoming packets):
>
> ping ff02::1%wlan0.112
>
> With the ath9k AP, I could see the packets. With ath10k, I wasn't able to see
> anything in the air. So for some reason something (firmware?) is dropping the
> packets. Btw. unicast seems to work fine - but little bit hard to use when ARP
> or ICMPv6 multicast packets are not working.
>
> And there were various reports already in the past which seem to suggest that
> this a problem since a long time:
>
> * https://forum.openwrt.org/t/802-1x-with-dynamic-vlans-5ghz-and-mdns-strange-behaviour/50180
> * https://bugs.openwrt.org/index.php?do=details&task_id=3266&pagenum=3
> * https://forum.openwrt.org/t/multicast-not-working-over-bridged-ap/69059
>
> I have also added the output of
> `perf ftrace ping -c 1 -I wlan0.112 255.255.255.255` in case somebody wants to
> check the trace
>
> Kind regards,
> Sven
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-02 7:04 ` Sebastian Gottschall
@ 2021-02-02 8:23 ` Sven Eckelmann
2021-02-02 8:58 ` Sebastian Gottschall
0 siblings, 1 reply; 14+ messages in thread
From: Sven Eckelmann @ 2021-02-02 8:23 UTC (permalink / raw)
To: ath10k, Sebastian Gottschall, Ben Greear
[-- Attachment #1.1: Type: text/plain, Size: 1237 bytes --]
On Tuesday, 2 February 2021 08:04:56 CET Sebastian Gottschall wrote:
> the standard ath10k firmware für qca988x chipsets does filter vlans.
Just to be sure that we are talking about the same thing: I am (or actually
hostapd is) using NL80211_IFTYPE_AP_VLAN here - not 802.1Q.
> the only option for you is using the CT firmware by candelatech, which
> does not suffer from this issue.
Thanks for the interesting hint - but there is a twist :)
I've initially tried ath10k-ct with the candelatech firmware.
5.4.93+2021-01-11-9fe1df7d-1 with 10.4b-ct-4019-fW-13-5ae337bb1 to be more
precise. And later also switched to the ath10k backport from 5.8.18(-1-5).
Sorry for forgetting to mention such details in the first mail.
And I've just noticed that I was always testing with the ath10k-ct firmware
(which is the default in OpenWrt but never with the official one from Kalle's
ath10k-firmware tree. So I've just switched to QCA4019 hw1.0 10.4-3.6-00140
from the official tree and the problem went away.
For Ben Greear's firmware, the only workaround which I found until now was to
set NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED to 1 to force mac80211 to send
multicast as unicast.
Kind regards,
Sven
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-02 8:23 ` Sven Eckelmann
@ 2021-02-02 8:58 ` Sebastian Gottschall
2021-02-02 9:06 ` Sven Eckelmann
0 siblings, 1 reply; 14+ messages in thread
From: Sebastian Gottschall @ 2021-02-02 8:58 UTC (permalink / raw)
To: Sven Eckelmann, ath10k, Ben Greear
Am 02.02.2021 um 09:23 schrieb Sven Eckelmann:
> On Tuesday, 2 February 2021 08:04:56 CET Sebastian Gottschall wrote:
>> the standard ath10k firmware für qca988x chipsets does filter vlans.
> Just to be sure that we are talking about the same thing: I am (or actually
> hostapd is) using NL80211_IFTYPE_AP_VLAN here - not 802.1Q.
then it might be something different. i'm not sure at that point. but
consider that AP_VLAN is also used for WDS STA/WDS AP implementations.
so each wds station becomes a individual interface on ap side for
bridging. that might of course have a influence to broadcast/multicast
frames
in addition the 10.4 firmware series has a special wmi flag which is not
used by ath10k, but solved alot of problems for me (in my case with
reauthentication)
WMI_VDEV_DISABLE_4_ADDR_SRC_LRN
this might be unrelated to your issue. but this flag must be set anyway
for proper work. but it isnt by default in all 10.4 firmwares.
>
>> the only option for you is using the CT firmware by candelatech, which
>> does not suffer from this issue.
> Thanks for the interesting hint - but there is a twist :)
>
> I've initially tried ath10k-ct with the candelatech firmware.
> 5.4.93+2021-01-11-9fe1df7d-1 with 10.4b-ct-4019-fW-13-5ae337bb1 to be more
> precise. And later also switched to the ath10k backport from 5.8.18(-1-5).
> Sorry for forgetting to mention such details in the first mail.
>
> And I've just noticed that I was always testing with the ath10k-ct firmware
> (which is the default in OpenWrt but never with the official one from Kalle's
> ath10k-firmware tree. So I've just switched to QCA4019 hw1.0 10.4-3.6-00140
> from the official tree and the problem went away.
>
> For Ben Greear's firmware, the only workaround which I found until now was to
> set NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED to 1 to force mac80211 to send
> multicast as unicast.
so if its a pure multicast/unicast issue it could be also a basic rate
issue for ct firmwares.
lets see what ben has to say here.
>
> Kind regards,
> Sven
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-02 8:58 ` Sebastian Gottschall
@ 2021-02-02 9:06 ` Sven Eckelmann
2021-02-02 9:12 ` Sebastian Gottschall
0 siblings, 1 reply; 14+ messages in thread
From: Sven Eckelmann @ 2021-02-02 9:06 UTC (permalink / raw)
To: ath10k, Ben Greear, Sebastian Gottschall
[-- Attachment #1.1: Type: text/plain, Size: 1725 bytes --]
On Tuesday, 2 February 2021 09:58:45 CET Sebastian Gottschall wrote:
>
> Am 02.02.2021 um 09:23 schrieb Sven Eckelmann:
> > On Tuesday, 2 February 2021 08:04:56 CET Sebastian Gottschall wrote:
> >> the standard ath10k firmware für qca988x chipsets does filter vlans.
> > Just to be sure that we are talking about the same thing: I am (or actually
> > hostapd is) using NL80211_IFTYPE_AP_VLAN here - not 802.1Q.
> then it might be something different. i'm not sure at that point. but
> consider that AP_VLAN is also used for WDS STA/WDS AP implementations.
> so each wds station becomes a individual interface on ap side for
> bridging. that might of course have a influence to broadcast/multicast
> frames
Interestingly, the WDS "mode" works perfectly fine on the same hardware. So I
have not a real idea what the difference is between EAP AP_VLAN and WDS (PSK)
AP_VLAN at the moment.
> in addition the 10.4 firmware series has a special wmi flag which is not
> used by ath10k, but solved alot of problems for me (in my case with
> reauthentication)
> WMI_VDEV_DISABLE_4_ADDR_SRC_LRN
> this might be unrelated to your issue. but this flag must be set anyway
> for proper work. but it isnt by default in all 10.4 firmwares.
Good to know, thanks.
> > For Ben Greear's firmware, the only workaround which I found until now was to
> > set NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED to 1 to force mac80211 to send
> > multicast as unicast.
> so if its a pure multicast/unicast issue it could be also a basic rate
> issue for ct firmwares.
Interesting idea. Btw. I've also switched to sw crypto for a test just to make
sure that there is no HW key problem.
Kind regards,
Sven
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-02 9:06 ` Sven Eckelmann
@ 2021-02-02 9:12 ` Sebastian Gottschall
2021-02-02 10:12 ` Sven Eckelmann
0 siblings, 1 reply; 14+ messages in thread
From: Sebastian Gottschall @ 2021-02-02 9:12 UTC (permalink / raw)
To: Sven Eckelmann, ath10k, Ben Greear
>> then it might be something different. i'm not sure at that point. but
>> consider that AP_VLAN is also used for WDS STA/WDS AP implementations.
>> so each wds station becomes a individual interface on ap side for
>> bridging. that might of course have a influence to broadcast/multicast
>> frames
> Interestingly, the WDS "mode" works perfectly fine on the same hardware. So I
> have not a real idea what the difference is between EAP AP_VLAN and WDS (PSK)
> AP_VLAN at the moment.
mmh. l have a idea
try the following (this a patch in my tree) and check also the wmi
services for this service flag which might be a difference between these
firmwares
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -9003,10 +9003,10 @@ int ath10k_mac_register(struct ath10k *ar)
goto err_dfs_detector_exit;
}
- if (test_bit(WMI_SERVICE_PER_PACKET_SW_ENCRYPT,
ar->wmi.svc_map)) {
+// if (test_bit(WMI_SERVICE_PER_PACKET_SW_ENCRYPT,
ar->wmi.svc_map)) {
ar->hw->wiphy->interface_modes |=
BIT(NL80211_IFTYPE_AP_VLAN);
ar->hw->wiphy->software_iftypes |=
BIT(NL80211_IFTYPE_AP_VLAN);
- }
+// }
if (!ath_is_world_regd(&ar->ath_common.regulatory)) {
ret = regulatory_hint(ar->hw->wiphy,
>
>> in addition the 10.4 firmware series has a special wmi flag which is not
>> used by ath10k, but solved alot of problems
>> for me (in my case with
>> reauthentication)
>> WMI_VDEV_DISABLE_4_ADDR_SRC_LRN
>> this might be unrelated to your issue. but this flag must be set anyway
>> for proper work. but it isnt by default in all 10.4 firmwares.
> Good to know, thanks.
>
>>> For Ben Greear's firmware, the only workaround which I found until now was to
>>> set NL80211_ATTR_MULTICAST_TO_UNICAST_ENABLED to 1 to force mac80211 to send
>>> multicast as unicast.
>> so if its a pure multicast/unicast issue it could be also a basic rate
>> issue for ct firmwares.
> Interesting idea. Btw. I've also switched to sw crypto for a test just to make
> sure that there is no HW key problem.
>
> Kind regards,
> Sven
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-02 9:12 ` Sebastian Gottschall
@ 2021-02-02 10:12 ` Sven Eckelmann
2021-02-02 13:27 ` Ben Greear
0 siblings, 1 reply; 14+ messages in thread
From: Sven Eckelmann @ 2021-02-02 10:12 UTC (permalink / raw)
To: ath10k, Ben Greear, Sebastian Gottschall
[-- Attachment #1.1.1: Type: text/plain, Size: 1099 bytes --]
On Tuesday, 2 February 2021 10:12:45 CET Sebastian Gottschall wrote:
> mmh. l have a idea
>
> try the following (this a patch in my tree) and check also the wmi
> services for this service flag which might be a difference between these
> firmwares
>
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -9003,10 +9003,10 @@ int ath10k_mac_register(struct ath10k *ar)
[...]
Thanks, for the idea. But this has no effect on the problem. I have also
attached the services and feature information (from ath10k-ct's perspective to
have hopefully a more complete look at the differences). And it seems both
have WMI_SERVICE_PER_PACKET_SW_ENCRYPT and Ben's firmware also
ATH10K_FW_FEATURE_CONSUME_BLOCK_ACK_CT (which would also have "enabled" this
code section).
The biggest difference (which would affect also the non-ct ath10k) would be in
wmi_services. Ben Greears firmware doesnt support:
* WMI_SERVICE_PEER_CACHING
* WMI_SERVICE_HTT_MGMT_TX_COMP_VALID_FLAGS
* WMI_SERVICE_HOST_DFS_CHECK_SUPPORT
* WMI_SERVICE_TPC_STATS_FINAL
Kind regards,
Sven
[-- Attachment #1.1.2: greearb-firmware_info --]
[-- Type: text/plain, Size: 426 bytes --]
directory: ath10k/QCA4019/hw1.0
firmware: firmware-5.bin
fwcfg: fwcfg-ahb-a000000.wifi.txt
bus: a000000.wifi
features: mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT
version: 10.4b-ct-4019-fW-13-5ae337bb1
hw_rev: 4019
board: board-2.bin
[-- Attachment #1.1.3: greearb-wmi_services --]
[-- Type: text/plain, Size: 5407 bytes --]
WMI_SERVICE_BEACON_OFFLOAD -
WMI_SERVICE_SCAN_OFFLOAD -
WMI_SERVICE_ROAM_OFFLOAD -
WMI_SERVICE_BCN_MISS_OFFLOAD enabled
WMI_SERVICE_STA_PWRSAVE enabled
WMI_SERVICE_STA_ADVANCED_PWRSAVE enabled
WMI_SERVICE_AP_UAPSD enabled
WMI_SERVICE_AP_DFS -
WMI_SERVICE_11AC enabled
WMI_SERVICE_BLOCKACK enabled
WMI_SERVICE_PHYERR enabled
WMI_SERVICE_BCN_FILTER -
WMI_SERVICE_RTT enabled
WMI_SERVICE_RATECTRL -
WMI_SERVICE_WOW -
WMI_SERVICE_RATECTRL_CACHE enabled
WMI_SERVICE_IRAM_TIDS -
WMI_SERVICE_ARPNS_OFFLOAD -
WMI_SERVICE_NLO -
WMI_SERVICE_GTK_OFFLOAD -
WMI_SERVICE_SCAN_SCH enabled
WMI_SERVICE_CSA_OFFLOAD -
WMI_SERVICE_CHATTER -
WMI_SERVICE_COEX_FREQAVOID -
WMI_SERVICE_PACKET_POWER_SAVE -
WMI_SERVICE_FORCE_FW_HANG enabled
WMI_SERVICE_GPIO enabled
WMI_SERVICE_STA_DTIM_PS_MODULATED_DTIM -
WMI_SERVICE_STA_UAPSD_BASIC_AUTO_TRIG -
WMI_SERVICE_STA_UAPSD_VAR_AUTO_TRIG -
WMI_SERVICE_STA_KEEP_ALIVE -
WMI_SERVICE_TX_ENCAP enabled
WMI_SERVICE_BURST -
WMI_SERVICE_SMART_ANTENNA_SW_SUPPORT enabled
WMI_SERVICE_SMART_ANTENNA_HW_SUPPORT -
WMI_SERVICE_ROAM_SCAN_OFFLOAD -
WMI_SERVICE_AP_PS_DETECT_OUT_OF_SYNC enabled
WMI_SERVICE_EARLY_RX -
WMI_SERVICE_STA_SMPS -
WMI_SERVICE_FWTEST -
WMI_SERVICE_STA_WMMAC -
WMI_SERVICE_TDLS -
WMI_SERVICE_MCC_BCN_INTERVAL_CHANGE -
WMI_SERVICE_ADAPTIVE_OCS -
WMI_SERVICE_BA_SSN_SUPPORT -
WMI_SERVICE_FILTER_IPSEC_NATKEEPALIVE -
WMI_SERVICE_WLAN_HB -
WMI_SERVICE_LTE_ANT_SHARE_SUPPORT -
WMI_SERVICE_BATCH_SCAN -
WMI_SERVICE_QPOWER -
WMI_SERVICE_PLMREQ -
WMI_SERVICE_THERMAL_MGMT -
WMI_SERVICE_RMC -
WMI_SERVICE_MHF_OFFLOAD -
WMI_SERVICE_COEX_SAR -
WMI_SERVICE_BCN_TXRATE_OVERRIDE -
WMI_SERVICE_NAN -
WMI_SERVICE_L1SS_STAT -
WMI_SERVICE_ESTIMATE_LINKSPEED -
WMI_SERVICE_OBSS_SCAN -
WMI_SERVICE_TDLS_OFFCHAN -
WMI_SERVICE_TDLS_UAPSD_BUFFER_STA -
WMI_SERVICE_TDLS_UAPSD_SLEEP_STA -
WMI_SERVICE_IBSS_PWRSAVE -
WMI_SERVICE_LPASS -
WMI_SERVICE_EXTSCAN -
WMI_SERVICE_D0WOW -
WMI_SERVICE_HSOFFLOAD -
WMI_SERVICE_ROAM_HO_OFFLOAD -
WMI_SERVICE_RX_FULL_REORDER -
WMI_SERVICE_DHCP_OFFLOAD -
WMI_SERVICE_STA_RX_IPA_OFFLOAD_SUPPORT -
WMI_SERVICE_MDNS_OFFLOAD -
WMI_SERVICE_SAP_AUTH_OFFLOAD -
WMI_SERVICE_ATF enabled
WMI_SERVICE_COEX_GPIO enabled
WMI_SERVICE_ENHANCED_PROXY_STA enabled
WMI_SERVICE_TT enabled
WMI_SERVICE_PEER_CACHING -
WMI_SERVICE_AUX_SPECTRAL_INTF -
WMI_SERVICE_AUX_CHAN_LOAD_INTF -
WMI_SERVICE_BSS_CHANNEL_INFO_64 enabled
WMI_SERVICE_EXT_RES_CFG_SUPPORT enabled
WMI_SERVICE_MESH_11S enabled
WMI_SERVICE_MESH_NON_11S enabled
WMI_SERVICE_PEER_STATS enabled
WMI_SERVICE_RESTRT_CHNL_SUPPORT -
WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT enabled
WMI_SERVICE_TX_MODE_PUSH_ONLY enabled
WMI_SERVICE_TX_MODE_PUSH_PULL enabled
WMI_SERVICE_TX_MODE_DYNAMIC enabled
WMI_SERVICE_VDEV_RX_FILTER enabled
WMI_SERVICE_BTCOEX enabled
WMI_SERVICE_CHECK_CAL_VERSION enabled
WMI_SERVICE_DBGLOG_WARN2 -
WMI_SERVICE_BTCOEX_DUTY_CYCLE enabled
WMI_SERVICE_4_WIRE_COEX_SUPPORT enabled
WMI_SERVICE_EXTENDED_NSS_SUPPORT enabled
WMI_SERVICE_PROG_GPIO_BAND_SELECT enabled
WMI_SERVICE_SMART_LOGGING_SUPPORT enabled
WMI_SERVICE_TDLS_CONN_TRACKER_IN_HOST_MODE -
WMI_SERVICE_TDLS_EXPLICIT_MODE_ONLY -
WMI_SERVICE_MGMT_TX_WMI -
WMI_SERVICE_TDLS_WIDER_BANDWIDTH -
WMI_SERVICE_HTT_MGMT_TX_COMP_VALID_FLAGS -
WMI_SERVICE_HOST_DFS_CHECK_SUPPORT -
WMI_SERVICE_TPC_STATS_FINAL -
WMI_SERVICE_RESET_CHIP -
WMI_SERVICE_SPOOF_MAC_SUPPORT -
WMI_SERVICE_TX_DATA_ACK_RSSI -
WMI_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT -
WMI_SERVICE_VDEV_DISABLE_4_ADDR_SRC_LRN_SUPPORT -
WMI_SERVICE_BB_TIMING_CONFIG_SUPPORT -
WMI_SERVICE_THERM_THROT enabled
WMI_SERVICE_RTT_RESPONDER_ROLE -
WMI_SERVICE_PER_PACKET_SW_ENCRYPT enabled
WMI_SERVICE_REPORT_AIRTIME -
WMI_SERVICE_SYNC_DELETE_CMDS -
WMI_SERVICE_TX_PWR_PER_PEER -
WMI_SERVICE_SUPPORT_EXTEND_ADDRESS -
[-- Attachment #1.1.4: kalle-firmware_info --]
[-- Type: text/plain, Size: 259 bytes --]
directory: ath10k/QCA4019/hw1.0
firmware: firmware-5.bin
fwcfg: fwcfg-ahb-a000000.wifi.txt
bus: a000000.wifi
features: no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps
version: 10.4-3.6-00140
hw_rev: 4019
board: board-2.bin
[-- Attachment #1.1.5: kalle-wmi_services --]
[-- Type: text/plain, Size: 5431 bytes --]
WMI_SERVICE_BEACON_OFFLOAD -
WMI_SERVICE_SCAN_OFFLOAD -
WMI_SERVICE_ROAM_OFFLOAD -
WMI_SERVICE_BCN_MISS_OFFLOAD enabled
WMI_SERVICE_STA_PWRSAVE enabled
WMI_SERVICE_STA_ADVANCED_PWRSAVE enabled
WMI_SERVICE_AP_UAPSD enabled
WMI_SERVICE_AP_DFS -
WMI_SERVICE_11AC enabled
WMI_SERVICE_BLOCKACK enabled
WMI_SERVICE_PHYERR enabled
WMI_SERVICE_BCN_FILTER -
WMI_SERVICE_RTT enabled
WMI_SERVICE_RATECTRL -
WMI_SERVICE_WOW -
WMI_SERVICE_RATECTRL_CACHE enabled
WMI_SERVICE_IRAM_TIDS -
WMI_SERVICE_ARPNS_OFFLOAD -
WMI_SERVICE_NLO -
WMI_SERVICE_GTK_OFFLOAD -
WMI_SERVICE_SCAN_SCH enabled
WMI_SERVICE_CSA_OFFLOAD -
WMI_SERVICE_CHATTER -
WMI_SERVICE_COEX_FREQAVOID -
WMI_SERVICE_PACKET_POWER_SAVE -
WMI_SERVICE_FORCE_FW_HANG enabled
WMI_SERVICE_GPIO enabled
WMI_SERVICE_STA_DTIM_PS_MODULATED_DTIM -
WMI_SERVICE_STA_UAPSD_BASIC_AUTO_TRIG -
WMI_SERVICE_STA_UAPSD_VAR_AUTO_TRIG -
WMI_SERVICE_STA_KEEP_ALIVE -
WMI_SERVICE_TX_ENCAP enabled
WMI_SERVICE_BURST -
WMI_SERVICE_SMART_ANTENNA_SW_SUPPORT enabled
WMI_SERVICE_SMART_ANTENNA_HW_SUPPORT -
WMI_SERVICE_ROAM_SCAN_OFFLOAD -
WMI_SERVICE_AP_PS_DETECT_OUT_OF_SYNC enabled
WMI_SERVICE_EARLY_RX -
WMI_SERVICE_STA_SMPS -
WMI_SERVICE_FWTEST -
WMI_SERVICE_STA_WMMAC -
WMI_SERVICE_TDLS -
WMI_SERVICE_MCC_BCN_INTERVAL_CHANGE -
WMI_SERVICE_ADAPTIVE_OCS -
WMI_SERVICE_BA_SSN_SUPPORT -
WMI_SERVICE_FILTER_IPSEC_NATKEEPALIVE -
WMI_SERVICE_WLAN_HB -
WMI_SERVICE_LTE_ANT_SHARE_SUPPORT -
WMI_SERVICE_BATCH_SCAN -
WMI_SERVICE_QPOWER -
WMI_SERVICE_PLMREQ -
WMI_SERVICE_THERMAL_MGMT -
WMI_SERVICE_RMC -
WMI_SERVICE_MHF_OFFLOAD -
WMI_SERVICE_COEX_SAR -
WMI_SERVICE_BCN_TXRATE_OVERRIDE -
WMI_SERVICE_NAN -
WMI_SERVICE_L1SS_STAT -
WMI_SERVICE_ESTIMATE_LINKSPEED -
WMI_SERVICE_OBSS_SCAN -
WMI_SERVICE_TDLS_OFFCHAN -
WMI_SERVICE_TDLS_UAPSD_BUFFER_STA -
WMI_SERVICE_TDLS_UAPSD_SLEEP_STA -
WMI_SERVICE_IBSS_PWRSAVE -
WMI_SERVICE_LPASS -
WMI_SERVICE_EXTSCAN -
WMI_SERVICE_D0WOW -
WMI_SERVICE_HSOFFLOAD -
WMI_SERVICE_ROAM_HO_OFFLOAD -
WMI_SERVICE_RX_FULL_REORDER -
WMI_SERVICE_DHCP_OFFLOAD -
WMI_SERVICE_STA_RX_IPA_OFFLOAD_SUPPORT -
WMI_SERVICE_MDNS_OFFLOAD -
WMI_SERVICE_SAP_AUTH_OFFLOAD -
WMI_SERVICE_ATF enabled
WMI_SERVICE_COEX_GPIO enabled
WMI_SERVICE_ENHANCED_PROXY_STA enabled
WMI_SERVICE_TT enabled
WMI_SERVICE_PEER_CACHING enabled
WMI_SERVICE_AUX_SPECTRAL_INTF -
WMI_SERVICE_AUX_CHAN_LOAD_INTF -
WMI_SERVICE_BSS_CHANNEL_INFO_64 enabled
WMI_SERVICE_EXT_RES_CFG_SUPPORT enabled
WMI_SERVICE_MESH_11S enabled
WMI_SERVICE_MESH_NON_11S enabled
WMI_SERVICE_PEER_STATS enabled
WMI_SERVICE_RESTRT_CHNL_SUPPORT -
WMI_SERVICE_PERIODIC_CHAN_STAT_SUPPORT enabled
WMI_SERVICE_TX_MODE_PUSH_ONLY enabled
WMI_SERVICE_TX_MODE_PUSH_PULL enabled
WMI_SERVICE_TX_MODE_DYNAMIC enabled
WMI_SERVICE_VDEV_RX_FILTER enabled
WMI_SERVICE_BTCOEX enabled
WMI_SERVICE_CHECK_CAL_VERSION enabled
WMI_SERVICE_DBGLOG_WARN2 -
WMI_SERVICE_BTCOEX_DUTY_CYCLE enabled
WMI_SERVICE_4_WIRE_COEX_SUPPORT enabled
WMI_SERVICE_EXTENDED_NSS_SUPPORT enabled
WMI_SERVICE_PROG_GPIO_BAND_SELECT enabled
WMI_SERVICE_SMART_LOGGING_SUPPORT enabled
WMI_SERVICE_TDLS_CONN_TRACKER_IN_HOST_MODE -
WMI_SERVICE_TDLS_EXPLICIT_MODE_ONLY -
WMI_SERVICE_MGMT_TX_WMI -
WMI_SERVICE_TDLS_WIDER_BANDWIDTH -
WMI_SERVICE_HTT_MGMT_TX_COMP_VALID_FLAGS enabled
WMI_SERVICE_HOST_DFS_CHECK_SUPPORT enabled
WMI_SERVICE_TPC_STATS_FINAL enabled
WMI_SERVICE_RESET_CHIP -
WMI_SERVICE_SPOOF_MAC_SUPPORT -
WMI_SERVICE_TX_DATA_ACK_RSSI -
WMI_SERVICE_VDEV_DIFFERENT_BEACON_INTERVAL_SUPPORT -
WMI_SERVICE_VDEV_DISABLE_4_ADDR_SRC_LRN_SUPPORT -
WMI_SERVICE_BB_TIMING_CONFIG_SUPPORT -
WMI_SERVICE_THERM_THROT enabled
WMI_SERVICE_RTT_RESPONDER_ROLE -
WMI_SERVICE_PER_PACKET_SW_ENCRYPT enabled
WMI_SERVICE_REPORT_AIRTIME -
WMI_SERVICE_SYNC_DELETE_CMDS -
WMI_SERVICE_TX_PWR_PER_PEER -
WMI_SERVICE_SUPPORT_EXTEND_ADDRESS -
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-02 10:12 ` Sven Eckelmann
@ 2021-02-02 13:27 ` Ben Greear
2021-02-02 13:57 ` Sven Eckelmann
0 siblings, 1 reply; 14+ messages in thread
From: Ben Greear @ 2021-02-02 13:27 UTC (permalink / raw)
To: Sven Eckelmann, ath10k, Sebastian Gottschall
On 2/2/21 2:12 AM, Sven Eckelmann wrote:
> On Tuesday, 2 February 2021 10:12:45 CET Sebastian Gottschall wrote:
>> mmh. l have a idea
>>
>> try the following (this a patch in my tree) and check also the wmi
>> services for this service flag which might be a difference between these
>> firmwares
>>
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -9003,10 +9003,10 @@ int ath10k_mac_register(struct ath10k *ar)
> [...]
>
> Thanks, for the idea. But this has no effect on the problem. I have also
> attached the services and feature information (from ath10k-ct's perspective to
> have hopefully a more complete look at the differences). And it seems both
> have WMI_SERVICE_PER_PACKET_SW_ENCRYPT and Ben's firmware also
> ATH10K_FW_FEATURE_CONSUME_BLOCK_ACK_CT (which would also have "enabled" this
> code section).
>
> The biggest difference (which would affect also the non-ct ath10k) would be in
> wmi_services. Ben Greears firmware doesnt support:
>
> * WMI_SERVICE_PEER_CACHING
> * WMI_SERVICE_HTT_MGMT_TX_COMP_VALID_FLAGS
> * WMI_SERVICE_HOST_DFS_CHECK_SUPPORT
> * WMI_SERVICE_TPC_STATS_FINAL
Sven, I can build you a series of firmware if you have interest in bisecting to see if
this is a regression?
I'll get started on the builds, looks like last time I did a full build of 4019
commits was a while back...
Thanks,
Ben
>
> Kind regards,
> Sven
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-02 13:27 ` Ben Greear
@ 2021-02-02 13:57 ` Sven Eckelmann
2021-02-07 16:50 ` Ben Greear
0 siblings, 1 reply; 14+ messages in thread
From: Sven Eckelmann @ 2021-02-02 13:57 UTC (permalink / raw)
To: ath10k; +Cc: Ben Greear, Sebastian Gottschall
[-- Attachment #1.1: Type: text/plain, Size: 388 bytes --]
On Tuesday, 2 February 2021 14:27:01 CET Ben Greear wrote:
> Sven, I can build you a series of firmware if you have interest in bisecting to see if
> this is a regression?
If it is ok for you then I can go through various firmware builds. But it
could be that I can only start with the bisect at the end of the week. At
least today, I will have no time after work.
Kind regards,
Sven
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-02 13:57 ` Sven Eckelmann
@ 2021-02-07 16:50 ` Ben Greear
2021-02-07 17:13 ` Sven Eckelmann
0 siblings, 1 reply; 14+ messages in thread
From: Ben Greear @ 2021-02-07 16:50 UTC (permalink / raw)
To: Sven Eckelmann, ath10k; +Cc: Sebastian Gottschall
On 2/2/21 5:57 AM, Sven Eckelmann wrote:
> On Tuesday, 2 February 2021 14:27:01 CET Ben Greear wrote:
>> Sven, I can build you a series of firmware if you have interest in bisecting to see if
>> this is a regression?
>
> If it is ok for you then I can go through various firmware builds. But it
> could be that I can only start with the bisect at the end of the week. At
> least today, I will have no time after work.
>
> Kind regards,
> Sven
>
Here are the images:
http://www.candelatech.com/downloads/ath10k-4019-10-4b/bisect/
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-07 16:50 ` Ben Greear
@ 2021-02-07 17:13 ` Sven Eckelmann
2021-02-07 17:42 ` Ben Greear
0 siblings, 1 reply; 14+ messages in thread
From: Sven Eckelmann @ 2021-02-07 17:13 UTC (permalink / raw)
To: ath10k, Ben Greear; +Cc: Sebastian Gottschall
[-- Attachment #1.1: Type: text/plain, Size: 713 bytes --]
On Sunday, 7 February 2021 17:50:11 CET Ben Greear wrote:
> Here are the images:
>
> http://www.candelatech.com/downloads/ath10k-4019-10-4b/bisect/
Thanks, will try to have look at them tomorrow evening. Can you confirm which
QCA ath10k version was used as the base for this one? I've read somewhere on
your page 10.4.3.3-25 - which doesn't seem to be in Kalles' repository. And my
original plan was to test the relevant QCA firmware first and check if the
problem might already be in the base version which you've used for your
builds. But maybe I will just start with the oldest one in you tree and check
if the problem is also there and based on the result decide how to continue.
Kind regards,
Sven
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-07 17:13 ` Sven Eckelmann
@ 2021-02-07 17:42 ` Ben Greear
2021-02-08 20:32 ` Sven Eckelmann
0 siblings, 1 reply; 14+ messages in thread
From: Ben Greear @ 2021-02-07 17:42 UTC (permalink / raw)
To: Sven Eckelmann, ath10k; +Cc: Sebastian Gottschall
On 2/7/21 9:13 AM, Sven Eckelmann wrote:
> On Sunday, 7 February 2021 17:50:11 CET Ben Greear wrote:
>> Here are the images:
>>
>> http://www.candelatech.com/downloads/ath10k-4019-10-4b/bisect/
>
> Thanks, will try to have look at them tomorrow evening. Can you confirm which
> QCA ath10k version was used as the base for this one? I've read somewhere on
> your page 10.4.3.3-25 - which doesn't seem to be in Kalles' repository. And my
> original plan was to test the relevant QCA firmware first and check if the
> problem might already be in the base version which you've used for your
> builds. But maybe I will just start with the oldest one in you tree and check
> if the problem is also there and based on the result decide how to continue.
I don't know exactly how qca versioning works, but my notes are that the initial
upstream wave-2 code was 3.5.3-00050, from back in 2018.
The first commit in the series should be very similar to stock FW, though perhaps
missing some feature flags. Maybe try forcing the driver to try to allow
vlans...if it is missing feature flag only, that might work around it.
Somewhere along the way I fixed up raw transmit in my firmware, so possibly
only then will vlans really have a chance of working.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-07 17:42 ` Ben Greear
@ 2021-02-08 20:32 ` Sven Eckelmann
2021-02-08 20:50 ` Ben Greear
0 siblings, 1 reply; 14+ messages in thread
From: Sven Eckelmann @ 2021-02-08 20:32 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k
[-- Attachment #1.1: Type: text/plain, Size: 6076 bytes --]
On Sunday, 7 February 2021 18:42:42 CET Ben Greear wrote:
> Somewhere along the way I fixed up raw transmit in my firmware, so possibly
> only then will vlans really have a chance of working.
The first step was to disable the check which enables AP_VLAN conditional and
just enable it all the time.
I've started testing with firmware-5-full-community-commit-0317-cf4991294.bin
but it doesn't provide the raw support + per packet swcrypto. So I've tried to
switch to firmware-5-full-community-commit-1187-774502ee5.bin but it has
exactly the same with the raw mode - but at least advertises
WMI_SERVICE_PER_PACKET_SW_ENCRYPT.
So my first target was to figure out what was the first firmware with
WMI_SERVICE_PER_PACKET_SW_ENCRYPT. So you would guess that bisect would be
suitable for this - but no, the first step directly found a crashing version.
I should not complain so much -- just have to skip more and have no extra test
results regarding the mcast support for them. Here is the log until I found the
first one which is supposed to support WMI_SERVICE_PER_PACKET_SW_ENCRYPT:
# has_sw_encrypt: firmware-5-full-community-commit-1187-774502ee5.bin
# no_sw_encrypt: firmware-5-full-community-commit-0317-cf4991294.bin
# skip: firmware-5-full-community-commit-0775-bb7462f22.bin
# skip: firmware-5-full-community-commit-0782-c66b3495b.bin
# no_sw_encrypt: firmware-5-full-community-commit-0533-4597878a6.bin
# no_sw_encrypt: firmware-5-full-community-commit-0885-2d9cfe00b.bin
# no_sw_encrypt: firmware-5-full-community-commit-1045-817be3ee8.bin
# has_sw_encrypt: firmware-5-full-community-commit-1112-68b46f73e.bin
# no_sw_encrypt: firmware-5-full-community-commit-1077-44c74a25a.bin
# has_sw_encrypt: firmware-5-full-community-commit-1093-3c7065550.bin
# no_sw_encrypt: firmware-5-full-community-commit-1085-c1d37213a.bin
# no_sw_encrypt: firmware-5-full-community-commit-1089-1fbfebf26.bin
# has_sw_encrypt: firmware-5-full-community-commit-1091-3aa26dbdd.bin
# no_sw_encrypt: firmware-5-full-community-commit-1090-7cfbf3e6a.bin
# first has_sw_encrypt commit: firmware-5-full-community-commit-1091-3aa26dbdd.bin
None of the firmware version seem to have working multicast tx.
And here are some (not so random) picked ones (just so nobody can say that I
didn't check in the other direction):
# no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0425-a422b044f.bin
# no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0371-157623ac0.bin
# no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0344-8b9e4442a.bin
# no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0331-5259fada9.bin
# no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0324-e6723f0f6.bin
# no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0321-814d9dc06.bin
# no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0319-ef95e743e.bin
# no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0318-51cd44bdd.bin
I didn't do a complete sweep of the builds but at the moment it looks a
little bit like there might not be a single one which supports multicast over
this setup. If you think there is a specific firmware version which I should
test then just say which version.
So I've decided to try the ath10k firmware blobs from Kalle's repository to
provide at least something useful for someone who also has this problem
and searches for a compatible version:
firmware blob | works | PER_PACKET_SW_ENCRYPT
----------------------------------------------+-------+----------------------
3.2/firmware-5.bin_10.4-3.2-00080 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00004 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00005 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00007 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00015 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00018 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00023 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00024 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00026 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00028 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00029 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00031 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00033 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00037 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00042 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00044 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00047 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00050 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00051 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00053 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00058 | N | N
3.2.1/firmware-5.bin_10.4-3.2.1-00060 | N | N
3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00009 | N | N
3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00017 | N | N
3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00019 | N | N
3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00021 | N | N
3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00022 | N | N
3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00025 | N | N
3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00028 | N | N
3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00031 | N | N
3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00032 | N | N
3.4/firmware-5.bin_10.4-3.4-00074 | N | N
3.4/firmware-5.bin_10.4-3.4-00082 | N | N
3.4/firmware-5.bin_10.4-3.4-00104 | N | N
3.5.3/firmware-5.bin_10.4-3.5.3-00053 | N | N
3.5.3/firmware-5.bin_10.4-3.5.3-00057 | Y | Y
3.5.3/firmware-5.bin_10.4-3.5.3-00078 | Y | Y
3.6/firmware-5.bin_10.4-3.6-00140 | Y | Y
Kind regards,
Sven
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 146 bytes --]
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: EAP AP/VLAN: multicast not send to client
2021-02-08 20:32 ` Sven Eckelmann
@ 2021-02-08 20:50 ` Ben Greear
0 siblings, 0 replies; 14+ messages in thread
From: Ben Greear @ 2021-02-08 20:50 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: ath10k
On 2/8/21 12:32 PM, Sven Eckelmann wrote:
> On Sunday, 7 February 2021 18:42:42 CET Ben Greear wrote:
>> Somewhere along the way I fixed up raw transmit in my firmware, so possibly
>> only then will vlans really have a chance of working.
>
> The first step was to disable the check which enables AP_VLAN conditional and
> just enable it all the time.
I appreciate the work you put into this. Looks like it is at least not a regression
in code that I added, but I guess I'll need to fix whatever bug/feature upstream
added to get it working.
I think I'll have a way to set up a testbed for this sometime soon, as part
of work on another project, so I'll try to debug it then.
Thanks,
Ben
>
> I've started testing with firmware-5-full-community-commit-0317-cf4991294.bin
> but it doesn't provide the raw support + per packet swcrypto. So I've tried to
> switch to firmware-5-full-community-commit-1187-774502ee5.bin but it has
> exactly the same with the raw mode - but at least advertises
> WMI_SERVICE_PER_PACKET_SW_ENCRYPT.
>
> So my first target was to figure out what was the first firmware with
> WMI_SERVICE_PER_PACKET_SW_ENCRYPT. So you would guess that bisect would be
> suitable for this - but no, the first step directly found a crashing version.
> I should not complain so much -- just have to skip more and have no extra test
> results regarding the mcast support for them. Here is the log until I found the
> first one which is supposed to support WMI_SERVICE_PER_PACKET_SW_ENCRYPT:
>
> # has_sw_encrypt: firmware-5-full-community-commit-1187-774502ee5.bin
> # no_sw_encrypt: firmware-5-full-community-commit-0317-cf4991294.bin
> # skip: firmware-5-full-community-commit-0775-bb7462f22.bin
> # skip: firmware-5-full-community-commit-0782-c66b3495b.bin
> # no_sw_encrypt: firmware-5-full-community-commit-0533-4597878a6.bin
> # no_sw_encrypt: firmware-5-full-community-commit-0885-2d9cfe00b.bin
> # no_sw_encrypt: firmware-5-full-community-commit-1045-817be3ee8.bin
> # has_sw_encrypt: firmware-5-full-community-commit-1112-68b46f73e.bin
> # no_sw_encrypt: firmware-5-full-community-commit-1077-44c74a25a.bin
> # has_sw_encrypt: firmware-5-full-community-commit-1093-3c7065550.bin
> # no_sw_encrypt: firmware-5-full-community-commit-1085-c1d37213a.bin
> # no_sw_encrypt: firmware-5-full-community-commit-1089-1fbfebf26.bin
> # has_sw_encrypt: firmware-5-full-community-commit-1091-3aa26dbdd.bin
> # no_sw_encrypt: firmware-5-full-community-commit-1090-7cfbf3e6a.bin
> # first has_sw_encrypt commit: firmware-5-full-community-commit-1091-3aa26dbdd.bin
>
> None of the firmware version seem to have working multicast tx.
>
>
> And here are some (not so random) picked ones (just so nobody can say that I
> didn't check in the other direction):
>
> # no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0425-a422b044f.bin
> # no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0371-157623ac0.bin
> # no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0344-8b9e4442a.bin
> # no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0331-5259fada9.bin
> # no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0324-e6723f0f6.bin
> # no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0321-814d9dc06.bin
> # no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0319-ef95e743e.bin
> # no_per_patcket_sw_encrypt_no_mcast: firmware-5-full-community-commit-0318-51cd44bdd.bin
>
> I didn't do a complete sweep of the builds but at the moment it looks a
> little bit like there might not be a single one which supports multicast over
> this setup. If you think there is a specific firmware version which I should
> test then just say which version.
>
> So I've decided to try the ath10k firmware blobs from Kalle's repository to
> provide at least something useful for someone who also has this problem
> and searches for a compatible version:
>
> firmware blob | works | PER_PACKET_SW_ENCRYPT
> ----------------------------------------------+-------+----------------------
> 3.2/firmware-5.bin_10.4-3.2-00080 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00004 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00005 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00007 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00015 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00018 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00023 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00024 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00026 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00028 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00029 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00031 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00033 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00037 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00042 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00044 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00047 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00050 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00051 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00053 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00058 | N | N
> 3.2.1/firmware-5.bin_10.4-3.2.1-00060 | N | N
> 3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00009 | N | N
> 3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00017 | N | N
> 3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00019 | N | N
> 3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00021 | N | N
> 3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00022 | N | N
> 3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00025 | N | N
> 3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00028 | N | N
> 3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00031 | N | N
> 3.2.1.1/firmware-5.bin_10.4-3.2.1.1-00032 | N | N
> 3.4/firmware-5.bin_10.4-3.4-00074 | N | N
> 3.4/firmware-5.bin_10.4-3.4-00082 | N | N
> 3.4/firmware-5.bin_10.4-3.4-00104 | N | N
> 3.5.3/firmware-5.bin_10.4-3.5.3-00053 | N | N
> 3.5.3/firmware-5.bin_10.4-3.5.3-00057 | Y | Y
> 3.5.3/firmware-5.bin_10.4-3.5.3-00078 | Y | Y
> 3.6/firmware-5.bin_10.4-3.6-00140 | Y | Y
>
> Kind regards,
> Sven
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-02-08 20:50 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-01 20:54 EAP AP/VLAN: multicast not send to client Sven Eckelmann
2021-02-02 7:04 ` Sebastian Gottschall
2021-02-02 8:23 ` Sven Eckelmann
2021-02-02 8:58 ` Sebastian Gottschall
2021-02-02 9:06 ` Sven Eckelmann
2021-02-02 9:12 ` Sebastian Gottschall
2021-02-02 10:12 ` Sven Eckelmann
2021-02-02 13:27 ` Ben Greear
2021-02-02 13:57 ` Sven Eckelmann
2021-02-07 16:50 ` Ben Greear
2021-02-07 17:13 ` Sven Eckelmann
2021-02-07 17:42 ` Ben Greear
2021-02-08 20:32 ` Sven Eckelmann
2021-02-08 20:50 ` Ben Greear
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).