* Re: Non-working mwifiex_sdio with SD8897
From: Takashi Iwai @ 2016-12-06 16:48 UTC (permalink / raw)
To: linux-wireless; +Cc: Amitkumar Karwar, Nishant Sarmukadam, Oliver Neukum
In-Reply-To: <s5hvav2wa2e.wl-tiwai@suse.de>
On Fri, 02 Dec 2016 17:49:13 +0100,
Takashi Iwai wrote:
>
> Hi,
>
> we've got an Intel Cherry Trail-based system with Marvell SD8897 chip
> over MMC (sdhci), and WiFi / BT always fails at starting (or better to
> say, it never worked properly).
>
> For avoiding the race between WiFi and BT, I blacklisted btmrvl_sdio,
> so let's concentrate only on mwifiex_sdio now.
>
> At the beginning of the driver loading, it looks fine:
>
> mwifiex_sdio mmc1:0001:1: info: FW download over, size 802164 bytes
> mwifiex_sdio mmc1:0001:1: WLAN FW is active
> mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p77)
> mwifiex_sdio mmc1:0001:1: driver_version = mwifiex 1.0 (15.68.7.p77)
> cfg80211: Regulatory domain changed to country: US
> .....
>
> Then it gets a timeout
>
> mwifiex_sdio mmc1:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0x107, act = 0x0
> mwifiex_sdio mmc1:0001:1: num_data_h2c_failure = 0
> mwifiex_sdio mmc1:0001:1: num_cmd_h2c_failure = 0
> mwifiex_sdio mmc1:0001:1: is_cmd_timedout = 1
> mwifiex_sdio mmc1:0001:1: num_tx_timeout = 0
> mwifiex_sdio mmc1:0001:1: last_cmd_index = 4
> mwifiex_sdio mmc1:0001:1: last_cmd_id: 1e 00 0c 01 1e 00 20 00 07 01
> mwifiex_sdio mmc1:0001:1: last_cmd_act: 00 00 01 00 00 00 08 00 00 00
> mwifiex_sdio mmc1:0001:1: last_cmd_resp_index = 3
> mwifiex_sdio mmc1:0001:1: last_cmd_resp_id: 1e 80 0c 81 1e 80 20 80 20 80
> mwifiex_sdio mmc1:0001:1: last_event_index = 1
> mwifiex_sdio mmc1:0001:1: last_event: 00 00 0b 00 00 00 00 00 00 00
> mwifiex_sdio mmc1:0001:1: data_sent=0 cmd_sent=0
> mwifiex_sdio mmc1:0001:1: ps_mode=1 ps_state=1
> mwifiex_sdio mmc1:0001:1: ===mwifiex driverinfo dump start===
> mwifiex_sdio mmc1:0001:1: info: MWIFIEX VERSION: mwifiex 1.0 (15.68.7.p77)
> mwifiex_sdio mmc1:0001:1: SDIO register dump start
> mwifiex_sdio mmc1:0001:1: SDIO Func0 (0x0-0x9): 43 03 02 02 03 02 00 02 03 00
> mwifiex_sdio mmc1:0001:1: SDIO Func1 (0x0-0xb): 02 ff c3 40 00 00 00 00 ff ff ff ff
> mwifiex_sdio mmc1:0001:1: SDIO Func1: (0x4c) 00 (0x50) 08 (0x54) 07 (0x55) 0c (0x58) 10 (0x59) 00 (0x5c) 00 (0x5d) 00
> mwifiex_sdio mmc1:0001:1: SDIO Func1 (0xc0-0xca): dc fe 6c 00 10 00 3f 36 36 02 20
> mwifiex_sdio mmc1:0001:1: SDIO Func1 (0xc0-0xca): dc fe 76 00 1a 00 3f 36 36 02 20
> mwifiex_sdio mmc1:0001:1: SDIO register dump end
> mwifiex_sdio mmc1:0001:1: ===mwifiex driverinfo dump end===
> mwifiex_sdio mmc1:0001:1: == mwifiex firmware dump start ==
> mwifiex_sdio mmc1:0001:1: Ignore scan. Card removed or firmware in bad state
> mwifiex_sdio mmc1:0001:1: scan failed: -14
> mwifiex_sdio mmc1:0001:1: == mwifiex firmware dump end ==
> mwifiex_sdio mmc1:0001:1: == mwifiex dump information to /sys/class/devcoredump start
> mwifiex_sdio mmc1:0001:1: == mwifiex dump information to /sys/class/devcoredump end
>
> And the reset fails as well:
>
> mwifiex_sdio mmc1:0001:1: info: shutdown mwifiex...
> mwifiex_sdio mmc1:0001:1: PREP_CMD: card is removed
> mmc1: tried to reset card
> mwifiex_sdio mmc1:0001:1: failed to enable function
>
>
> I can give the output with CONFIG_MMC_DEBUG and dyndbg for mwifiex*,
> but the full log is way too big to post, as the system is eMMC and it
> contains lots of noises. In case it helps, the log snippet before the
> timeout is like:
>
> [ 42.367403] mwifiex_sdio mmc1:0001:1: bgscan already stopped!
> [ 42.398871] mmc1: starting CMD53 arg 93000100 flags 000001b5
> [ 42.398880] mmc1: blksz 256 blocks 1 flags 00000100 tsac 1000 ms nsac 0
> [ 42.399136] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.400415] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.401787] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.403044] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.404498] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.405874] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.407192] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.408703] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.410229] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.411464] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.412754] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.414211] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.415365] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.416635] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.417968] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.419163] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.420439] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.421891] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.423206] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.424531] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.425974] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.427268] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.428575] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.429959] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.431153] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.432436] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.433793] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.435034] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.436447] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.437957] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.439244] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.440559] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000020
> [ 42.441993] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000103
> [ 42.442061] mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000
> [ 42.442067] mmc1: 256 bytes transferred: 0
> [ 42.442183] mmc1: starting CMD53 arg 100000b8 flags 000001b5
> [ 42.442189] mmc1: blksz 184 blocks 1 flags 00000200 tsac 1000 ms nsac 0
> [ 42.442217] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000003
> [ 42.442228] mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000
> [ 42.442229] mmc1: 184 bytes transferred: 0
> [ 42.442368] mmc1: starting CMD53 arg 13000100 flags 000001b5
> [ 42.442374] mmc1: blksz 256 blocks 1 flags 00000200 tsac 1000 ms nsac 0
> [ 42.442472] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000003
> [ 42.442483] mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000
> [ 42.442484] mmc1: 256 bytes transferred: 0
> [ 42.442645] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000100
> [ 42.442675] mmc1: starting CMD53 arg 100000b8 flags 000001b5
> [ 42.442681] mmc1: blksz 184 blocks 1 flags 00000200 tsac 1000 ms nsac 0
> [ 42.442804] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000003
> [ 42.442814] mmc1: req done (CMD53): 0: 00002000 00000000 00000000 00000000
> [ 42.442816] mmc1: 184 bytes transferred: 0
> [ 52.447746] mwifiex_sdio mmc1:0001:1: mwifiex_cmd_timeout_func: Timeout cmd id = 0x6, act = 0x3
>
> So there seems really no ack before the timeout.
>
>
> Looking through the web, some earlier bug reports (in year 2014)
> showed the similar problem,
>
> https://bugzilla.kernel.org/show_bug.cgi?id=76111
>
> The bug entry remains opened, so I'm not sure about the situation of
> that bug. Also there are some other hits, but not quite sure whether
> it's the same issue.
>
>
> A few more things to be noted:
>
> - The timeout isn't always 0x107. Sometimes it gets 0xa9.
> - I already tried to set can_ext_scan=false, but it didn't help.
> - The symptom appears on all kernel version from 4.4 to 4.9.
> - Backporting the stuff in mwifiex from linux-next as of today didn't
> help, either.
>
>
> Does anyone have a hint for further debugging?
> Any suggestions appreciated.
Does anyone have an idea how to debug further?
thanks,
Takashi
^ permalink raw reply
* ath10k firmware sends probes on DFS channels without radar detection
From: Jean-Pierre Tosoni @ 2016-12-06 17:02 UTC (permalink / raw)
To: ath10k, linux-wireless; +Cc: Cedric VONCKEN
This follows on the previous discussion
"Client station sends probes on DFS channels"
Problem:
The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
wpa_supplicant do not comply with the norm ETSI/EN 301-893
section 4.7; because they can send probes for 600s when no
AP is around.
Analysis:
The problem seems to lie in the firmware, which regards the presence
of *any* beacon as a proof that the channel is radar-clean for 600s.
This is a wrong hypothesis, since a rogue AP sending fraudulent
beacons should not induce a scrupulous STA in sending illegal probes.
Moreover, the norm (table D.1) sets a time limit of 10s to
shutdown when no AP positively allows the STA to transmit on
the DFS channel.
Status:
- there is no known plan at QCA to fix the issue.
- ath10k firmware is not publicly available for fixes.
- there is no obvious fix working in ath10k.
- the issue does not show up with other mac80211 devices like ath9k.
- wpa_supplicant considers this is a kernel issue [2]
Jean-Pierre Tosoni
> -----Message d'origine-----
> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de
> Jean-Pierre Tosoni
> Envoyé : mercredi 30 novembre 2016 19:04
> À : ath10k@lists.infradead.org
> Objet : Client station sends probes on DFS channels
>
> Hello list,
>
> There is a case where I can see probes on a DFS channel, from a non-
> associated station using ath10k. (note that the problem does not arise
> when using ath9k).
>
> *The setup*
>
> I am using Openwrt, wpa_supplicant and compat-wireless 2016-10-08,
> Card firmware is ath10k_pci: qca988x hw2.0 (0x4100016c, 0x043202ff)
> fw 10.2.4.70-2 api 5 htt-ver 2.1 wmi-op 5 htt-op 2
> cal otp max-sta 128 features no-p2p
> ath10k_pci: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
>
> I am using channel 116, regdom US or FR, where I see no traffic at all
> using wireshark+Airpcap.
> I set wpa_supplicant to scan this channel only for a specific SSID
> "ssid1".
>
> At initial startup of the client device, no probes are going out, which
> is OK.
>
> Then, on another device, I start a hostapd set to channel 116, with a
> different SSID "otherssid" so that the supplicant will not associate.
>
> Shortly (1-2s) after the beacons appear in the air, the client begins to
> Send probe request in the air, which is unexpected, but acceptable since
> the client can infer absence of radars from the presence of beacons.
>
> *The problem*
>
> If I power down the AP, the client continues to send probes for around
> 10 minutes, which is unacceptable since it cannot handle radar detection,
> as it is a slave device in the meaning of ETSI/EN 301-893[1].
>
>
> Some tests I made:
> - I tried to investigate the "beacon hint" mechanism but it appears
> that it is not used on DFS channels.
>
> - I tried to force the IEEE80211_NO_IR flag when IEEE80211_CHAN_DFS
> is set.
>
> - When I reload the reg. domain using "iw reg set", the probes cease,
> but will reappear if I cycle my AP again On then Off.
>
> - When I let the client associate, then disassociate and stop the AP,
> the same problem arises. It disappears if I add a call to
> ath10k_regd_update() in mac.c after a disconnection (This is not a
> fix, since in my case the client never associates).
>
> - Since at startup, the client does not send probes, I infer that the
> problem is *not* caused by a hidden AP that the card could see but
> not airpcap.
>
> - I tried with channels 52 and 100, with regdom FR or US: same problem.
>
> Any ideas?
>
>
> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/
> 01.08.01_60/en_301893v010801p.pdf
[2] http://lists.shmoo.com/pipermail/hostap/2015-January/031906.html
>
> J.P. Tosoni - ACKSYS
>
>
>
>
> _______________________________________________
> ath10k mailing list
> ath10k@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/ath10k
^ permalink raw reply
* Re: ath10k firmware sends probes on DFS channels without radar detection
From: Ben Greear @ 2016-12-06 19:36 UTC (permalink / raw)
To: Jean-Pierre Tosoni, ath10k, linux-wireless; +Cc: Cedric VONCKEN
In-Reply-To: <004a01d24fe2$94da8dc0$be8fa940$@acksys.fr>
On 12/06/2016 09:02 AM, Jean-Pierre Tosoni wrote:
> This follows on the previous discussion
> "Client station sends probes on DFS channels"
>
> Problem:
> The combination of QCA988X firmware v10.2.4.70-2 + ath10k +
> wpa_supplicant do not comply with the norm ETSI/EN 301-893
> section 4.7; because they can send probes for 600s when no
> AP is around.
>
> Analysis:
> The problem seems to lie in the firmware, which regards the presence
> of *any* beacon as a proof that the channel is radar-clean for 600s.
>
> This is a wrong hypothesis, since a rogue AP sending fraudulent
> beacons should not induce a scrupulous STA in sending illegal probes.
>
> Moreover, the norm (table D.1) sets a time limit of 10s to
> shutdown when no AP positively allows the STA to transmit on
> the DFS channel.
>
> Status:
> - there is no known plan at QCA to fix the issue.
> - ath10k firmware is not publicly available for fixes.
> - there is no obvious fix working in ath10k.
> - the issue does not show up with other mac80211 devices like ath9k.
> - wpa_supplicant considers this is a kernel issue [2]
Have you confirmed that there are no probe requests being sent by
ath10k driver?
You could also try disabling the station keep-alive and roaming logic in the firmware by
tweaking the wmi initial setup logic. I disable that in my firmware,
for instance, because mac80211 can do a better job and then I can
save resources in the firmware.
Finally, if that doesn't work, then I could probably fix that in CT firmware
in case that is of interest.
Thanks,
Ben
>
> Jean-Pierre Tosoni
>
>
>
>> -----Message d'origine-----
>> De : ath10k [mailto:ath10k-bounces@lists.infradead.org] De la part de
>> Jean-Pierre Tosoni
>> Envoyé : mercredi 30 novembre 2016 19:04
>> À : ath10k@lists.infradead.org
>> Objet : Client station sends probes on DFS channels
>>
>> Hello list,
>>
>> There is a case where I can see probes on a DFS channel, from a non-
>> associated station using ath10k. (note that the problem does not arise
>> when using ath9k).
>>
>> *The setup*
>>
>> I am using Openwrt, wpa_supplicant and compat-wireless 2016-10-08,
>> Card firmware is ath10k_pci: qca988x hw2.0 (0x4100016c, 0x043202ff)
>> fw 10.2.4.70-2 api 5 htt-ver 2.1 wmi-op 5 htt-op 2
>> cal otp max-sta 128 features no-p2p
>> ath10k_pci: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1
>>
>> I am using channel 116, regdom US or FR, where I see no traffic at all
>> using wireshark+Airpcap.
>> I set wpa_supplicant to scan this channel only for a specific SSID
>> "ssid1".
>>
>> At initial startup of the client device, no probes are going out, which
>> is OK.
>>
>> Then, on another device, I start a hostapd set to channel 116, with a
>> different SSID "otherssid" so that the supplicant will not associate.
>>
>> Shortly (1-2s) after the beacons appear in the air, the client begins to
>> Send probe request in the air, which is unexpected, but acceptable since
>> the client can infer absence of radars from the presence of beacons.
>>
>> *The problem*
>>
>> If I power down the AP, the client continues to send probes for around
>> 10 minutes, which is unacceptable since it cannot handle radar detection,
>> as it is a slave device in the meaning of ETSI/EN 301-893[1].
>>
>>
>> Some tests I made:
>> - I tried to investigate the "beacon hint" mechanism but it appears
>> that it is not used on DFS channels.
>>
>> - I tried to force the IEEE80211_NO_IR flag when IEEE80211_CHAN_DFS
>> is set.
>>
>> - When I reload the reg. domain using "iw reg set", the probes cease,
>> but will reappear if I cycle my AP again On then Off.
>>
>> - When I let the client associate, then disassociate and stop the AP,
>> the same problem arises. It disappears if I add a call to
>> ath10k_regd_update() in mac.c after a disconnection (This is not a
>> fix, since in my case the client never associates).
>>
>> - Since at startup, the client does not send probes, I infer that the
>> problem is *not* caused by a hidden AP that the card could see but
>> not airpcap.
>>
>> - I tried with channels 52 and 100, with regdom FR or US: same problem.
>>
>> Any ideas?
>>
>>
>> [1] http://www.etsi.org/deliver/etsi_en/301800_301899/301893/
>> 01.08.01_60/en_301893v010801p.pdf
> [2] http://lists.shmoo.com/pipermail/hostap/2015-January/031906.html
>>
>> J.P. Tosoni - ACKSYS
>>
>>
>>
>>
>> _______________________________________________
>> ath10k mailing list
>> ath10k@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/ath10k
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH 10/14] rtlwifi: Add BTC_TRACE_STRING to new btcoex
From: Dan Carpenter @ 2016-12-06 19:37 UTC (permalink / raw)
To: Larry Finger; +Cc: kvalo, devel, Ping-Ke Shih, linux-wireless
In-Reply-To: <6442d5c7-f083-0e98-490b-dd18a5a4d316@lwfinger.net>
On Mon, Dec 05, 2016 at 04:34:08PM -0600, Larry Finger wrote:
> Can you point me to a driver with a better way to conditionally dump
> a debugging string to the logs?
People should look at using ftrace and kprobes. They really are very
powerful and useful.
regards,
dan carpenter
^ permalink raw reply
* Re: ath10k firmware crashes in mesh mode on QCA9880
From: Benjamin Morgan @ 2016-12-06 21:32 UTC (permalink / raw)
To: Nagarajan, Ashok Raj, Mohammed Shafi Shajakhan
Cc: agreen@cococorp.com, lede-dev@lists.infradead.org,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org
In-Reply-To: <d8eb0ba5828d43dd83030247ba443b88@aphydexm01f.ap.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 19151 bytes --]
1. Yes, this appears to happens every time a unicast packet with
wpa_supplicant encryption in VHT80 mode is received. I haven't seen a
successful ping-pong pair.
2. We tried with 10.2.4.70.42-2 firmware and still saw crashes.
3. We ran our experiment again with extra debugging turned on.
Node A: 18:A6:F7:23:6E:66 | 10.230.5.41
Node B: 18:A6:F7:26:0F:21 | 10.230.5.42
The ping command we used was run on Node A was 'ping -s 1500 -i 0.1
10.230.5.42'
Here is the dmesg log from Node B.
[ 5413.478170] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5413.503954] ath10k_pci 0000:01:00.0: scan event bss channel type 4
reason 3 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
[ 5413.503985] ath10k_pci 0000:01:00.0: chan info err_code 0 freq 5825
cmd_flags 1 noise_floor -105 rx_clear_count 7692807 cycle_count 312271423
[ 5413.504029] ath10k_pci 0000:01:00.0: scan event completed type 2
reason 0 freq 5825 req_id 40961 scan_id 40960 vdev_id 0 state running (2)
[ 5413.525868] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1
cipher 4 len 16
[ 5413.526014] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 value 1
[ 5413.526193] ath10k_pci 0000:01:00.0: mac vdev 0 set keyidx 1
[ 5413.526216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 value 1
[ 5413.526532] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180 width
3 ptr 86db29b0
[ 5413.526556] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
needed? 0 allowed? 1
[ 5413.526574] ath10k_pci 0000:01:00.0: mac chanctx assign ptr 86db29b0
vdev_id 0
[ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
5180 phymode 11ac-vht80
[ 5413.526616] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags:
0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
[ 5413.533099] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
[ 5413.533148] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
[ 5413.533163] ath10k_pci 0000:01:00.0: mac txpower 23
[ 5413.533180] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
[ 5413.533247] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
[ 5413.533295] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
width 3 ptr 86db29b0 changed 10
[ 5413.533318] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
width 3 ptr 86db29b0 changed 2
[ 5413.533337] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
needed? 1 allowed? 1
[ 5413.533357] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4
subtype 0 macaddr 18:a6:f7:26:0f:21
[ 5413.533412] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
[ 5413.533463] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags:
0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
[ 5413.937652] ath10k_pci 0000:01:00.0: wmi event debug mesg len 152
[ 5413.978273] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5414.478363] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5414.527015] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
[ 5414.527067] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc id
0 bssid 18:a6:f7:26:0f:21
[ 5414.527121] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
[ 5414.527165] ath10k_pci 0000:01:00.0: mac monitor started
[ 5414.527216] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3
value 1000
[ 5414.527262] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
[ 5414.527278] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
staggered
[ 5414.527294] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 5414.527314] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 5414.527330] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 5414.527457] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc id
0 bssid 00:00:00:00:00:00
[ 5414.527501] ath10k_pci 0000:01:00.0: mac vdev 0 up
[ 5414.527564] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
[ 5414.541090] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
needed? 1 allowed? 1
[ 5414.978454] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5415.478548] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5415.978649] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5416.445280] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
needed? 1 allowed? 1
[ 5416.478761] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5416.978879] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5417.478985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5417.979081] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5418.479190] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5418.979301] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5419.479403] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5419.979551] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5420.479643] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5420.979746] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5421.479841] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5421.979940] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5422.480288] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5422.980386] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5423.480490] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5423.980600] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5424.480702] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5424.971969] ath10k_pci 0000:01:00.0: mac vdev 0 peer create
18:a6:f7:23:6e:66 (new sta) sta 1 / 128 peer 2 / 144
[ 5424.972000] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0
peer_addr 18:a6:f7:23:6e:66
[ 5424.975107] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
staggered
[ 5424.975134] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 5424.975219] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 5424.975238] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 5424.980787] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5425.204468] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:23:6e:66 associated
[ 5425.204531] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:23:6e:66
mcs cnt 24 nss 3
[ 5425.204548] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66 qos 1
[ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66
phymode 11na-ht40
[ 5425.204585] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr
18:a6:f7:23:6e:66 (new)
[ 5425.204614] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
0x18:a6:f7:23:6e:66 set param 1 value 0
[ 5425.205376] ath10k_pci 0000:01:00.0: received event id 36891 not
implemented
[ 5425.209240] ath10k_pci 0000:01:00.0: wmi vdev install key idx 0
cipher 4 len 16
[ 5425.209655] ath10k_pci 0000:01:00.0: wmi vdev install key idx 1
cipher 4 len 16
[ 5425.209848] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 31 value 1
[ 5425.210196] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
staggered
[ 5425.210221] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 5425.210296] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 5425.210315] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 5425.480863] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5425.938619] ath10k_pci 0000:01:00.0: wmi event debug mesg len 100
[ 5425.980946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5425.995007] ath10k_pci 0000:01:00.0: mac sta rc update for
18:a6:f7:23:6e:66 changed 00000001 bw 2 nss 3 smps 1
[ 5425.995060] ath10k_pci 0000:01:00.0: mac update sta 18:a6:f7:23:6e:66
peer bw 2
[ 5425.995081] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
0x18:a6:f7:23:6e:66 set param 4 value 2
[ 5426.481030] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5426.981117] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5427.481206] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5427.981294] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5428.481628] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5428.981718] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5429.481812] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5429.981894] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5430.481985] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5430.982073] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5431.482174] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5431.982505] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5432.482597] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5432.982679] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5433.482765] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5433.982857] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5434.482946] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5434.983008] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5435.483100] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5435.983181] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5436.483276] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5436.983366] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5437.483445] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5437.983516] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5438.483607] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5438.983692] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 5439.439875] ath10k_pci 0000:01:00.0: firmware crashed! (uuid
db76b67c-ca98-4519-a762-4ff4edb45526)
[ 5439.449007] ath10k_pci 0000:01:00.0: qca988x hw2.0 target 0x4100016c
chip_id 0x043202ff sub 0000:0000
[ 5439.458378] ath10k_pci 0000:01:00.0: kconfig debug 1 debugfs 1
tracing 0 dfs 1 testmode 1
[ 5439.471460] ath10k_pci 0000:01:00.0: firmware ver 10.2.4.70.54 api 5
features no-p2p,raw-mode,mfp crc32 9d340dd9
[ 5439.481844] ath10k_pci 0000:01:00.0: board_file api 1 bmi_id N/A
crc32 bebc7c08
[ 5439.489267] ath10k_pci 0000:01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2
cal file max-sta 128 raw 0 hwcrypto 1
[ 5439.500918] ath10k_pci 0000:01:00.0: firmware register dump:
[ 5439.506678] ath10k_pci 0000:01:00.0: [00]: 0x4100016C 0x000015B3
0x009A4577 0x00955B31
[ 5439.514706] ath10k_pci 0000:01:00.0: [04]: 0x009A4577 0x00060130
0x00000002 0x00439E98
[ 5439.522751] ath10k_pci 0000:01:00.0: [08]: 0x0044110C 0x00442074
0x00407120 0x004436CC
[ 5439.530794] ath10k_pci 0000:01:00.0: [12]: 0x00000009 0x00000000
0x009A3518 0x009A3526
[ 5439.538834] ath10k_pci 0000:01:00.0: [16]: 0x00958080 0x0094085D
0x00000000 0x00000000
[ 5439.546871] ath10k_pci 0000:01:00.0: [20]: 0x409A4577 0x0040AAC4
0x0040AC60 0x0040AC09
[ 5439.554915] ath10k_pci 0000:01:00.0: [24]: 0x809A44BA 0x0040AB24
0x00400000 0xC09A4577
[ 5439.562948] ath10k_pci 0000:01:00.0: [28]: 0x809A39DE 0x0040AB84
0x0044110C 0x00442074
[ 5439.570992] ath10k_pci 0000:01:00.0: [32]: 0x809A5FE2 0x0040ABB4
0x0044110C 0x00407120
[ 5439.579032] ath10k_pci 0000:01:00.0: [36]: 0x809A2E6C 0x0040ABF4
0x0040AC14 0x00001580
[ 5439.587070] ath10k_pci 0000:01:00.0: [40]: 0x80990F6F 0x0040AD04
0x009C643C 0x004436CC
[ 5439.595113] ath10k_pci 0000:01:00.0: [44]: 0x80998510 0x0040AD64
0x004208FC 0x00439E4C
[ 5439.603146] ath10k_pci 0000:01:00.0: [48]: 0x8099AE95 0x0040AD84
0x004208FC 0x00425E00
[ 5439.611191] ath10k_pci 0000:01:00.0: [52]: 0x809BFC55 0x0040AEE4
0x00424FE8 0x00000002
[ 5439.619230] ath10k_pci 0000:01:00.0: [56]: 0x80940F18 0x0040AF14
0x00000004 0x004039D0
[ 5439.726818] ieee80211 phy0: Hardware restart was requested
[ 5439.732433] ath10k_pci 0000:01:00.0: wmi mgmt vdev down id 0x1
[ 5439.732461] ath10k_pci 0000:01:00.0: wmi vdev stop id 0x1
[ 5439.732482] ath10k_pci 0000:01:00.0: failed to synchronize monitor
vdev 1 stop: -143
[ 5439.740370] ath10k_pci 0000:01:00.0: mac monitor vdev 1 stopped
[ 5439.740386] ath10k_pci 0000:01:00.0: failed to stop monitor vdev: -143
[ 5439.747042] ath10k_pci 0000:01:00.0: wmi disable pktlog
We noticed in this log that when the radio starts up it says that it is
in VHT80 mode:
[ 5413.526592] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
5180 phymode 11ac-vht80
But when a peer connects it seems to think the peer is in HT40 mode:
[ 5425.204563] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:23:6e:66
phymode 11na-ht40
Compared to no encryption case - this log was taken from Node A:
[ 24.874253] ath10k_pci 0000:01:00.0: mac chanctx add freq 5180 width
3 ptr 86d26db0
[ 24.874278] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
needed? 0 allowed? 1
[ 24.874296] ath10k_pci 0000:01:00.0: mac chanctx assign ptr 86d26db0
vdev_id 0
[ 24.874312] ath10k_pci 0000:01:00.0: mac vdev 0 start center_freq
5180 phymode 11ac-vht80
[ 24.874337] ath10k_pci 0000:01:00.0: wmi vdev start id 0x0 flags:
0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
[ 24.881335] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
[ 24.881423] ath10k_pci 0000:01:00.0: mac vdev_id 0 txpower 23
[ 24.881438] ath10k_pci 0000:01:00.0: mac txpower 23
[ 24.881454] ath10k_pci 0000:01:00.0: wmi pdev set param 3 value 46
[ 24.881491] ath10k_pci 0000:01:00.0: wmi pdev set param 4 value 46
[ 24.881515] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
width 3 ptr 86d26db0 changed 10
[ 24.881535] ath10k_pci 0000:01:00.0: mac chanctx change freq 5180
width 3 ptr 86d26db0 changed 2
[ 24.881554] ath10k_pci 0000:01:00.0: mac monitor recalc started? 0
needed? 1 allowed? 1
[ 24.881574] ath10k_pci 0000:01:00.0: WMI vdev create: id 1 type 4
subtype 0 macaddr 18:a6:f7:23:6e:66
[ 24.881689] ath10k_pci 0000:01:00.0: mac monitor vdev 1 created
[ 24.881745] ath10k_pci 0000:01:00.0: wmi vdev start id 0x1 flags:
0x0, freq 5180, mode 10, ch_flags: 0xA000000, max_power: 46
[ 25.273460] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 25.730570] ath10k_pci 0000:01:00.0: wmi event debug mesg len 300
[ 25.773566] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 25.874556] ath10k_pci 0000:01:00.0: WMI_VDEV_START_RESP_EVENTID
[ 25.879992] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x1 assoc id
0 bssid 18:a6:f7:23:6e:66
[ 25.880077] ath10k_pci 0000:01:00.0: mac monitor vdev 1 started
[ 25.880093] ath10k_pci 0000:01:00.0: mac monitor started
[ 25.880139] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 3
value 1000
[ 25.880184] ath10k_pci 0000:01:00.0: mac vdev 0 beacon_interval 1000
[ 25.880199] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
staggered
[ 25.880215] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 25.880235] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 25.880250] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 25.880988] ath10k_pci 0000:01:00.0: wmi mgmt vdev up id 0x0 assoc id
0 bssid 00:00:00:00:00:00
[ 25.881035] ath10k_pci 0000:01:00.0: mac vdev 0 up
[ 25.881097] ath10k_pci 0000:01:00.0: WMI_TBTTOFFSET_UPDATE_EVENTID
[ 25.882968] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
[ 25.928796] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
staggered
[ 25.928821] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 25.928866] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 25.928883] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 25.929020] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
needed? 1 allowed? 1
[ 25.941886] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
staggered
[ 25.941911] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 25.941955] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 25.941972] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 25.953727] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
staggered
[ 25.953753] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 25.953798] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 25.953817] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 25.970588] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
staggered
[ 25.970614] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 25.970659] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 25.970676] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 25.989056] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
staggered
[ 25.989081] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 25.989126] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 25.989143] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 26.071686] ath10k_pci 0000:01:00.0: mac vdev 0 peer create
18:a6:f7:26:0f:21 (new sta) sta 1 / 128 peer 2 / 144
[ 26.071712] ath10k_pci 0000:01:00.0: wmi peer create vdev_id 0
peer_addr 18:a6:f7:26:0f:21
[ 26.071952] ath10k_pci 0000:01:00.0: mac sta 18:a6:f7:26:0f:21 associated
[ 26.071981] ath10k_pci 0000:01:00.0: mac ht peer 18:a6:f7:26:0f:21
mcs cnt 24 nss 3
[ 26.071999] ath10k_pci 0000:01:00.0: mac vht peer 18:a6:f7:26:0f:21
max_mpdu 1048575 flags 0x601b001
[ 26.072013] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21 qos 1
[ 26.072028] ath10k_pci 0000:01:00.0: mac peer 18:a6:f7:26:0f:21
phymode 11ac-vht80
[ 26.072047] ath10k_pci 0000:01:00.0: wmi peer assoc vdev 0 addr
18:a6:f7:26:0f:21 (new)
[ 26.072071] ath10k_pci 0000:01:00.0: wmi vdev 0 peer
0x18:a6:f7:26:0f:21 set param 1 value 0
[ 26.072502] ath10k_pci 0000:01:00.0: received event id 36891 not
implemented
[ 26.074194] ath10k_pci 0000:01:00.0: mac sta rc update for
18:a6:f7:26:0f:21 changed 00000000 bw 2 nss 3 smps 1
[ 26.074586] ath10k_pci 0000:01:00.0: vdev 0 set beacon tx mode to
staggered
[ 26.074609] ath10k_pci 0000:01:00.0: wmi pdev set param 7 value 0
[ 26.074682] ath10k_pci 0000:01:00.0: mac vdev 0 dtim_period 2
[ 26.074701] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 13 value 2
[ 26.074760] ath10k_pci 0000:01:00.0: mac vdev 0 slot_time 2
[ 26.074779] ath10k_pci 0000:01:00.0: wmi vdev id 0x0 set param 7 value 2
[ 26.273652] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 26.730650] ath10k_pci 0000:01:00.0: wmi event debug mesg len 44
[ 26.773733] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
[ 27.135445] ath10k_pci 0000:01:00.0: mac monitor recalc started? 1
needed? 1 allowed? 1
[ 27.273810] ath10k_pci 0000:01:00.0: WMI_UPDATE_STATS_EVENTID
It seems to start up in VHT80 mode and when it peers with Node B it
thinks Node B is also in VHT80 mode and ping works.
4. Beacons are sent at 6 Mb/s basic rate and unicast QoS Data is sent
with three spatial streams. Attached is the full pcap of the experiment.
Thank you for looking into this!
~Benjamin
On 12/05/2016 11:24 AM, Nagarajan, Ashok Raj wrote:
> 0x009A4577 0x00955B31
>
> Benjamin, Thanks for the logs.
> Quick questions to further debug the issue here,
>
> 1. Is this issue seen every time you start sending data traffic?
> 2. Issue seen with older firmwares? (FYR, http://linuxwireless.org/en/users/Drivers/ath10k/firmware/ )
> 3. Could you please share the dmesg from your device after enabling MAC and WMI logs in ath10k driver
> To enable debug logs please see http://linuxwireless.org/en/users/Drivers/ath10k/debug/
> 4. Do you know what is the Number of Spatial Streams seen in mesh beacons and in mesh data packet?
>
> Thanks,
> Ashok
[-- Attachment #2: ath10k_crash_pcap.tgz --]
[-- Type: application/x-compressed-tar, Size: 25083 bytes --]
^ permalink raw reply
* Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Denis Kenzior @ 2016-12-06 21:42 UTC (permalink / raw)
To: Johannes Berg, Andrew Zaborowski, linux-wireless
In-Reply-To: <1481008560.6610.3.camel@sipsolutions.net>
Hi Johannes,
On 12/06/2016 01:16 AM, Johannes Berg wrote:
> On Mon, 2016-12-05 at 09:32 -0600, Denis Kenzior wrote:
>
>> To what purpose? That's like saying that maybe a socket should be
>> kept open in case an application crashes.
>
> That socket would be useless, so no, that's not comparable at all. It's
> more like saying the disk should be unmounted once 'mount' exits ;-)
>
Except the kernel doesn't want to reconfigure mount parameters every
15-30 minutes. So no, its not like 'mount' at all ;) But I digress, I
can see that we won't agree here. But we still would like the kernel to
clean up nicely if stuff hits the fan.
> Anyway ... I'm not even super against this patch, but you need to fix
I'm afraid to consider what you're like when you _are_ 'super' against
something :)
> things:
> * this is actually wrong for authenticate - I'll let you figure out
> why by yourself
So here's a quick test, with the client triggering authenticate, then
crashing:
< Request: Authenticate (0x25) len 52 [ack] 362.339712
Interface Index: 3 (0x00000003)
Wiphy Frequency: 2417 (0x00000971)
MAC Address <snip>
SSID: len 9
<snip>
Auth Type: 0 (0x00000000)
> Event: New Station (0x13) len 32 362.341337
Interface Index: 3 (0x00000003)
> Response: Authenticate (0x25) len 4 362.341860
Status: Success (0)
> Event: Authenticate (0x25) len 64 362.343640
Wiphy: 0 (0x00000000)
Interface Index: 3 (0x00000003)
> Event: Del Station (0x14) len 1144 367.442024
Interface Index: 3 (0x00000003)
MAC Address <snip>
Pay attention to the time stamps. The del station event comes in 5
seconds or so after our client has aborted. So for 5 seconds we have an
unmanaged link to some AP. It would be nice if the authentication was
aborted as soon as we crash.
So again, why do you say that SOCKET_OWNER is 'wrong' for authenticate?
Or do you mean something else?
> * you need to teach people to write useful commit messages
The commit description in this patch was lacking. We both agree here.
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Andrew Zaborowski @ 2016-12-07 1:40 UTC (permalink / raw)
To: Denis Kenzior; +Cc: Johannes Berg, linux-wireless
In-Reply-To: <584730D7.2020708@gmail.com>
Hi,
On 6 December 2016 at 22:42, Denis Kenzior <denkenz@gmail.com> wrote:
> On 12/06/2016 01:16 AM, Johannes Berg wrote:
>> Anyway ... I'm not even super against this patch, but you need to fix
>> things:
>> * this is actually wrong for authenticate - I'll let you figure out
>> why by yourself
>
>
> So here's a quick test, with the client triggering authenticate, then
> crashing:
>
> < Request: Authenticate (0x25) len 52 [ack] 362.339712
> Interface Index: 3 (0x00000003)
> Wiphy Frequency: 2417 (0x00000971)
> MAC Address <snip>
> SSID: len 9
> <snip>
> Auth Type: 0 (0x00000000)
>> Event: New Station (0x13) len 32 362.341337
> Interface Index: 3 (0x00000003)
>> Response: Authenticate (0x25) len 4 362.341860
> Status: Success (0)
>> Event: Authenticate (0x25) len 64 362.343640
> Wiphy: 0 (0x00000000)
> Interface Index: 3 (0x00000003)
>> Event: Del Station (0x14) len 1144 367.442024
> Interface Index: 3 (0x00000003)
> MAC Address <snip>
>
> Pay attention to the time stamps. The del station event comes in 5 seconds
> or so after our client has aborted. So for 5 seconds we have an unmanaged
> link to some AP. It would be nice if the authentication was aborted as soon
> as we crash.
>
> So again, why do you say that SOCKET_OWNER is 'wrong' for authenticate? Or
> do you mean something else?
Possibly Johanness refers to the fact that if you use
CMD_AUTHENTICATE, or if you use CMD_CONNECT but the driver implements
the SME -- doesn't use the cfg80211 software SME -- then
cfg80211_disconnect won't do anything if we're not associated, only
authenticated. Currently cfg80211 doesn't have knowledge of whether
it is authenticated and where to.
With the software SME current_bss would be set from the moment the
authentication attempt starts, so there seems to be an inconsistency
which would affect for example the NL80211_BSS_STATUS_ASSOCIATED flags
in the result of CMD_GET_SCAN. Perhaps this can be fixed by always
setting current_bss on auth attempt start, with flags to indicate
whether authentication has happened and whether association happened.
At the very least with this patch if you set the socket owner during
CMD_AUTHENTICATE and then separately associate, you'd get the expected
deauthentication.
Best regards
^ permalink raw reply
* [PATCH] ath10k: Avoid potential page alloc BUG_ON in tx free path
From: Mohammed Shafi Shajakhan @ 2016-12-07 5:00 UTC (permalink / raw)
To: ath10k; +Cc: mohammed, linux-wireless, Mohammed Shafi Shajakhan
From: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
'ath10k_htt_tx_free_cont_txbuf' and 'ath10k_htt_tx_free_cont_frag_desc'
have NULL pointer checks to avoid crash if they are called twice
but this is as of now not sufficient as these pointers are not assigned
to NULL once the contiguous DMA memory allocation is freed, fix this.
Though this may not be hit with the explicity check of state variable
'tx_mem_allocated' check, good to have this addressed as well.
Below BUG_ON is hit when the above scenario is simulated
with kernel debugging enabled
page:f6d09a00 count:0 mapcount:-127 mapping: (null)
index:0x0
flags: 0x40000000()
page dumped because: VM_BUG_ON_PAGE(page_ref_count(page)
== 0)
------------[ cut here ]------------
kernel BUG at ./include/linux/mm.h:445!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
EIP is at put_page_testzero.part.88+0xd/0xf
Call Trace:
[<c118a2cc>] __free_pages+0x3c/0x40
[<c118a30e>] free_pages+0x3e/0x50
[<c10222b4>] dma_generic_free_coherent+0x24/0x30
[<f8c1d9a8>] ath10k_htt_tx_free_cont_txbuf+0xf8/0x140
[<f8c1e2a9>] ath10k_htt_tx_destroy+0x29/0xa0
[<f8c143e0>] ath10k_core_destroy+0x60/0x80 [ath10k_core]
[<f8acd7e9>] ath10k_pci_remove+0x79/0xa0 [ath10k_pci]
[<c13ed7a8>] pci_device_remove+0x38/0xb0
[<c14d3492>] __device_release_driver+0x72/0x100
[<c14d36b7>] driver_detach+0x97/0xa0
[<c14d29c0>] bus_remove_driver+0x40/0x80
[<c14d427a>] driver_unregister+0x2a/0x60
[<c13ec768>] pci_unregister_driver+0x18/0x70
[<f8aced4f>] ath10k_pci_exit+0xd/0x2be [ath10k_pci]
[<c1101e78>] SyS_delete_module+0x158/0x210
[<c11b34f1>] ? __might_fault+0x41/0xa0
[<c11b353b>] ? __might_fault+0x8b/0xa0
[<c1001a4b>] do_fast_syscall_32+0x9b/0x1c0
[<c178da34>] sysenter_past_esp+0x45/0x74
Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath10k/htt_tx.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/htt_tx.c b/drivers/net/wireless/ath/ath10k/htt_tx.c
index 27e49db..86b427f 100644
--- a/drivers/net/wireless/ath/ath10k/htt_tx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_tx.c
@@ -239,6 +239,7 @@ static void ath10k_htt_tx_free_cont_txbuf(struct ath10k_htt *htt)
size = htt->max_num_pending_tx * sizeof(struct ath10k_htt_txbuf);
dma_free_coherent(ar->dev, size, htt->txbuf.vaddr, htt->txbuf.paddr);
+ htt->txbuf.vaddr = NULL;
}
static int ath10k_htt_tx_alloc_cont_txbuf(struct ath10k_htt *htt)
@@ -268,6 +269,7 @@ static void ath10k_htt_tx_free_cont_frag_desc(struct ath10k_htt *htt)
size,
htt->frag_desc.vaddr,
htt->frag_desc.paddr);
+ htt->frag_desc.vaddr = NULL;
}
static int ath10k_htt_tx_alloc_cont_frag_desc(struct ath10k_htt *htt)
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] net: wireless: realtek: constify rate_control_ops structures
From: Jes Sorensen @ 2016-12-07 5:07 UTC (permalink / raw)
To: Larry Finger
Cc: Bhumika Goyal, julia.lawall, chaoming_li, kvalo, linux-wireless,
netdev, linux-kernel
In-Reply-To: <0f223291-734f-7658-57b7-18e962d15823@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> On 12/02/2016 03:50 AM, Bhumika Goyal wrote:
>> The structures rate_control_ops are only passed as an argument to the
>> functions ieee80211_rate_control_{register/unregister}. This argument is
>> of type const, so rate_control_ops having this property can also be
>> declared as const.
>> Done using Coccinelle:
>>
>> @r1 disable optional_qualifier @
>> identifier i;
>> position p;
>> @@
>> static struct rate_control_ops i@p = {...};
>>
>> @ok1@
>> identifier r1.i;
>> position p;
>> @@
>> ieee80211_rate_control_register(&i@p)
>>
>> @ok2@
>> identifier r1.i;
>> position p;
>> @@
>> ieee80211_rate_control_unregister(&i@p)
>>
>> @bad@
>> position p!={r1.p,ok1.p,ok2.p};
>> identifier r1.i;
>> @@
>> i@p
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r1.i;
>> @@
>> static
>> +const
>> struct rate_control_ops i={...};
>>
>> @depends on !bad disable optional_qualifier@
>> identifier r1.i;
>> @@
>> +const
>> struct rate_control_ops i;
>>
>> File size before:
>> text data bss dec hex filename
>> 1991 104 0 2095 82f wireless/realtek/rtlwifi/rc.o
>>
>> File size after:
>> text data bss dec hex filename
>> 2095 0 0 2095 wireless/realtek/rtlwifi/rc.o
>>
[snip]
> The content of your patch is OK; however, your subject is not. By
> convention, "net: wireless: realtek:" is assumed. We do, however,
> include "rtlwifi:" to indicate which part of
> drivers/net/wireless/realtek/ is referenced.
In addition, the first part of the description is useful and the file
size information is reasonable too, but ~20 lines of coccinelle scripts
in the commit message is rather pointless.
Jes
^ permalink raw reply
* Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Johannes Berg @ 2016-12-07 6:15 UTC (permalink / raw)
To: Denis Kenzior, Andrew Zaborowski, linux-wireless
In-Reply-To: <584730D7.2020708@gmail.com>
> I'm afraid to consider what you're like when you _are_ 'super'
> against something :)
Why, that's easy, there wouldn't be a long discussion like that ;-)
> So here's a quick test, with the client triggering authenticate, then
> crashing:
> < Request: Authenticate (0x25) len 52
> [ack] 362.339712
> [...]
> > Event: Del Station (0x14) len
> 1144 367.442024
> Pay attention to the time stamps. The del station event comes in 5
> seconds or so after our client has aborted. So for 5 seconds we have
> an unmanaged link to some AP.
No, this is the part you didn't understand. Simply authenticating
doesn't actually create anything like a "link" to the AP. The only
reason we keep the station entry around for a few seconds is that it
*probably* will be used next to associate. But if you don't do that, or
authenticate to some other AP, or do whatever else - nothing stops you
from doing that. There's no connection, nothing really stays active
except for this 5 second grace period to associate.
So even if you crash here like in the example, there's nothing to clean
up, a subsequent authentication attempt to the same or another AP will
go through anyway.
Therefore, there's nothing to "own" with an authentication attempt,
since it doesn't actually keep any (permanent) state in the kernel, and
keeping the station entry around is just an optimisation.
I don't think it's worth trying to clean that up.
Also, consider that authentication doesn't block anything, so another
socket might immediately do another authentication/association, and you
don't want to kill that even when the first one dies. Corner case,
sure, but at least with association the second one would get "-EBUSY"
or so, whereas authentication keeps no state in the kernel.
johannes
^ permalink raw reply
* Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Johannes Berg @ 2016-12-07 6:19 UTC (permalink / raw)
To: Andrew Zaborowski, Denis Kenzior; +Cc: linux-wireless
In-Reply-To: <CAOq732LOk-GQiSfs9Js-qEgvmbNMD_xf6j_1NR88Z1SDL=J8WA@mail.gmail.com>
> Possibly Johanness refers to the fact that if you use
> CMD_AUTHENTICATE, or if you use CMD_CONNECT but the driver implements
> the SME -- doesn't use the cfg80211 software SME -- then
> cfg80211_disconnect won't do anything if we're not associated, only
> authenticated. Currently cfg80211 doesn't have knowledge of whether
> it is authenticated and where to.
We used to track it, but it was a nightmare and just always buggy :)
> With the software SME current_bss would be set from the moment the
> authentication attempt starts,
I'm almost certain this isn't true, what makes you think so?
> so there seems to be an inconsistency
> which would affect for example the NL80211_BSS_STATUS_ASSOCIATED
> flags in the result of CMD_GET_SCAN.
Thus this can't be the case.
> Perhaps this can be fixed by always
> setting current_bss on auth attempt start, with flags to indicate
> whether authentication has happened and whether association happened.
No! That would be wrong!
> At the very least with this patch if you set the socket owner during
> CMD_AUTHENTICATE and then separately associate, you'd get the
> expected deauthentication.
That would *NOT* be expected. There's no need to even authenticate
through CMD_AUTHENTICATE at all to connect to (another) AP!
You need to think beyond the 1996 version of 802.11 ;-)
johannes
^ permalink raw reply
* Re: [PATCH 1/2] ath10k: add accounting for the extended peer statistics
From: Mohammed Shafi Shajakhan @ 2016-12-07 6:28 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, ath10k, Kalle Valo
In-Reply-To: <992a4e2676037a06f482cdbe2d3d39e287530be5.1480974623.git.chunkeey@googlemail.com>
Hi Christian,
On Mon, Dec 05, 2016 at 10:52:45PM +0100, Christian Lamparter wrote:
> The 10.4 firmware adds extended peer information to the
> firmware's statistics payload. This additional info is
> stored as a separate data field and the elements are
> stored in their own "peers_extd" list.
>
> These elements can pile up in the same way as the peer
> information elements. This is because the
> ath10k_wmi_10_4_op_pull_fw_stats() function tries to
> pull the same amount (num_peer_stats) for every statistic
> data unit.
>
> Fixes: 4a49ae94a448faa ("ath10k: fix 10.4 extended peer stats update")
> Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
> ---
> drivers/net/wireless/ath/ath10k/debug.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/ath10k/debug.c b/drivers/net/wireless/ath/ath10k/debug.c
> index 82a4c67f3672..4acd9eb65910 100644
> --- a/drivers/net/wireless/ath/ath10k/debug.c
> +++ b/drivers/net/wireless/ath/ath10k/debug.c
> @@ -399,6 +399,7 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> * prevent firmware from DoS-ing the host.
> */
> ath10k_fw_stats_peers_free(&ar->debug.fw_stats.peers);
> + ath10k_fw_extd_stats_peers_free(&ar->debug.fw_stats.peers_extd);
[shafi] thanks for fixing this !
> ath10k_warn(ar, "dropping fw peer stats\n");
> goto free;
> }
> @@ -409,10 +410,12 @@ void ath10k_debug_fw_stats_process(struct ath10k *ar, struct sk_buff *skb)
> goto free;
> }
>
> + if (!list_empty(&stats.peers))
[shafi] sorry please correct me if i am wrong, for 'extended peer stats' we are checking
for normal 'peer stats' ? Is this the fix intended, i had started a build to
check your change and we will keep you posted, does this fix displaying
'rx_duration' in ath10k fw_stats.
> + list_splice_tail_init(&stats.peers_extd,
> + &ar->debug.fw_stats.peers_extd);
> +
> list_splice_tail_init(&stats.peers, &ar->debug.fw_stats.peers);
> list_splice_tail_init(&stats.vdevs, &ar->debug.fw_stats.vdevs);
> - list_splice_tail_init(&stats.peers_extd,
> - &ar->debug.fw_stats.peers_extd);
> }
>
> complete(&ar->debug.fw_stats_complete);
thanks,
shafi
^ permalink raw reply
* [PATCH] iwlegacy: make il3945_mac_ops __ro_after_init
From: Johannes Berg @ 2016-12-07 6:36 UTC (permalink / raw)
To: linux-wireless; +Cc: Stanislaw Gruszka, Johannes Berg
From: Johannes Berg <johannes.berg@intel.com>
There's no need for this to be only __read_mostly, since
it's only written in a single way depending on the module
parameter, so that can be moved into the module's __init
function, and the ops can be __ro_after_init.
This is a little bit safer since it means the ops can't
be overwritten (accidentally or otherwise), which would
otherwise cause an arbitrary function or bad pointer to
be called.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlegacy/3945-mac.c b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
index 466912eb2d87..e8e65115feba 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
@@ -3469,7 +3469,7 @@ static struct attribute_group il3945_attribute_group = {
.attrs = il3945_sysfs_entries,
};
-static struct ieee80211_ops il3945_mac_ops __read_mostly = {
+static struct ieee80211_ops il3945_mac_ops __ro_after_init = {
.tx = il3945_mac_tx,
.start = il3945_mac_start,
.stop = il3945_mac_stop,
@@ -3627,15 +3627,6 @@ il3945_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
il->cmd_queue = IL39_CMD_QUEUE_NUM;
- /*
- * Disabling hardware scan means that mac80211 will perform scans
- * "the hard way", rather than using device's scan.
- */
- if (il3945_mod_params.disable_hw_scan) {
- D_INFO("Disabling hw_scan\n");
- il3945_mac_ops.hw_scan = NULL;
- }
-
D_INFO("*** LOAD DRIVER ***\n");
il->cfg = cfg;
il->ops = &il3945_ops;
@@ -3913,6 +3904,15 @@ il3945_init(void)
pr_info(DRV_DESCRIPTION ", " DRV_VERSION "\n");
pr_info(DRV_COPYRIGHT "\n");
+ /*
+ * Disabling hardware scan means that mac80211 will perform scans
+ * "the hard way", rather than using device's scan.
+ */
+ if (il3945_mod_params.disable_hw_scan) {
+ pr_info("hw_scan is disabled\n");
+ il3945_mac_ops.hw_scan = NULL;
+ }
+
ret = il3945_rate_control_register();
if (ret) {
pr_err("Unable to register rate control algorithm: %d\n", ret);
--
2.9.3
^ permalink raw reply related
* Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Denis Kenzior @ 2016-12-07 6:40 UTC (permalink / raw)
To: Johannes Berg, Andrew Zaborowski, linux-wireless
In-Reply-To: <1481091301.4092.5.camel@sipsolutions.net>
Hi Johannes,
On 12/07/2016 12:15 AM, Johannes Berg wrote:
>
>> I'm afraid to consider what you're like when you _are_ 'super'
>> against something :)
>
> Why, that's easy, there wouldn't be a long discussion like that ;-)
lol
>
> No, this is the part you didn't understand. Simply authenticating
> doesn't actually create anything like a "link" to the AP. The only
Okay, but it is then a bit misleading that iw link reports us being
'connected' during this time for example.
> reason we keep the station entry around for a few seconds is that it
> *probably* will be used next to associate. But if you don't do that, or
> authenticate to some other AP, or do whatever else - nothing stops you
> from doing that. There's no connection, nothing really stays active
> except for this 5 second grace period to associate.
>
> So even if you crash here like in the example, there's nothing to clean
> up, a subsequent authentication attempt to the same or another AP will
> go through anyway.
>
> Therefore, there's nothing to "own" with an authentication attempt,
> since it doesn't actually keep any (permanent) state in the kernel, and
> keeping the station entry around is just an optimisation.
>
> I don't think it's worth trying to clean that up.
Fair enough. I think we can live with that since we're not using
CMD_AUTHENTICATE unless we need to roam using FT.
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH] RFC: Universal scan proposal
From: Johannes Berg @ 2016-12-07 6:44 UTC (permalink / raw)
To: Dmitry Shmidt; +Cc: linux-wireless
In-Reply-To: <CAH7ZN-wcvoJLTr_zYMwpbjuvMBGwmNhuVYx-MuNU1pOPTf9HEA@mail.gmail.com>
> Indeed, results are results. I just want to take care of two things:
> 1) Memory consumption - we can clear stale scan results for
> connection, but not for location if we are using history scan.
Well eventually we also have to clear for location if we run out of
memory, that usually means dumping them out to the host, no?
> 2) Use of insufficient results for connection - in case we had
> history or hotlist scan only for very limited amount of channels,
> then we may not have enough APs in our result for "sterling"
> connection decision.
I'm not entirely sure about this case - surely noticing "we can do
better now" is still better than waiting for being able to make the
perfect decision?
> > > Report: none / batch / immediate
> >
> > Not sure I see much point in "none"??
> >
> > Can you define these more clearly? Do you think "batch" reporting
> > should be like the gscan buckets? Or actually have full
> > information?
>
> None - means that there is not need to report. It can be useful
> in case of roaming scan, scheduling or hotlist scan - you didn't find
> anything suitable - don't report that there is no scan results.
But that seems more of a filtering thing, combined with "immediate" for
anything passing the filter?
> > > Request may have priority and can be inserted into
> > > the head of the queue.
> > > Types of scans:
> > > - Normal scan
> > > - Scheduled scan
> > > - Hotlist (BSSID scan)
> > > - Roaming
> > > - AutoJoin
> >
> > I think somebody else said this but I didn't find it now - I think
> > this would make more sense to define in terms of expected behaviour
> > than use cases for each type of scan.
>
> I think Luca made this statement.
Yeah - I just couldn't find it again on re-reading the thread :)
> It is totally ok from SW point of
> view - especially due to the fact that scan is scan. However,
> I suspect it will be harder to handle from user experience. I mean
> at the end wireless framework / driver / FW will convert special
> scan type to usual scan with special params and response, but why
> to put this burden on user?
I just think it's more flexible and open-ended. The actual definition
of the resulting parameters needs to be somewhere anyway - putting it
into driver/firmware (vs. wifi framework or so) seems to duplicate it
and certainly makes it harder to modify/extend in the future, no?
johannes
^ permalink raw reply
* Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Johannes Berg @ 2016-12-07 6:48 UTC (permalink / raw)
To: Denis Kenzior, Andrew Zaborowski, linux-wireless
In-Reply-To: <5847AEF9.90409@gmail.com>
On Wed, 2016-12-07 at 00:40 -0600, Denis Kenzior wrote:
>
> > No, this is the part you didn't understand. Simply authenticating
> > doesn't actually create anything like a "link" to the AP. The only
>
> Okay, but it is then a bit misleading that iw link reports us being
> 'connected' during this time for example.
It doesn't!
# iw wlan0 auth <ssid> <bssid> open 2462
-> iw event reporting
wlan0 (phy #0): auth <localMAC> -> <bssid> status: 0: Successful
# iw wlan0 link
Not connected.
> Fair enough. I think we can live with that since we're not using
> CMD_AUTHENTICATE unless we need to roam using FT.
That seems like a very strange decision, but it's obviously up to you
:)
johannes
^ permalink raw reply
* Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Denis Kenzior @ 2016-12-07 7:07 UTC (permalink / raw)
To: Johannes Berg, Andrew Zaborowski, linux-wireless
In-Reply-To: <1481093287.4092.20.camel@sipsolutions.net>
Hi Johannes,
On 12/07/2016 12:48 AM, Johannes Berg wrote:
> On Wed, 2016-12-07 at 00:40 -0600, Denis Kenzior wrote:
>>
>>> No, this is the part you didn't understand. Simply authenticating
>>> doesn't actually create anything like a "link" to the AP. The only
>>
>> Okay, but it is then a bit misleading that iw link reports us being
>> 'connected' during this time for example.
>
> It doesn't!
>
> # iw wlan0 auth <ssid> <bssid> open 2462
>
> -> iw event reporting
> wlan0 (phy #0): auth <localMAC> -> <bssid> status: 0: Successful
>
> # iw wlan0 link
> Not connected.
>
Yes, you're right. It is iw info that shows us 'connected'
< Request: Get Interface (0x05) len 8 [ack] 35235.316448
Interface Index: 3 (0x00000003)
> Result: New Interface (0x07) len 108 35235.316455
Interface Index: 3 (0x00000003)
Interface Name: wlp2s0
Wiphy: 0 (0x00000000)
Interface Type: 2 (0x00000002)
Wireless Device: 1 (0x0000000000000001)
Generation: 5 (0x00000005)
Wiphy Frequency: 2417 (0x00000971)
Wiphy Channel Type: 1 (0x00000001)
Channel Width: 1 (0x00000001)
Center Frequency 1: 2417 (0x00000971)
Wiphy TX Power Level: 2200 (0x00000898)
> Response: Get Interface (0x05) len 4 35235.316457
Status: Success (0)
>
>> Fair enough. I think we can live with that since we're not using
>> CMD_AUTHENTICATE unless we need to roam using FT.
>
> That seems like a very strange decision, but it's obviously up to you
> :)
>
Care to elaborate ?
Regards,
-Denis
^ permalink raw reply
* Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Johannes Berg @ 2016-12-07 7:38 UTC (permalink / raw)
To: Denis Kenzior, Andrew Zaborowski, linux-wireless
In-Reply-To: <5847B51A.6090303@gmail.com>
> > > Fair enough. I think we can live with that since we're not using
> > > CMD_AUTHENTICATE unless we need to roam using FT.
> >
> > That seems like a very strange decision, but it's obviously up to
> > you
> > :)
> >
>
> Care to elaborate ?
Well, for example, you won't be able to do SAE, the upcoming FILS or
generally have any control over what's going on in the auth/assoc
handshake, since the kernel's version thereof is really really simple.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: fix rx-rate report when rate is invalid.
From: Johannes Berg @ 2016-12-07 9:07 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1480975935-12760-1-git-send-email-greearb@candelatech.com>
On Mon, 2016-12-05 at 14:12 -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> This fixes obtaining the rate info via sta_set_sinfo
> when the rx rate is invalid (for instance, on IBSS
> interface that has received no frames from one of its
> peers).
Please fix this completely while at it, i.e.
make sta_set_rate_info_rx() have a return value and don't set
the BIT(NL80211_STA_INFO_RX_BITRATE) when there's no known rate.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Remove invalid flag operations in mesh TSF synchronization
From: Johannes Berg @ 2016-12-07 9:24 UTC (permalink / raw)
To: Thomas Pedersen, Masashi Honma; +Cc: Bob Copeland, linux-wireless
In-Reply-To: <CADjYELw=-LEqDra0pM+3FjtJDve+NiNYEMz5=F0i5Ge-5k3LaA@mail.gmail.com>
Hi,
I'm not sure what to do with this now :)
> > There are two functionalities.
> >
> > 1) 13.13.2.2 Neighbor offset synchronization method
> > 2) 13.13.4.4 TBTT adjustment
Yes, this much is obvious.
> > The flag is updated by 2).
Yes, the definition of the flag says:
"The TBTT Adjusting subfield is set to 1 while the TBTT adjustment
procedure is ongoing, and is set to 0 otherwise. (See 13.13.4.4.3.)"
(802.11-2012 8.4.2.100.8 Mesh Capability)
> > 13.13.4.4.3 TBTT scanning and adjustment procedures:
> > The mesh STA shall set the TBTT Adjusting field in the Mesh
> > Configuration element to 1 in order to announce that the TBTT
> > adjustment procedure is ongoing.
That's saying the same thing again, I guess :)
> > And the flag is refered by 1) as you said.
> >
> >
> > The purpose of the flag is to prevent 1) while 2) is ongoing.
> >
> > In other words, 1) has only read access authority to the flag.
> > However,
> > previous code updated the flag in 1). In addition, there is no code
> > for
> > 2). So I just remove the invalid accessing codes.
>
> I don't think 1) has read only access to that flag. A TSF adjust will
> by definition move the TBTT as well.
It seems that the wording in the spec disagrees with that - it says
(twice) to set the bit only while the TBTT adjustment procedure is
ongoing, which isn't the case here?
Then again, what exactly *is* this code doing?
It's called mesh_sync_offset_adjust_tbtt() which matches more closely
"TBTT adjustment" than "neighbor offset synchronization"? The code
looks more like offset synchronization though. Perhaps there's some
confusing and it's kinda doing both?
johannes
^ permalink raw reply
* Re: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Johannes Berg @ 2016-12-07 9:25 UTC (permalink / raw)
To: Jouni Malinen; +Cc: linux-wireless, vamsi krishna
In-Reply-To: <1480715949-20169-2-git-send-email-jouni@qca.qualcomm.com>
> v2: address comments from Luca, Arend, and Johannes
What about Arend's comment regarding this functionality overlapping
with the BSS selection offload configuration?
Do you think there's any ability to share attributes/functionality?
johannes
^ permalink raw reply
* RE: [PATCH v2 2/2] cfg80211: Add support to sched scan to report better BSSs
From: Vamsi, Krishna @ 2016-12-07 9:33 UTC (permalink / raw)
To: Johannes Berg, Malinen, Jouni; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <1481102727.4092.34.camel@sipsolutions.net>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKb2hhbm5lcyBCZXJnIFttYWls
dG86am9oYW5uZXNAc2lwc29sdXRpb25zLm5ldF0NCg0KPiBXaGF0IGFib3V0IEFyZW5kJ3MgY29t
bWVudCByZWdhcmRpbmcgdGhpcyBmdW5jdGlvbmFsaXR5IG92ZXJsYXBwaW5nIHdpdGggdGhlDQo+
IEJTUyBzZWxlY3Rpb24gb2ZmbG9hZCBjb25maWd1cmF0aW9uPw0KPiANCj4gRG8geW91IHRoaW5r
IHRoZXJlJ3MgYW55IGFiaWxpdHkgdG8gc2hhcmUgYXR0cmlidXRlcy9mdW5jdGlvbmFsaXR5Pw0K
DQpIaSBKb2hhbm5lcywNCg0KSSB0aGluayB0aGUgbGF0ZXIgY29tbWVudCBmcm9tIEx1Y2Egb24g
dGhpcyB3aGljaCBJIHBhc3RlZCBiZWxvdyBpcyBtb3JlIGFncmVlYWJsZS4NCg0KWWVzLCBzaW1p
bGFyIGJ1dCBub3QgcXVpdGUgdGhlIHNhbWUuICBUaGUgZXhpc3RpbmcgY2FzZSBpcyBmb3IgZmlu
ZGluZyBCU1NzIHRoYXQgYXJlIHdvcnRoIHdha2luZyB0aGUgaG9zdCB1cCBmb3IgKHdoaWxlIGRp
c2Nvbm5lY3RlZCksIHNvIGl0IG5lZWRzIHRvIGJlIGJldHRlciB0aGFuIHRoZSBSU1NJIHBhc3Nl
ZCAoYWJzb2x1dGUgbnVtYmVyKS4gIE5vdyB0aGlzIGlzIGFib3V0IHJlbGF0aXZlIFJTU0kgYXMg
Y29tcGFyZWQgdG8gdGhlIGN1cnJlbnQgY29ubmVjdGlvbiwgc28gUkVMQVRJVkVfUlNTSSBpcyBk
aWZmZXJlbnQgdGhhbiBSU1NJIGFuZCBJIHRoaW5rIHRoZSBzYW1lIGF0dHJpYnV0ZSBzaG91bGQg
bm90IGJlIHVzZWQsIHRvIGF2b2lkIGNvbmZ1c2lvbi4NCg0KVGhhbmtzLA0KVmFtc2kNCg==
^ permalink raw reply
* Re: [PATCH v2 2/2] mac80211: Show pending txqlen in debugfs.
From: Johannes Berg @ 2016-12-07 9:36 UTC (permalink / raw)
To: greearb, linux-wireless
In-Reply-To: <1480964310-16698-2-git-send-email-greearb@candelatech.com>
On Mon, 2016-12-05 at 10:58 -0800, greearb@candelatech.com wrote:
> From: Ben Greear <greearb@candelatech.com>
>
> Could be useful for debugging memory consumption issues,
> and perhaps power-save as well.
Applied this one, but I tend to agree with Felix about the ethtool
stuff, so I've dropped that.
FWIW, we have cfg80211_get_station() now (maybe we could extend that
and provide an iterator as well), so instead of carrying patches you
could also have a small additional module that uses the existing APIs
to get the data, since nl80211 seems to somehow be so problematic for
you.
johannes
^ permalink raw reply
* Re: [PATCH] mac80211: Ensure enough headroom when forwarding mesh pkt
From: Johannes Berg @ 2016-12-07 9:40 UTC (permalink / raw)
To: Cedric Izoard, linux-wireless@vger.kernel.org; +Cc: Laurent Trarieux
In-Reply-To: <356db1fcf788467f9145abc10e218d66@ceva-dsp.com>
> - fwd_skb = skb_copy(skb, GFP_ATOMIC);
> + if (skb_headroom(skb) >= local->tx_headroom)
> + fwd_skb = skb_copy(skb, GFP_ATOMIC);
> + else
> + fwd_skb = skb_copy_expand(skb, local->tx_headroom,
> + 0, GFP_ATOMIC);
Why bother making this conditional? It seems that always using
skb_copy_expand() should be sufficient? The code between the two
(skb_copy, skb_copy_expand) is almost identical anyway, apart from the
latter setting the headroom (and tailroom).
johannes
^ permalink raw reply
* Re: [PATCH][RFC] cfg80211: NL80211_ATTR_SOCKET_OWNER support for CMD_CONNECT
From: Andrew Zaborowski @ 2016-12-07 9:49 UTC (permalink / raw)
To: Johannes Berg; +Cc: Denis Kenzior, linux-wireless
In-Reply-To: <1481091554.4092.7.camel@sipsolutions.net>
On 7 December 2016 at 07:19, Johannes Berg <johannes@sipsolutions.net> wrote:
>> Possibly Johanness refers to the fact that if you use
>> CMD_AUTHENTICATE, or if you use CMD_CONNECT but the driver implements
>> the SME -- doesn't use the cfg80211 software SME -- then
>> cfg80211_disconnect won't do anything if we're not associated, only
>> authenticated. Currently cfg80211 doesn't have knowledge of whether
>> it is authenticated and where to.
>
> We used to track it, but it was a nightmare and just always buggy :)
>
>> With the software SME current_bss would be set from the moment the
>> authentication attempt starts,
>
> I'm almost certain this isn't true, what makes you think so?
Ok, I think I misread the code, indeed it looks consistent between the
driver SME and cfg80211 SME.
I'm fine only adding the socket owner flag to CMD_ASSOCIATE and
CMD_CONNECT. I'll need to store the bssid of the association in
progress so we can send the Deauthenticate if the socket is closed
before association finishes.
>
>> so there seems to be an inconsistency
>> which would affect for example the NL80211_BSS_STATUS_ASSOCIATED
>> flags in the result of CMD_GET_SCAN.
>
> Thus this can't be the case.
>
>> Perhaps this can be fixed by always
>> setting current_bss on auth attempt start, with flags to indicate
>> whether authentication has happened and whether association happened.
>
> No! That would be wrong!
>
>> At the very least with this patch if you set the socket owner during
>> CMD_AUTHENTICATE and then separately associate, you'd get the
>> expected deauthentication.
>
> That would *NOT* be expected. There's no need to even authenticate
> through CMD_AUTHENTICATE at all to connect to (another) AP!
>
> You need to think beyond the 1996 version of 802.11 ;-)
Best regards
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox