Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 5月, 2021 5 次提交
  3. 04 2月, 2021 1 次提交
  5. 07 11月, 2020 1 次提交
  7. 18 8月, 2020 1 次提交
  9. 17 8月, 2020 1 次提交
  11. 21 7月, 2020 1 次提交
    • Z
      ath10k: check idx validity in __ath10k_htt_rx_ring_fill_n() · bad60b8d
      由 Zekun Shen 提交于 
      The idx in __ath10k_htt_rx_ring_fill_n function lives in
consistent dma region writable by the device. Malfunctional
or malicious device could manipulate such idx to have a OOB
write. Either by
    htt->rx_ring.netbufs_ring[idx] = skb;
or by
    ath10k_htt_set_paddrs_ring(htt, paddr, idx);

The idx can also be negative as it's signed, giving a large
memory space to write to.

It's possibly exploitable by corruptting a legit pointer with
a skb pointer. And then fill skb with payload as rougue object.

Part of the log here. Sometimes it appears as UAF when writing
to a freed memory by chance.

 [   15.594376] BUG: unable to handle page fault for address: ffff887f5c1804f0
 [   15.595483] #PF: supervisor write access in kernel mode
 [   15.596250] #PF: error_code(0x0002) - not-present page
 [   15.597013] PGD 0 P4D 0
 [   15.597395] Oops: 0002 [#1] SMP KASAN PTI
 [   15.597967] CPU: 0 PID: 82 Comm: kworker/u2:2 Not tainted 5.6.0 #69
 [   15.598843] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
 BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
 [   15.600438] Workqueue: ath10k_wq ath10k_core_register_work [ath10k_core]
 [   15.601389] RIP: 0010:__ath10k_htt_rx_ring_fill_n
 (linux/drivers/net/wireless/ath/ath10k/htt_rx.c:173) ath10k_core
Signed-off-by: NZekun Shen <bruceshenzk@gmail.com>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200623221105.3486-1-bruceshenzk@gmail.com
      bad60b8d
  13. 16 6月, 2020 1 次提交
  15. 27 4月, 2020 1 次提交
    • W
      ath10k: add statistics of tx retries and tx failed when tx complete disable · 59a022cc
      由 Wen Gong 提交于 
      When tx complete is disabled, all tx status will be set with status
HTT_TX_COMPL_STATE_ACK and indicate to mac80211 by ieee80211_tx_status,
then it does not have the statistics for retries and failed packets.
count of tx retries and tx failed of command "iw wlan0 station dump"
are both 0. If tx complete is not disabled, then firmware report the
tx status and ath10k indicate the status to mac80211, then mac80211
save the statistics and command "iw wlan0 station dump" show them.

for example:
localhost ~ # iw dev wlan0 station dump
Station 3c:28:6d:96:fd:69 (on wlan0)
	inactive time:	5 ms
	rx bytes:	1325012
	rx packets:	6477
	tx bytes:	85264
	tx packets:	518
	tx retries:	0
	tx failed:	0

This patch only effect chips with tx complete disabled, e.g. SDIO.

with this patch, output of command "iw dev wlan0 station dump":
Station c4:04:15:5d:97:22 (on wlan0)
        inactive time:  608 ms
        rx bytes:       180366
        rx packets:     991
        tx bytes:       98765577
        tx packets:     64624
        tx retries:     14682
        tx failed:      47086

Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00042.
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200423024134.10601-1-wgong@codeaurora.org
      59a022cc
  17. 22 4月, 2020 1 次提交
    • W
      ath10k: add htt TX bundle for sdio · c8334512
      由 Wen Gong 提交于 
      The transmission utilization ratio for sdio bus for small packet is
slow, because the space and time cost for sdio bus is same for large
length packet and small length packet. So the speed of data for large
length packet is higher than small length.

Test result of different length of data:

data packet(byte)   cost time(us)   calculated rate(Mbps)
      256               28                73
      512               33               124
     1024               35               234
     1792               45               318
    14336              168               682
    28672              333               688
    57344              660               695

This patch change the TX packet from single packet to a large length
bundle packet, max size is 32, it results in significant performance
improvement on TX path.

Also there's a fourth thread "ath10k_tx_complete_wq" added to ath10k as it
improves TCP RX throughput (values in Mbps):

                                       TCP-RX    TCP-TX    UDP-RX      UDP-TX
use workqueue_tx_complete              423       357       448         412
change it to ar->workqueue             410       360       449         414
change it to ar->workqueue_aux         405       339       446         401

This patch only effect sdio chip, it will not effect PCI, SNOC etc.
It only enable bundle for sdio chip.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00017-QCARMSWP-1.
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200410061400.14231-2-wgong@codeaurora.org
      c8334512
  19. 09 4月, 2020 1 次提交
    • W
      ath10k: disable TX complete indication of htt for sdio · d81686d3
      由 Wen Gong 提交于 
      For sdio chip, it is high latency bus, all the TX packet's content will
be tranferred from HOST memory to firmware memory via sdio bus, then it
need much more memory in firmware than low latency bus chip, for low
latency chip, such as PCI-E, it only need to transfer the TX descriptor
via PCI-E bus to firmware memory. For sdio chip, reduce the complexity of
TX logic will help TX efficiency since its memory is limited, and it will
reduce the TX circle's time of each packet and then firmware will have more
memory for TX since TX complete also need memeory.

This patch disable TX complete indication from firmware for htt data
packet, it will not have TX complete indication from firmware to ath10k.
It will cut the cost of bus bandwidth of TX complete and make the TX
logic of firmware simpler, it results in significant performance
improvement on TX path.

Udp TX throughout is 130Mbps without this patch, and it arrives
400Mbps with this patch.

The downside of this patch is the command "iw wlan0 station dump" will
show 0 for "tx retries" and "tx failed" since all tx packet's status
is success.

This patch only effect sdio chip, it will not effect PCI, SNOC etc.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00017-QCARMSWPZ-1
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200212080415.31265-2-wgong@codeaurora.org
      d81686d3
  21. 12 3月, 2020 1 次提交
  23. 26 1月, 2020 1 次提交
  25. 02 12月, 2019 1 次提交
    • W
      ath10k: enable napi on RX path for sdio · cfee8793
      由 Wen Gong 提交于 
      For tcp RX, the quantity of tcp acks to remote is 1/2 of the quantity
of tcp data from remote, then it will have many small length packets
on TX path of sdio bus, then it reduce the RX packets's bandwidth of
tcp.

This patch enable napi on RX path, then the RX packet of tcp will not
feed to tcp stack immeditely from mac80211 since GRO is enabled by
default, it will feed to tcp stack after napi complete, if rx bundle
is enabled, then it will feed to tcp stack one time for each bundle
of RX. For example, RX bundle size is 32, then tcp stack will receive
one large length packet, its length is neary 1500*32, then tcp stack
will send a tcp ack for this large packet, this will reduce the tcp
acks ratio from 1/2 to 1/32. This results in significant performance
improvement for tcp RX.

Tcp rx throughout is 240Mbps without this patch, and it arrive 390Mbps
with this patch. The cpu usage has no obvious difference with and
without NAPI.

call stack for each RX packet on GRO path:
(skb length is about 1500 bytes)
  skb_gro_receive ([kernel.kallsyms])
  tcp4_gro_receive ([kernel.kallsyms])
  inet_gro_receive ([kernel.kallsyms])
  dev_gro_receive ([kernel.kallsyms])
  napi_gro_receive ([kernel.kallsyms])
  ieee80211_deliver_skb ([mac80211])
  ieee80211_rx_handlers ([mac80211])
  ieee80211_prepare_and_rx_handle ([mac80211])
  ieee80211_rx_napi ([mac80211])
  ath10k_htt_rx_proc_rx_ind_hl ([ath10k_core])
  ath10k_htt_rx_pktlog_completion_handler ([ath10k_core])
  ath10k_sdio_napi_poll ([ath10k_sdio])
  net_rx_action ([kernel.kallsyms])
  softirqentry_text_start ([kernel.kallsyms])
  do_softirq ([kernel.kallsyms])

call stack for napi complete and send tcp ack from tcp stack:
(skb length is about 1500*32 bytes)
 _tcp_ack_snd_check ([kernel.kallsyms])
 tcp_v4_do_rcv ([kernel.kallsyms])
 tcp_v4_rcv ([kernel.kallsyms])
 local_deliver_finish ([kernel.kallsyms])
 ip_local_deliver ([kernel.kallsyms])
 ip_rcv_finish ([kernel.kallsyms])
 ip_rcv ([kernel.kallsyms])
 netif_receive_skb_core ([kernel.kallsyms])
 netif_receive_skb_one_core([kernel.kallsyms])
 netif_receive_skb ([kernel.kallsyms])
 netif_receive_skb_internal ([kernel.kallsyms])
 napi_gro_complete ([kernel.kallsyms])
 napi_gro_flush ([kernel.kallsyms])
 napi_complete_done ([kernel.kallsyms])
 ath10k_sdio_napi_poll ([ath10k_sdio])
 net_rx_action ([kernel.kallsyms])
 __softirqentry_text_start ([kernel.kallsyms])
 do_softirq ([kernel.kallsyms])

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00017-QCARMSWP-1.
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      cfee8793
  27. 29 11月, 2019 1 次提交
  29. 25 11月, 2019 3 次提交
    • L
      ath10k: fix RX of frames with broken FCS in monitor mode · ea0c3e2a
      由 Linus Lüssing 提交于 
      So far, frames were forwarded regardless of the FCS correctness leading
to userspace applications listening on the monitor mode interface to
receive potentially broken frames, even with the "fcsfail" flag unset.

By default, with the "fcsfail" flag of a monitor mode interface
unset, frames with FCS errors should be dropped. With this patch, the
fcsfail flag is taken into account correctly.

Tested-on: QCA4019 firmware-5-ct-full-community-12.bin-lede.011

Cc: Simon Wunderlich <sw@simonwunderlich.de>
Signed-off-by: NLinus Lüssing <ll@simonwunderlich.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      ea0c3e2a
    • W
      ath10k: report rssi of each chain to mac80211 for sdio · 7005eafc
      由 Wen Gong 提交于 
      iw command only show rssi without each chain's rssi on sdio
iw wlan0 station dump
Station a0:40:a0:93:3e:de (on wlan0)
signal:         -82 dBm
signal avg:     -82 dBm

after this patch, it will show each chain's rssi on sdio
Station a0:40:a0:93:3e:de (on wlan0)
signal:         -82 [-84, -88] dBm
signal avg:     -82 [-84, -87] dBm

For QCA6174 PCIe, the ppdu have the correct rssi of each chain, it
indicate rssi of rx data by ath10k_htt_rx_h_signal. For sdio chip, the
rssi of each chain stored in rx management reported by firmware, the
ath10k_wmi_tlv_op_pull_mgmt_rx_ev which used for tlv wmi will get the
rssi of each chain and stored them in wmi_mgmt_rx_ev_arg, then indicate
them to mac80211. For non-tlv wmi chip, it will not get the rssi of each
chain and not indicate to mac80211, for non-tlv wmi chip, this patch will
not have impact. For tlv wmi chip, if the rssi of chain in mgmt is valid,
it will be indicate to mac80211, tested with QCA6174 PCIe/SDIO, the rssi
of 2 chain in mgmt is valid.

rssi of chains in mgmt of QCA6174 SDIO:
92096.652780: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[0]:70
92096.657324: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[1]:68
92096.662009: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[2]:128
92096.666647: ath10k:ath10k_log_warn: ath10k_sdio mmc1:0001:1 rssi[3]:128

rssi of chains in mgmt of QCA6174 PCIe:
[ 1581.049816] ath10k_pci 0000:02:00.0: mgmt rssi[0]:17
[ 1581.049818] ath10k_pci 0000:02:00.0: mgmt rssi[1]:22
[ 1581.049821] ath10k_pci 0000:02:00.0: mgmt rssi[2]:128
[ 1581.049823] ath10k_pci 0000:02:00.0: mgmt rssi[3]:128

after apply this patch, the iw's rssi of PCIe do not changed, result is
same with before.

iw wlan0 station dump of QCA6174 PCIe:
Station 6c:e8:73:b8:92:dc (on wlan0)
        signal:         -70 [-77, -72] dBm
        signal avg:     -69 [-78, -72] dBm

iw wlan-5000mhz station dump of QCA9984 PCIe
connected with 2 client which has 2 chain:
Station 70:48:0f:1f:1a:b2 (on wlan-5000mhz)
        signal:         -47 [-55, -48, -87, -88] dBm
        signal avg:     -42 [-50, -43, -83, -86] dBm
Station ac:c1:ee:39:e3:83 (on wlan-5000mhz)
        signal:         -43 [-46, -45, -79, -84] dBm
        signal avg:     -43 [-46, -46, -82, -83] dBm

Tested with QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00017-QCARMSWP-1.
Tested with QCA6174 PCIe with firmware WLAN.RM.4.4.1-00110-QCARMSWP-1.
Tested with QCA9984 PCIe with firmware 10.4-3.9.0.2-00040.
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      7005eafc
    • W
      ath10k: add workqueue for RX path of sdio · 67654b26
      由 Wen Gong 提交于 
      For RX, it has two parts, one is to read data from sdio, another
is to indicate the packets to upper stack. Recently it has only
one thread to do all RX things, it results that it is sequential
for RX and low throughout, change RX to parallel for the two parts
will increase throughout.

This patch move the indication to a workqueue, it results in
significant performance improvement on RX path.

Udp rx throughout is 200Mbps without this patch, and it arrives
400Mbps with this patch.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00017-QCARMSWPZ-1
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      67654b26
  31. 31 10月, 2019 1 次提交
  33. 17 9月, 2019 1 次提交
    • H
      ath10k: Check if station exists before forwarding tx airtime report · b10f3267
      由 Hauke Mehrtens 提交于 
      It looks like the FW on QCA9984 already reports the tx airtimes before
the station is added to the peer entry. The peer entry is created in
ath10k_peer_map_event() just with the vdev_id and the ethaddr, but
not with a station entry, this is added later in ath10k_peer_create() in
callbacks from mac80211.

When there is no sta added to the peer entry, this function fails
because it calls ieee80211_sta_register_airtime() with NULL.

This was reported in OpenWrt some time ago:
https://bugs.openwrt.org/index.php?do=details&task_id=2414

This commit should fix this crash:
[   75.991714] Unable to handle kernel paging request at virtual address fffff9e8
[   75.991756] pgd = c0204000
[   75.997955] [fffff9e8] *pgd=5fdfd861, *pte=00000000, *ppte=00000000
[   76.000537] Internal error: Oops: 37 [#1] SMP ARM
[   76.006686] Modules linked in: pppoe ppp_async ath10k_pci ath10k_core ath pptp pppox ppp_mppe ppp_generic mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_tcpmss xt_statistic xt_state xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_HL xt_FLOWOFFLOAD xt_DSCP xt_CT xt_CLASSIFY usbserial slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_netlink iptable_raw iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables crc_ccitt compat chaoskey fuse sch_cake sch_tbf sch_ingress sch_htb sch_hfsc em_u32 cls_u32
[   76.059974]  cls_tcindex cls_route cls_matchall cls_fw cls_flow cls_basic act_skbedit act_mirred ledtrig_usbport xt_set ip_set_list_set ip_set_hash_netportnet ip_set_hash_netport ip_set_hash_netnet ip_set_hash_netiface ip_set_hash_net ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6t_NPT ip6t_MASQUERADE nf_nat_masquerade_ipv6 nf_nat nf_conntrack nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 msdos ip_gre gre ifb sit tunnel4 ip_tunnel tun vfat fat hfsplus cifs nls_utf8 nls_iso8859_15 nls_iso8859_1 nls_cp850 nls_cp437 nls_cp1250 sha1_generic md5 md4
[   76.130634]  usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_of_simple ohci_platform ohci_hcd phy_qcom_dwc3 ahci ehci_platform sd_mod ahci_platform libahci_platform libahci libata scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 exfat crc32c_generic
[   76.154772] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.132 #0
[   76.177001] Hardware name: Generic DT based system
[   76.182990] task: c0b06d80 task.stack: c0b00000
[   76.187832] PC is at ieee80211_sta_register_airtime+0x24/0x148 [mac80211]
[   76.192211] LR is at ath10k_htt_t2h_msg_handler+0x678/0x10f4 [ath10k_core]
[   76.199052] pc : [<bf75bfac>]    lr : [<bf83e8b0>]    psr: a0000113
[   76.205820] sp : c0b01d54  ip : 00000002  fp : bf869c0c
[   76.211981] r10: 0000003c  r9 : dbdca138  r8 : 00060002
[   76.217192] r7 : 00000000  r6 : dabe1150  r5 : 00000000  r4 : dbdc95c0
[   76.222401] r3 : 00000000  r2 : 00060002  r1 : 00000000  r0 : 00000000
[   76.229003] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   76.235509] Control: 10c5787d  Table: 5c94006a  DAC: 00000051
[   76.242716] Process swapper/0 (pid: 0, stack limit = 0xc0b00210)
[   76.248446] Stack: (0xc0b01d54 to 0xc0b02000)
[   76.254532] 1d40:                                              dbdc95c0 00000000 dabe1150
[   76.258808] 1d60: 00000001 dabe1150 dbdca138 0000003c bf869c0c bf83e8b0 00000002 c0314b10
[   76.266969] 1d80: dbdc9c70 00000001 00000001 dabe114c 00010000 00000000 dbdcd724 bf88f3d8
[   76.275126] 1da0: c0310d28 db393c00 dbdc95c0 00000000 c0b01dd0 c07fb4c4 dbdcd724 00000001
[   76.283286] 1dc0: 00000022 bf88b09c db393c00 00000022 c0b01dd0 c0b01dd0 00000000 dbdcc5c0
[   76.291445] 1de0: bf88f04c dbdcd654 dbdcd71c dbdc95c0 00000014 dbdcd724 dbdcc5c0 00000005
[   76.299605] 1e00: 0004b400 bf85c360 00000000 bf87101c c0b01e24 00000006 00000000 dbdc95c0
[   76.307764] 1e20: 00000001 00000040 0000012c c0b01e80 1cf51000 bf85c448 dbdcd440 dbdc95c0
[   76.315925] 1e40: dbdca440 ffffa880 00000040 bf88cb68 dbdcd440 00000001 00000040 ffffa880
[   76.324084] 1e60: c0b02d00 c06d72e0 dd990080 c0a3f080 c0b255dc c0b047e4 c090afac c090e80c
[   76.332244] 1e80: c0b01e80 c0b01e80 c0b01e88 c0b01e88 dd4cc200 00000000 00000003 c0b0208c
[   76.340405] 1ea0: c0b02080 40000003 ffffe000 00000100 c0b02080 c03015c8 00000000 00000001
[   76.348564] 1ec0: dd408000 c0a38210 c0b2c7c0 0000000a ffffa880 c0b02d00 c07fb764 00200102
[   76.356723] 1ee0: dd4cc268 c0a3e414 00000000 00000000 00000001 dd408000 de803000 00000000
[   76.364883] 1f00: 00000000 c03247cc c0a3e414 c0368f1c c0b03f60 c0b153cc de80200c de802000
[   76.373042] 1f20: c0b01f48 c0301488 c0308630 60000013 ffffffff c0b01f7c 00000000 c0b00000
[   76.381204] 1f40: 00000000 c030c08c 00000001 00000000 00000000 c0315180 ffffe000 c0b03cc0
[   76.389363] 1f60: c0b03c70 00000000 00000000 c0a2da28 00000000 00000000 c0b01f90 c0b01f98
[   76.397522] 1f80: c030862c c0308630 60000013 ffffffff 00000051 00000000 ffffe000 c035dd18
[   76.405681] 1fa0: 000000bf c0b03c40 00000000 c0b2c000 dddfce80 c035e060 c0b2c040 c0a00cf4
[   76.413842] 1fc0: ffffffff ffffffff 00000000 c0a0067c c0a2da28 00000000 00000000 c0b2c1d4
[   76.422001] 1fe0: c0b03c5c c0a2da24 c0b07ee0 4220406a 512f04d0 4220807c 00000000 00000000
[   76.430335] [<bf75bfac>] (ieee80211_sta_register_airtime [mac80211]) from [<00000002>] (0x2)
[   76.438314] Code: e1cd81f0 e1a08002 e1cda1f8 e58de020 (e5102618)
[   76.446965] ---[ end trace 227a38ade964d642 ]---

Fixes: bb31b7cb ("ath10k: report tx airtime provided by fw")
Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      b10f3267
  35. 10 9月, 2019 1 次提交
    • W
      ath10k: add reorder and change PN check logic for mac80211 · db8deae0
      由 Wen Gong 提交于 
      For sdio chip, if the rssi is not good, then it have some retry,
firmware will indicate the msdu list of a ppdu with a hole, it
means it lost the hole msdu, after the msdu retry from AP, the
hole msdu will indicate from firmware later. The hole msdu's PN
check will fail and the hole msdu will be dropped.

PN check fail example:
Sequence number PN number  PN check status
     3814         6101         success
     3815         6102         success
     3816         6103         success
     3818         6105         success
     3819         6106         success
     3820         6107         success
     3817         6104         fail

The correct logic is reorder the msdu list and then do PN check.
ieee80211_rx_reorder_ampdu of mac80211 will do the reorer logic
and then do PN check in ieee80211_rx_h_decrypt of mac80211.

example after reorder:
Sequence number PN number  PN check status
     3814         6101         success
     3815         6102         success
     3816         6103         success
     3817         6104         success
     3818         6105         success
     3819         6106         success
     3820         6107         success

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00017-QCARMSWP-1.
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      db8deae0
  37. 29 6月, 2019 1 次提交
  39. 25 6月, 2019 2 次提交
    • W
      ath10k: add report MIC error for sdio chip · 47ed1b4e
      由 Wen Gong 提交于 
      Firmware will report flag with HTT_RX_IND_MPDU_STATUS_TKIP_MIC_ERR
if MIC error, the flag will be used in mac80211.

ieee80211_rx_h_michael_mic_verify will check the flag and start TKIP
countermeasures.

Now countermeasure tests pass both with WPA only and WPA2/WPA mixed
mode.

Tested with QCA6174 SDIO with firmware
WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      47ed1b4e
    • C
      ath10k: acquire lock to fix lockdep's warning · ef9cc0c4
      由 Claire Chang 提交于 
      Lockdep warns at lockdep_assert_held(&ar->data_lock) in
ath10k_htt_rx_pn_check_replay_hl(). Acquire ar->data_lock before calling
ath10k_htt_rx_pn_check_replay_hl() to fix it.

Call trace:
ath10k_htt_rx_pn_check_replay_hl+0x118/0x134 [ath10k_core]
ath10k_htt_rx_proc_rx_ind_hl+0xd8/0x250 [ath10k_core]
ath10k_htt_t2h_msg_handler+0x148/0xf30 [ath10k_core]
ath10k_htt_htc_t2h_msg_handler+0x24/0x40 [ath10k_core]
ath10k_sdio_irq_handler+0x374/0xaa4 [ath10k_sdio]

Fixes: 130c7749 ("ath10k: add PN replay protection for high latency devices")
Signed-off-by: NClaire Chang <tientzu@chromium.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      ef9cc0c4
  41. 07 5月, 2019 2 次提交
  43. 29 4月, 2019 3 次提交
    • W
      ath10k: add fragmentation handler for high latency devices · 33f97472
      由 Wen Gong 提交于 
      On high latency devices (SDIO, USB) ath10k did not handle fragmented frames and
all fragmented frames on receive path were lost in ath10k. Even a simple ping
test failed with fragmentation.

The fragmented packets are decapsulated based on the security mode, then the PN
is checked and the fragmented frame is passed to mac80211.  mac80211 in
ieee80211_rx_h_defragment() will then combine the fragment frames and forward
to upper layers.

Tested on QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      33f97472
    • W
      ath10k: add PN replay protection for high latency devices · 130c7749
      由 Wen Gong 提交于 
      On high latency devices (SDIO, USB) ath10k did not do PN replay check, a data
frame with an invalid PN number was not discard as it should have been. So this
patch implements PN replay in ath10k. PN replay check for fragmented frames is
implemented in followup patch.

With low latency devices (PCI, AHB) hardware can store the data
frames's content to host memory directly and the firmware can fully reorder
data frames, and do PN replay check at the same time. But for high latency
devices all data frames will be received and stored in firmware's memory and it
is hard to do full reorder because of the memory size limitations in the
firmware. This is why the PN replay protections needs to be implemented in host
driver.

Tested on QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      130c7749
    • W
      ath10k: add handler for HTT_T2H_MSG_TYPE_SEC_IND event · 28ce53b6
      由 Wen Gong 提交于 
      Add the handler for HTT_T2H_MSG_TYPE_SEC_IND event from firmware, which stores
PN for replay check implemented in the following patch.

Tested on QCA6174 SDIO with firmware WLAN.RMH.4.4.1-00007-QCARMSWP-1.
Signed-off-by: NWen Gong <wgong@codeaurora.org>
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>
      28ce53b6
  45. 23 4月, 2019 1 次提交
  47. 08 4月, 2019 1 次提交
    • F
      mac80211: make ieee80211_schedule_txq schedule empty TXQs · 2b4a6698
      由 Felix Fietkau 提交于 
      Currently there is no way for the driver to signal to mac80211 that it should
schedule a TXQ even if there are no packets on the mac80211 part of that queue.
This is problematic if the driver has an internal retry queue to deal with
software A-MPDU retry.

This patch changes the behavior of ieee80211_schedule_txq to always schedule
the queue, as its only user (ath9k) seems to expect such behavior already:
it calls this function on tx status and on powersave wakeup whenever its
internal retry queue is not empty.

Also add an extra argument to ieee80211_return_txq to get the same behavior.

This fixes an issue on ath9k where tx queues with packets to retry (and no
new packets in mac80211) would not get serviced.

Fixes: 89cea749 ("ath9k: Switch to mac80211 TXQ scheduling and airtime APIs")
Signed-off-by: NFelix Fietkau <nbd@nbd.name>
Acked-by: NToke Høiland-Jørgensen <toke@redhat.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2b4a6698
  49. 28 2月, 2019 3 次提交
  51. 26 2月, 2019 2 次提交
  53. 20 2月, 2019 1 次提交