* Re: pull-request: mac80211-next 2019-08-21
From: David Miller @ 2019-08-21 20:02 UTC (permalink / raw)
To: johannes; +Cc: netdev, linux-wireless
In-Reply-To: <20190821100424.13682-1-johannes@sipsolutions.net>
From: Johannes Berg <johannes@sipsolutions.net>
Date: Wed, 21 Aug 2019 12:04:23 +0200
> For -next, we have more changes, but as described in the tag
> they really just fall into a few groups of changes :-)
>
> Please pull and let me know if there's any problem.
Also pulled, thanks.
^ permalink raw reply
* Re: Implementing Mikrotik IE
From: Josef Miegl @ 2019-08-21 20:04 UTC (permalink / raw)
To: Johannes Berg; +Cc: Sebastian Gottschall, linux-wireless
In-Reply-To: <b3b7a99971f1512b4cd9c72920b699c252c1ae83.camel@sipsolutions.net>
On August 19, 2019 10:21:55 PM GMT+02:00, Johannes Berg <johannes@sipsolutions.net> wrote:
>I don't know, try capturing over the air?
>
>Perhaps the vendor IEs added this way are added *first* before all the
>RSN IEs, and that's tripping up your AP, and you'd have to add them
>*after* the normal elements? Not really sure where/how they're added?
>
>johannes
The vendor elements are added at the very end of the frame. In fact I tried moving the RSN IE to the end of the frame so that the frame is similar to the one ubnt airos produces. No luck either. One thing I've learned is that ubnt airos assoc req frames have the WMM/WME IE placed before HT Capabilities. But I'm not sure how to move it and also not sure if it would actually work.
I am getting 4WAY_HANDSHAKE_TIMEOUT. From capturing I can see the station sends Key (msg 2 of 4) and a bunch of acknowledgements, but it never sends Key (msg 4 of 4) afterwards.
I feel like I'm stuck.. What could be the reason for this behaviour?
Josef
^ permalink raw reply
* Re: Implementing Mikrotik IE
From: Sebastian Gottschall @ 2019-08-21 20:09 UTC (permalink / raw)
To: Josef Miegl, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <A3C14EA9-BA2D-4745-BBB9-E10028B6DE13@miegl.cz>
Am 21.08.2019 um 22:04 schrieb Josef Miegl:
> On August 19, 2019 10:21:55 PM GMT+02:00, Johannes Berg <johannes@sipsolutions.net> wrote:
>> I don't know, try capturing over the air?
>>
>> Perhaps the vendor IEs added this way are added *first* before all the
>> RSN IEs, and that's tripping up your AP, and you'd have to add them
>> *after* the normal elements? Not really sure where/how they're added?
>>
>> johannes
> The vendor elements are added at the very end of the frame. In fact I tried moving the RSN IE to the end of the frame so that the frame is similar to the one ubnt airos produces. No luck either. One thing I've learned is that ubnt airos assoc req frames have the WMM/WME IE placed before HT Capabilities. But I'm not sure how to move it and also not sure if it would actually work.
>
> I am getting 4WAY_HANDSHAKE_TIMEOUT. From capturing I can see the station sends Key (msg 2 of 4) and a bunch of acknowledgements, but it never sends Key (msg 4 of 4) afterwards.
>
> I feel like I'm stuck.. What could be the reason for this behaviour?
i can just tell you that i added the mikrotik ie just before the wmm ie
but after ht/vht ie
> Josef
>
^ permalink raw reply
* Re: Implementing Mikrotik IE
From: Johannes Berg @ 2019-08-21 20:12 UTC (permalink / raw)
To: Josef Miegl; +Cc: Sebastian Gottschall, linux-wireless
In-Reply-To: <A3C14EA9-BA2D-4745-BBB9-E10028B6DE13@miegl.cz>
On Wed, 2019-08-21 at 22:04 +0200, Josef Miegl wrote:
>
> The vendor elements are added at the very end of the frame. In fact I
> tried moving the RSN IE to the end of the frame so that the frame is
> similar to the one ubnt airos produces. No luck either. One thing I've
> learned is that ubnt airos assoc req frames have the WMM/WME IE placed
> before HT Capabilities. But I'm not sure how to move it and also not
> sure if it would actually work.
>
> I am getting 4WAY_HANDSHAKE_TIMEOUT. From capturing I can see the
> station sends Key (msg 2 of 4) and a bunch of acknowledgements, but it
> never sends Key (msg 4 of 4) afterwards.
>
> I feel like I'm stuck.. What could be the reason for this behaviour?
What AP are you trying to connect to? Have you tried adding some other
random vendor IE, with an OUI that the AP is almost certain to not know?
Maybe it's actually interpreting this somehow?
Would you be willing to show sniffer captures so we could take a look?
johannes
^ permalink raw reply
* Regression with commit "ath10k: fill the channel survey results for WCN3990 correctly"
From: Ben Greear @ 2019-08-21 20:56 UTC (permalink / raw)
To: ath10k, pillair, linux-wireless@vger.kernel.org
Hello,
I just noticed in 5.2.7+ kernel than this commit below appears to break WMI
message for my 10.1 firmware, and based on code inspection, 10.2 will be broken
as well.
10.1 struct ends with cycle_count, and 10.2 ends with one 32-bit number
after that, but which is not chan_tx_pwr_range.
I guess you need to create your own wmi msg for the WCN3990.
The change to 10.4 chan_info event is also wrong for my relatively
new version of 10.4 code, so likely breaks firmware in use. last member
in that struct in my 10.4 fw src is 'A_UINT32 rx_11b_mode_data_duration;'
commit 13104929d2ec32aec0552007d55b9e15bc07176b
Author: Rakesh Pillai <pillair@codeaurora.org>
Date: Wed Oct 17 16:50:03 2018 +0530
ath10k: fill the channel survey results for WCN3990 correctly
diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
index 4971d61..58e33ab 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.h
+++ b/drivers/net/wireless/ath/ath10k/wmi.h
@@ -6442,6 +6442,14 @@ struct wmi_chan_info_event {
__le32 noise_floor;
__le32 rx_clear_count;
__le32 cycle_count;
+ __le32 chan_tx_pwr_range;
+ __le32 chan_tx_pwr_tp;
+ __le32 rx_frame_count;
+ __le32 my_bss_rx_cycle_count;
+ __le32 rx_11b_mode_data_duration;
+ __le32 tx_frame_cnt;
+ __le32 mac_clk_mhz;
+
} __packed;
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply related
* Re: Regression with commit "ath10k: fill the channel survey results for WCN3990 correctly"
From: Ben Greear @ 2019-08-21 21:06 UTC (permalink / raw)
To: ath10k, pillair, linux-wireless@vger.kernel.org
In-Reply-To: <5D5DAFE4.6080706@candelatech.com>
On 08/21/2019 01:56 PM, Ben Greear wrote:
> Hello,
>
> I just noticed in 5.2.7+ kernel than this commit below appears to break WMI
> message for my 10.1 firmware, and based on code inspection, 10.2 will be broken
> as well.
>
> 10.1 struct ends with cycle_count, and 10.2 ends with one 32-bit number
> after that, but which is not chan_tx_pwr_range.
>
> I guess you need to create your own wmi msg for the WCN3990.
>
> The change to 10.4 chan_info event is also wrong for my relatively
> new version of 10.4 code, so likely breaks firmware in use. last member
> in that struct in my 10.4 fw src is 'A_UINT32 rx_11b_mode_data_duration;'
Sorry, I mis-read this 10.4 part of the patch, it was not changing the wmi event
itself, so probably that part is fine.
Thanks,
Ben
>
>
> commit 13104929d2ec32aec0552007d55b9e15bc07176b
> Author: Rakesh Pillai <pillair@codeaurora.org>
> Date: Wed Oct 17 16:50:03 2018 +0530
>
> ath10k: fill the channel survey results for WCN3990 correctly
>
>
>
> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
> index 4971d61..58e33ab 100644
> --- a/drivers/net/wireless/ath/ath10k/wmi.h
> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
> @@ -6442,6 +6442,14 @@ struct wmi_chan_info_event {
> __le32 noise_floor;
> __le32 rx_clear_count;
> __le32 cycle_count;
> + __le32 chan_tx_pwr_range;
> + __le32 chan_tx_pwr_tp;
> + __le32 rx_frame_count;
> + __le32 my_bss_rx_cycle_count;
> + __le32 rx_11b_mode_data_duration;
> + __le32 tx_frame_cnt;
> + __le32 mac_clk_mhz;
> +
> } __packed;
>
>
>
> Thanks,
> Ben
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Regression with commit "ath10k: fill the channel survey results for WCN3990 correctly"
From: Rakesh Pillai @ 2019-08-21 21:12 UTC (permalink / raw)
To: Ben Greear; +Cc: ath10k, linux-wireless
In-Reply-To: <5D5DB246.7040402@candelatech.com>
Hi Ben,
Can you please check https://patchwork.kernel.org/patch/10844513/ ?
This change fixes the below mentioned regression. A different structure
is made for tlv specific event handling.
Thanks,
Rakesh Pillai.
On 2019-08-21 14:06, Ben Greear wrote:
> On 08/21/2019 01:56 PM, Ben Greear wrote:
>> Hello,
>>
>> I just noticed in 5.2.7+ kernel than this commit below appears to
>> break WMI
>> message for my 10.1 firmware, and based on code inspection, 10.2 will
>> be broken
>> as well.
>>
>> 10.1 struct ends with cycle_count, and 10.2 ends with one 32-bit
>> number
>> after that, but which is not chan_tx_pwr_range.
>>
>> I guess you need to create your own wmi msg for the WCN3990.
>>
>> The change to 10.4 chan_info event is also wrong for my relatively
>> new version of 10.4 code, so likely breaks firmware in use. last
>> member
>> in that struct in my 10.4 fw src is 'A_UINT32
>> rx_11b_mode_data_duration;'
>
> Sorry, I mis-read this 10.4 part of the patch, it was not changing the
> wmi event
> itself, so probably that part is fine.
>
> Thanks,
> Ben
>
>>
>>
>> commit 13104929d2ec32aec0552007d55b9e15bc07176b
>> Author: Rakesh Pillai <pillair@codeaurora.org>
>> Date: Wed Oct 17 16:50:03 2018 +0530
>>
>> ath10k: fill the channel survey results for WCN3990 correctly
>>
>>
>>
>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h
>> b/drivers/net/wireless/ath/ath10k/wmi.h
>> index 4971d61..58e33ab 100644
>> --- a/drivers/net/wireless/ath/ath10k/wmi.h
>> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
>> @@ -6442,6 +6442,14 @@ struct wmi_chan_info_event {
>> __le32 noise_floor;
>> __le32 rx_clear_count;
>> __le32 cycle_count;
>> + __le32 chan_tx_pwr_range;
>> + __le32 chan_tx_pwr_tp;
>> + __le32 rx_frame_count;
>> + __le32 my_bss_rx_cycle_count;
>> + __le32 rx_11b_mode_data_duration;
>> + __le32 tx_frame_cnt;
>> + __le32 mac_clk_mhz;
>> +
>> } __packed;
>>
>>
>>
>> Thanks,
>> Ben
>>
^ permalink raw reply
* Re: Regression with commit "ath10k: fill the channel survey results for WCN3990 correctly"
From: Ben Greear @ 2019-08-21 21:15 UTC (permalink / raw)
To: Rakesh Pillai; +Cc: ath10k, linux-wireless
In-Reply-To: <c77c271a3d77d990b8de67cdbd8ea8c7@codeaurora.org>
Looks like it should work.
Why is this rotting in patchwork?
Thanks
Ben
On 08/21/2019 02:12 PM, Rakesh Pillai wrote:
> Hi Ben,
> Can you please check https://patchwork.kernel.org/patch/10844513/ ?
> This change fixes the below mentioned regression. A different structure is made for tlv specific event handling.
>
> Thanks,
> Rakesh Pillai.
>
>
> On 2019-08-21 14:06, Ben Greear wrote:
>> On 08/21/2019 01:56 PM, Ben Greear wrote:
>>> Hello,
>>>
>>> I just noticed in 5.2.7+ kernel than this commit below appears to break WMI
>>> message for my 10.1 firmware, and based on code inspection, 10.2 will be broken
>>> as well.
>>>
>>> 10.1 struct ends with cycle_count, and 10.2 ends with one 32-bit number
>>> after that, but which is not chan_tx_pwr_range.
>>>
>>> I guess you need to create your own wmi msg for the WCN3990.
>>>
>>> The change to 10.4 chan_info event is also wrong for my relatively
>>> new version of 10.4 code, so likely breaks firmware in use. last member
>>> in that struct in my 10.4 fw src is 'A_UINT32 rx_11b_mode_data_duration;'
>>
>> Sorry, I mis-read this 10.4 part of the patch, it was not changing the wmi event
>> itself, so probably that part is fine.
>>
>> Thanks,
>> Ben
>>
>>>
>>>
>>> commit 13104929d2ec32aec0552007d55b9e15bc07176b
>>> Author: Rakesh Pillai <pillair@codeaurora.org>
>>> Date: Wed Oct 17 16:50:03 2018 +0530
>>>
>>> ath10k: fill the channel survey results for WCN3990 correctly
>>>
>>>
>>>
>>> diff --git a/drivers/net/wireless/ath/ath10k/wmi.h b/drivers/net/wireless/ath/ath10k/wmi.h
>>> index 4971d61..58e33ab 100644
>>> --- a/drivers/net/wireless/ath/ath10k/wmi.h
>>> +++ b/drivers/net/wireless/ath/ath10k/wmi.h
>>> @@ -6442,6 +6442,14 @@ struct wmi_chan_info_event {
>>> __le32 noise_floor;
>>> __le32 rx_clear_count;
>>> __le32 cycle_count;
>>> + __le32 chan_tx_pwr_range;
>>> + __le32 chan_tx_pwr_tp;
>>> + __le32 rx_frame_count;
>>> + __le32 my_bss_rx_cycle_count;
>>> + __le32 rx_11b_mode_data_duration;
>>> + __le32 tx_frame_cnt;
>>> + __le32 mac_clk_mhz;
>>> +
>>> } __packed;
>>>
>>>
>>>
>>> Thanks,
>>> Ben
>>>
>
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Implementing Mikrotik IE
From: Josef Miegl @ 2019-08-21 21:17 UTC (permalink / raw)
To: Johannes Berg; +Cc: Sebastian Gottschall, linux-wireless
In-Reply-To: <6efb9b56c77cd9ea945f89c3371b49c301dc2b4e.camel@sipsolutions.net>
On August 21, 2019 10:12:26 PM GMT+02:00, Johannes Berg <johannes@sipsolutions.net> wrote:
>What AP are you trying to connect to? Have you tried adding some other
>random vendor IE, with an OUI that the AP is almost certain to not
>know?
>Maybe it's actually interpreting this somehow?
>
>Would you be willing to show sniffer captures so we could take a look?
>
>johannes
Of course it's interpreting the IE. Random vendor IE works fine. Let me explain why I'm even bothering with sending this mikrotik IE in association requests. The Mikrotik IE has a flag that tells the AP if the station wants WDS. Setting that flag and sending the mikrotik IE is required for transparent bridging with a mikrotik AP.
Sending the Mikrotik IE with the WDS bit set to 0 works fine. Now I'm sure this is a problem on Mikrotiks side, however in ubnts airos this works as expected, and since their airos is probably based on openwrt there has to be a way to make this work.
I will send you the captures, however there doesn't seem to be anything much interesting in them.
Josef
^ permalink raw reply
* Re: Implementing Mikrotik IE
From: Josef Miegl @ 2019-08-21 21:19 UTC (permalink / raw)
To: Johannes Berg, Sebastian Gottschall; +Cc: linux-wireless
In-Reply-To: <bb0d7dd87a7821df245919c86458bd50a3d1a81e.camel@sipsolutions.net>
Forgot to add:
This is what the mikrotik AP reports:
Disconnecting, unicast key exchamge timeout
Josef
^ permalink raw reply
* Re: [linuxwifi] Intel Centrino Ultimate N 6300 regression
From: Alexander Wetzel @ 2019-08-21 21:45 UTC (permalink / raw)
To: Nigel Sollars, Luciano Coelho; +Cc: linuxwifi, linux-wireless
In-Reply-To: <CAG6aBkW09YFz4asHZkhWBUenBiT3dgb7iGXBCq8KkCM09QXjLg@mail.gmail.com>
>> So I have been trying to reach out in aim to get this driver fixed as its regressed now to a total non working state.
>>
>> The card can see access points, but thats about as good as it gets as trying to connect to any networks ( either 2.4 ot 5 Ghz ) results in the following,
>>
>> wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
>>
>> ( alot of these ) which then resets connection status with a failed timeout.
>>
>> I am currently running FedoraCore 30 with the 5.2.5-200 kernel updated from 5.1.x yesterday. The firmware loaded is,
>>
>> loaded firmware version 9.221.4.1 build 25532 op_mode iwldvm
>>
>> Now with all that said, using a Linux Mint live boot from a usb device yeilds the card working fine at both 2.4 and 5ghz speeds, it connects within seconds. The kernal in this live boot is 4.15.x and uses the same firmware build as my FC install.
I'm also using a "Intel Corporation Centrino Ultimate-N 6300 (rev 3e)"
card and it's working perfectly with 5.3.0-rc4-wt here.
(And with most wireless-testing kernels for the last years, too..)
Now there was one noteworthy bug in the last year we handled on the
mailing list:
https://lore.kernel.org/linux-wireless/87k1rk1af5.fsf@kamboji.qca.qualcomm.com/
But then this was a null pointer and does not match to what you observe.
(And that really should be fixed in any 5.2 kernel...)
I'm using a Gentoo ~amd64 system and wpa_supplicant more or less
tracking git upstream and the wireless-testing kernels with the same
firmware as you.
So whatever it is, it's not affecting me. I would suggest to try a
vanilla 5.2 kernel and maybe also an updated wpa_supplicant version next...
Alexander
^ permalink raw reply
* Re: Implementing Mikrotik IE
From: Josef Miegl @ 2019-08-21 23:57 UTC (permalink / raw)
To: Sebastian Gottschall, Johannes Berg; +Cc: linux-wireless
In-Reply-To: <8ec8202e-ca07-3594-5873-5b282d553711@newmedia-net.de>
On August 20, 2019 2:36:21 PM GMT+02:00, Sebastian Gottschall <s.gottschall@newmedia-net.de> wrote:
>i know. thats why i never even tried to contribute it upstream. but
>from
>hostapd side it was more complicated than just hacking mac80211
>and from stations a second mod for wpa_supplicant would be needed and
>since the dd-wrt webgui just uses nl80211 to show the station table
>its more comportable and takes less code just todo it within the driver
>i there is special interest in it i could of course try to clean it up
>and make a upstream patch out of it
I don't think something like Mikrotiks IE belongs to hostapd. The cleanest solution is probably parsing the IE and generating the IE for hostapd with an external tool, that can the dd-wrt GUI then use. I've made a simple C program for this, can share if you want.
Josef
Josef
^ permalink raw reply
* Re: [linuxwifi] Intel Centrino Ultimate N 6300 regression
From: Nigel Sollars @ 2019-08-22 0:12 UTC (permalink / raw)
To: Alexander Wetzel; +Cc: Luciano Coelho, linuxwifi, linux-wireless
In-Reply-To: <4e63174a-34cc-cebf-4eb9-205f0d237574@wetzel-home.de>
Interesting to be sure, so here are the versions of kernel and wpa_supplicant,
5.2.9-200.fc30.x86_64
wpa_supplicant-2.8-2.fc30.x86_64
On Wed, Aug 21, 2019 at 5:45 PM Alexander Wetzel
<alexander@wetzel-home.de> wrote:
>
> >> So I have been trying to reach out in aim to get this driver fixed as its regressed now to a total non working state.
> >>
> >> The card can see access points, but thats about as good as it gets as trying to connect to any networks ( either 2.4 ot 5 Ghz ) results in the following,
> >>
> >> wlp3s0: CTRL-EVENT-SCAN-FAILED ret=-22 retry=1
> >>
> >> ( alot of these ) which then resets connection status with a failed timeout.
> >>
> >> I am currently running FedoraCore 30 with the 5.2.5-200 kernel updated from 5.1.x yesterday. The firmware loaded is,
> >>
> >> loaded firmware version 9.221.4.1 build 25532 op_mode iwldvm
> >>
> >> Now with all that said, using a Linux Mint live boot from a usb device yeilds the card working fine at both 2.4 and 5ghz speeds, it connects within seconds. The kernal in this live boot is 4.15.x and uses the same firmware build as my FC install.
>
> I'm also using a "Intel Corporation Centrino Ultimate-N 6300 (rev 3e)"
> card and it's working perfectly with 5.3.0-rc4-wt here.
> (And with most wireless-testing kernels for the last years, too..)
>
> Now there was one noteworthy bug in the last year we handled on the
> mailing list:
> https://lore.kernel.org/linux-wireless/87k1rk1af5.fsf@kamboji.qca.qualcomm.com/
>
> But then this was a null pointer and does not match to what you observe.
> (And that really should be fixed in any 5.2 kernel...)
>
> I'm using a Gentoo ~amd64 system and wpa_supplicant more or less
> tracking git upstream and the wireless-testing kernels with the same
> firmware as you.
>
> So whatever it is, it's not affecting me. I would suggest to try a
> vanilla 5.2 kernel and maybe also an updated wpa_supplicant version next...
>
> Alexander
--
“Science is a differential equation. Religion is a boundary condition.”
Alan Turing
^ permalink raw reply
* RE: [PATCH] rtw88: pci: enable MSI interrupt
From: Tony Chuang @ 2019-08-22 2:26 UTC (permalink / raw)
To: Brian Norris
Cc: kvalo@codeaurora.org, linux-wireless@vger.kernel.org,
jano.vesely@gmail.com
In-Reply-To: <CA+ASDXPFVHaXM_5VtWNeTW8mPSZi6EX9JYoJRn4RTygA6iKQpg@mail.gmail.com>
> On Behalf Of Brian Norris
> On Thu, Aug 1, 2019 at 2:21 AM Tony Chuang <yhchuang@realtek.com>
> wrote:
> > > Subject: Re: [PATCH] rtw88: pci: enable MSI interrupt
> > > On Tue, Jul 30, 2019 at 07:50:14PM +0800, yhchuang@realtek.com
> wrote:
> > > > --- a/drivers/net/wireless/realtek/rtw88/pci.c
> > > > +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> > > > @@ -874,6 +878,7 @@ static irqreturn_t rtw_pci_interrupt_handler(int
> irq,
> > > void *dev)
> > > > if (!rtwpci->irq_enabled)
> > > > goto out;
> > > >
> > > > + rtw_pci_disable_interrupt(rtwdev, rtwpci);
> > >
> > > Why exactly do you have to mask interrupts during the ISR? Is there a
> > > race in rtw_pci_irq_recognized() or something?
> >
> >
> > I think there is a race between SW and HW, if we do not stop the
> > IRQ first, write 1 clear will make the interrupt to be lost.
>
> This doesn't need to slow down this patch (I think v2 is fine), but I
> still don't quite understand. Before this addition, the sequence is:
> (a) read out your IRQ status
> (b) ack the un-masked IRQs you see
> (c) operate on those IRQs
>
> Even if a new IRQ comes in the middle of (b), shouldn't it be
> sufficient to move on to (c), where you're still prepared to handle
> that IRQ?
>
> Or if the IRQ comes after (b), you won't ACK it, and you should
> immediately get a new IRQ after you return?
I think it's because that MSI interrupts are edge-triggered.
If the interrupt comes when IRQ is being processed, the interrupt won't be received.
If the interrupt is not received, the interrupt won't be Write-1-Cleared, and won't be fired again.
So driver should disable the interrupt until the ISRs are done.
>
> I guess that's assuming that these registers are Write 1 to Clear. But
> if so, that means rtw_pci_irq_recognized() is effectively atomic, no?
>
> Also, somewhat unrelated: but why do you unmask HIMR1, when you're not
> actually handling any of its IRQ bits?
We could use HIMR1, just not handling any of them now :)
>
> Brian
>
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH 16/16] iwlwifi: mvm: fix version check for GEO_TX_POWER_LIMIT support
From: Luca Coelho @ 2019-08-22 6:44 UTC (permalink / raw)
To: Jonas Hahnfeld, kvalo; +Cc: linux-wireless
In-Reply-To: <8402552457c387269d3e535b5f2ef42159e17f91.camel@hahnjo.de>
On Thu, 2019-08-01 at 16:07 +0200, Jonas Hahnfeld wrote:
> Am Samstag, den 20.07.2019, 13:25 +0300 schrieb Luca Coelho:
> > From: Luca Coelho <
> > luciano.coelho@intel.com
> >
> > We erroneously added a check for FW API version 41 before sending
> > GEO_TX_POWER_LIMIT, but this was already implemented in version 38.
> > Additionally, it was cherry-picked to older versions, namely 17, 26
> > and 29, so check for those as well.
> >
> > Signed-off-by: Luca Coelho <
> > luciano.coelho@intel.com
> > ---
> > drivers/net/wireless/intel/iwlwifi/mvm/fw.c | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> > index a837cf40afde..00c89bcfdf6a 100644
> > --- a/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> > +++ b/drivers/net/wireless/intel/iwlwifi/mvm/fw.c
> > @@ -886,9 +886,14 @@ static bool iwl_mvm_sar_geo_support(struct iwl_mvm *mvm)
> > * The GEO_TX_POWER_LIMIT command is not supported on earlier
> > * firmware versions. Unfortunately, we don't have a TLV API
> > * flag to rely on, so rely on the major version which is in
> > - * the first byte of ucode_ver.
> > + * the first byte of ucode_ver. This was implemented
> > + * initially on version 38 and then backported to 36, 29 and
> > + * 17.
> > */
> > - return IWL_UCODE_SERIAL(mvm->fw->ucode_ver) >= 41;
> > + return IWL_UCODE_SERIAL(mvm->fw->ucode_ver) >= 38 ||
> > + IWL_UCODE_SERIAL(mvm->fw->ucode_ver) == 36 ||
> > + IWL_UCODE_SERIAL(mvm->fw->ucode_ver) == 29 ||
> > + IWL_UCODE_SERIAL(mvm->fw->ucode_ver) == 17;
> > }
> >
> > int iwl_mvm_get_sar_geo_profile(struct iwl_mvm *mvm)
>
> After pulling iwlwifi-fixes-for-kvalo-2019-07-30, I still get firmware
> crashes on my "Intel(R) Dual Band Wireless AC 8260" which uses firmware
> version 36. I tried the latest ucode in linux-firmware (36.77d01142.0),
> but it seems GEO_TX_POWER_LIMIT is not yet implemented there.
>
> Could you let me know which firmware version I need for Linux 5.3? Can
> there be a check in iwl_mvm_sar_geo_support() that the backported
> support is indeed available?
We have some issues detecting whether the FW supports this command or
not. There is already a bugzilla[1] for this (and a bunch of
duplicates), so let's track it there.
https://bugzilla.kernel.org/show_bug.cgi?id=204151
--
Cheers,
Luca.
^ permalink raw reply
* Re: Regression with the latest iwlwifi 9260 and Canon Point firmware
From: Luciano Coelho @ 2019-08-22 6:50 UTC (permalink / raw)
To: Peter Robinson; +Cc: linux-wireless
In-Reply-To: <CALeDE9Mwtm8fVMm6Ce99aju=UqPPSaZWQR+zZtJodENZ6_m+_Q@mail.gmail.com>
On Mon, 2019-07-29 at 19:49 +0100, Peter Robinson wrote:
> Hi Luca,
>
> Similar to the issues seen in the thread on [1] thje 9260 we're seeing
> the same reports in Fedora on both versions of the firmware [2], on
> both the 9260 series but also the Cannon Point-LP CNVi wifi devices as
> well. There's more details and dmesg output in that bug report.
>
> Do you have an update on the issue?
Hi,
Please check this bugzilla entry:
https://patchwork.kernel.org/patch/11021735/
The bug has been fixed with this patch:
https://patchwork.kernel.org/patch/11021735/
HTH.
--
Cheers,
Luca.
^ permalink raw reply
* Re: Regression with the latest iwlwifi 9260 and Canon Point firmware
From: Luciano Coelho @ 2019-08-22 6:51 UTC (permalink / raw)
To: Peter Robinson; +Cc: linux-wireless
In-Reply-To: <a5b555a03f97a73064bd5d7927dd16379642baa0.camel@intel.com>
On Thu, 2019-08-22 at 09:50 +0300, Luciano Coelho wrote:
> On Mon, 2019-07-29 at 19:49 +0100, Peter Robinson wrote:
> > Hi Luca,
> >
> > Similar to the issues seen in the thread on [1] thje 9260 we're seeing
> > the same reports in Fedora on both versions of the firmware [2], on
> > both the 9260 series but also the Cannon Point-LP CNVi wifi devices as
> > well. There's more details and dmesg output in that bug report.
> >
> > Do you have an update on the issue?
>
> Hi,
>
> Please check this bugzilla entry:
>
> https://patchwork.kernel.org/patch/11021735/
I meant this bugzilla entry:
https://bugzilla.kernel.org/show_bug.cgi?id=204387
--
Luca.
^ permalink raw reply
* Re: Implementing Mikrotik IE
From: Johannes Berg @ 2019-08-22 6:58 UTC (permalink / raw)
To: Josef Miegl, Sebastian Gottschall; +Cc: linux-wireless
In-Reply-To: <E28FAC24-4B21-48FB-A010-770BCEF4CCA1@miegl.cz>
On Thu, 2019-08-22 at 01:57 +0200, Josef Miegl wrote:
> On August 20, 2019 2:36:21 PM GMT+02:00, Sebastian Gottschall <s.gottschall@newmedia-net.de> wrote:
> > i know. thats why i never even tried to contribute it upstream. but
> > from
> > hostapd side it was more complicated than just hacking mac80211
> > and from stations a second mod for wpa_supplicant would be needed and
> > since the dd-wrt webgui just uses nl80211 to show the station table
> > its more comportable and takes less code just todo it within the driver
> > i there is special interest in it i could of course try to clean it up
> > and make a upstream patch out of it
>
> I don't think something like Mikrotiks IE belongs to hostapd. The
> cleanest solution is probably parsing the IE and generating the IE for
> hostapd with an external tool, that can the dd-wrt GUI then use. I've
> made a simple C program for this, can share if you want.
Sebastian was talking about yet another case - namely recording it for
the stations, to be able to show it.
I guess hostapd could be made to just generally record *all* the
association request IEs that a station sent and make those available
over the control interface.
Alternatively, you could have another application just listen to nl80211
events, I guess.
Or even the kernel could capture *all*, but I don't see why we'd waste
unpageable kernel memory for it.
johannes
^ permalink raw reply
* Re: Implementing Mikrotik IE
From: Johannes Berg @ 2019-08-22 7:00 UTC (permalink / raw)
To: Josef Miegl; +Cc: Sebastian Gottschall, linux-wireless
In-Reply-To: <58A25955-2A17-4DE7-82FB-3B20E00C96EC@miegl.cz>
On Wed, 2019-08-21 at 23:17 +0200, Josef Miegl wrote:
> On August 21, 2019 10:12:26 PM GMT+02:00, Johannes Berg <johannes@sipsolutions.net> wrote:
> > What AP are you trying to connect to? Have you tried adding some other
> > random vendor IE, with an OUI that the AP is almost certain to not
> > know?
> > Maybe it's actually interpreting this somehow?
> >
> > Would you be willing to show sniffer captures so we could take a look?
> >
> > johannes
>
> Of course it's interpreting the IE. Random vendor IE works fine.
Ok, that wasn't really clear to me until now.
> Let me explain why I'm even bothering with sending this mikrotik IE in
> association requests. The Mikrotik IE has a flag that tells the AP if
> the station wants WDS. Setting that flag and sending the mikrotik IE
> is required for transparent bridging with a mikrotik AP.
Aha, ok.
> Sending the Mikrotik IE with the WDS bit set to 0 works fine.
Even more curious :-)
> Now I'm sure this is a problem on Mikrotiks side, however in ubnts
> airos this works as expected, and since their airos is probably based
> on openwrt there has to be a way to make this work.
>
> I will send you the captures, however there doesn't seem to be
> anything much interesting in them.
Indeed, it seems unlikely I could get anything from that.
Do you have a successful handshake done by a "real" client
implementation?
Perhaps it expects the 4-way-HS to already be in 4-addr frame format, or
something else special in the 4-way-HS if you have WDS?
johannes
^ permalink raw reply
* Re: [PATCH 5.3] mt76: mt76x0e: don't use hw encryption for MT7630E
From: Felix Fietkau @ 2019-08-22 7:23 UTC (permalink / raw)
To: Stanislaw Gruszka; +Cc: Lorenzo Bianconi, linux-wireless, Ryder Lee, Roy Luo
In-Reply-To: <20190821112244.GA23546@redhat.com>
On 2019-08-21 13:22, Stanislaw Gruszka wrote:
> On Wed, Aug 21, 2019 at 12:40:14PM +0200, Felix Fietkau wrote:
>> On 2019-08-21 11:03, Felix Fietkau wrote:
>> > On 2019-08-21 10:47, Stanislaw Gruszka wrote:
>> >> On Tue, Aug 20, 2019 at 01:24:39PM +0200, Stanislaw Gruszka wrote:
>> >>> > Can you test if disabling hw encryption only for shared or only for
>> >>> > pairwise keys makes any difference?
>> >>>
>> >>> Disabling only pairwise keys helps. Disabling only shared keys does
>> >>> not help.
>> >>>
>> >>> Not sure if this will be helpful information or make things more
>> >>> confusing, but seems the difference between mt76_txq_schedule()
>> >>> and tasklet_schedule() in mt76_wake_tx_queue() is that on
>> >>> mt76_txq_schedule() some tx packets are serialized by dev->rx_lock
>> >>> (because some ARP and TCP packets are sent via network stack as response
>> >>> of incoming packet within ieee80211_rx_napi() call). Removing
>> >>> spin_lock(&dev->rx_lock) in mt76_rx_complete() make the problem
>> >>> reproducible again with mt76_txq_schedule() & HW encryption.
>> >>
>> >> So, I think this is FW/HW issue related with encryption and ordering
>> >> and we should apply patch originally posted in this thread that
>> >> disable HW encryption for MT7630E.
>> >>
>> >> I do not think we should disable HW encryption only for pairwise keys,
>> >> because FW/HW can have the same bug for shared keys, but is not
>> >> triggered in my test, as we do not sent lot of group frames.
>> > I'm still not convinced that this is just the hardware implementation of
>> > hw crypto being faulty. I think it's more likely that there's a bug in
>> > the tx path somewhere, which causes hangs on MT7630E but remains hidden
>> > (or at least recoverable) on other devices.
>> > I'm currently reviewing key handling in the mac80211 fast-xmit codepath
>> > and get the feeling that something might be racy there.
>> > I will let you know when I make some progress with that review.
>> > If we can't find the bug soon, then I'm fine with merging this patch.
>> > Right now, I would like to see first if we can fix it properly.
>> Another question: Does a watchdog restart happen before tx fails?
>
> No, we do not run wdt_work for mt76x0e.
I didn't find anything conclusive yet, so I agree with merging this
patch for now until we have a better fix.
- Felix
^ permalink raw reply
* [PATCH 1/2] mt76: dma: reset q->rx_head on rx reset
From: Felix Fietkau @ 2019-08-22 7:33 UTC (permalink / raw)
To: linux-wireless
Fixes rx of the first frame if a fragmented rx was interrupted by the reset
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/dma.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
index 46f5223b4d89..c747eb24581c 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -431,6 +431,12 @@ mt76_dma_rx_reset(struct mt76_dev *dev, enum mt76_rxq_id qid)
mt76_dma_rx_cleanup(dev, q);
mt76_dma_sync_idx(dev, q);
mt76_dma_rx_fill(dev, q);
+
+ if (!q->rx_head)
+ return;
+
+ dev_kfree_skb(q->rx_head);
+ q->rx_head = NULL;
}
static void
--
2.17.0
^ permalink raw reply related
* [PATCH 2/2] mt76: stop rx aggregation on station removal
From: Felix Fietkau @ 2019-08-22 7:33 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <20190822073305.37840-1-nbd@nbd.name>
Fixes use-after-free issues on forced station removal during hardware restart
on MT76x02
Fixes: aee5b8cf2477 ("mt76: implement A-MPDU rx reordering in the driver code")
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index aeb535204c4d..32ddbf088817 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -708,6 +708,9 @@ void __mt76_sta_remove(struct mt76_dev *dev, struct ieee80211_vif *vif,
rcu_assign_pointer(dev->wcid[idx], NULL);
synchronize_rcu();
+ for (i = 0; i < ARRAY_SIZE(wcid->aggr); i++)
+ mt76_rx_aggr_stop(dev, wcid, i);
+
if (dev->drv->sta_remove)
dev->drv->sta_remove(dev, vif, sta);
--
2.17.0
^ permalink raw reply related
* Re: [PATCH 1/1] [MT76x02] [STA interface]
From: Felix Fietkau @ 2019-08-22 7:40 UTC (permalink / raw)
To: Balakrishna Bandi, lorenzo.bianconi83; +Cc: linux-wireless
In-Reply-To: <1566315751-7688-1-git-send-email-b.balakrishna@globaledgesoft.com>
On 2019-08-20 17:42, Balakrishna Bandi wrote:
> MT76-Station sends class 3 frames after deauthentication from 3rd party AP
> (Sending BAR frame after deauth).
>
> Fix to be, do not send BAR frame after deauth.
>
> Signed-off-by: Balakrishna Bandi <b.balakrishna@globaledgesoft.com>
The same issue is also present for MT7615 and MT7603, and the patch
subject line is wrong. I will send a more complete fix
Thanks,
- Felix
^ permalink raw reply
* Re: [PATCH 1/1] [PATCH] Mt76 enabling data pkt transmission.
From: Felix Fietkau @ 2019-08-22 7:45 UTC (permalink / raw)
To: Balakrishna Bandi, lorenzo.bianconi83; +Cc: linux-wireless
In-Reply-To: <1566335498-10977-1-git-send-email-b.balakrishna@globaledgesoft.com>
On 2019-08-20 23:11, Balakrishna Bandi wrote:
> Data Packet transmission was disabled during scanning in mt76 driver.
>
> Fix to be, enabling data packet transmission during scanning.
>
> Note:
> Mac80211 will handle channel switching. During scanning, it handles
> stopping the data transmission on off channel and enabling data
> transmission on operating channel also. It does not require to stop data
> transmission in mt76 driver during scanning. Verified with other driver
> ath9k and rt2x00 driver, data transmission was not stopped during
> scanning
>
> Signed-off-by: Balakrishna Bandi <b.balakrishna@globaledgesoft.com>
> ---
> drivers/net/wireless/mediatek/mt76/tx.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
> index 5397827..376720d 100644
> --- a/drivers/net/wireless/mediatek/mt76/tx.c
> +++ b/drivers/net/wireless/mediatek/mt76/tx.c
> @@ -438,8 +438,7 @@ void mt76_tx_complete_skb(struct mt76_dev *dev, struct sk_buff *skb)
> if (probe)
> break;
>
> - if (test_bit(MT76_OFFCHANNEL, &dev->state) ||
> - test_bit(MT76_RESET, &dev->state))
> + if (test_bit(MT76_RESET, &dev->state))
The patch is incomplete, since this test is done twice in the tx path.
Also, the subject line is wrong. I will send a more complete fix.
Thanks,
- Felix
^ permalink raw reply
* [PATCH] net/wireless: Delete unnecessary checks before the macro call “dev_kfree_skb”
From: Markus Elfring @ 2019-08-22 8:30 UTC (permalink / raw)
To: linux-wireless, linux-arm-kernel, linux-mediatek, ath10k,
David S. Miller, Felix Fietkau, Kalle Valo, Lorenzo Bianconi,
Matthias Brugger, Roy Luo, Ryder Lee, Solomon Peachy,
Stanislaw Gruszka
Cc: LKML, kernel-janitors
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Thu, 22 Aug 2019 10:20:10 +0200
The dev_kfree_skb() function performs also input parameter validation.
Thus the test around the shown calls is not needed.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/net/wireless/ath/ath10k/wmi.c | 4 +---
drivers/net/wireless/intel/iwlegacy/3945-mac.c | 8 ++------
drivers/net/wireless/intel/iwlegacy/common.c | 8 ++------
drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c | 5 +----
drivers/net/wireless/st/cw1200/scan.c | 3 +--
5 files changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c b/drivers/net/wireless/ath/ath10k/wmi.c
index 4f707c6394bb..d384293429b4 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -9440,7 +9440,5 @@ void ath10k_wmi_detach(struct ath10k *ar)
}
cancel_work_sync(&ar->svc_rdy_work);
-
- if (ar->svc_rdy_skb)
- dev_kfree_skb(ar->svc_rdy_skb);
+ dev_kfree_skb(ar->svc_rdy_skb);
}
diff --git a/drivers/net/wireless/intel/iwlegacy/3945-mac.c b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
index b82da75a9ae3..4b3b166f6f2a 100644
--- a/drivers/net/wireless/intel/iwlegacy/3945-mac.c
+++ b/drivers/net/wireless/intel/iwlegacy/3945-mac.c
@@ -2302,9 +2302,7 @@ __il3945_down(struct il_priv *il)
il3945_hw_txq_ctx_free(il);
exit:
memset(&il->card_alive, 0, sizeof(struct il_alive_resp));
-
- if (il->beacon_skb)
- dev_kfree_skb(il->beacon_skb);
+ dev_kfree_skb(il->beacon_skb);
il->beacon_skb = NULL;
/* clear out any free frames */
@@ -3847,9 +3845,7 @@ il3945_pci_remove(struct pci_dev *pdev)
il_free_channel_map(il);
il_free_geos(il);
kfree(il->scan_cmd);
- if (il->beacon_skb)
- dev_kfree_skb(il->beacon_skb);
-
+ dev_kfree_skb(il->beacon_skb);
ieee80211_free_hw(il->hw);
}
diff --git a/drivers/net/wireless/intel/iwlegacy/common.c b/drivers/net/wireless/intel/iwlegacy/common.c
index 73f7bbf742bc..4e7e64f46ea8 100644
--- a/drivers/net/wireless/intel/iwlegacy/common.c
+++ b/drivers/net/wireless/intel/iwlegacy/common.c
@@ -5182,8 +5182,7 @@ il_mac_reset_tsf(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
memset(&il->current_ht_config, 0, sizeof(struct il_ht_config));
/* new association get rid of ibss beacon skb */
- if (il->beacon_skb)
- dev_kfree_skb(il->beacon_skb);
+ dev_kfree_skb(il->beacon_skb);
il->beacon_skb = NULL;
il->timestamp = 0;
@@ -5302,10 +5301,7 @@ il_beacon_update(struct ieee80211_hw *hw, struct ieee80211_vif *vif)
}
spin_lock_irqsave(&il->lock, flags);
-
- if (il->beacon_skb)
- dev_kfree_skb(il->beacon_skb);
-
+ dev_kfree_skb(il->beacon_skb);
il->beacon_skb = skb;
timestamp = ((struct ieee80211_mgmt *)skb->data)->u.beacon.timestamp;
diff --git a/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c b/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c
index d61c686e08de..d6487cd67cca 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76x02_beacon.c
@@ -88,10 +88,7 @@ int mt76x02_mac_set_beacon(struct mt76x02_dev *dev, u8 vif_idx,
for (i = 0; i < ARRAY_SIZE(dev->beacons); i++) {
if (vif_idx == i) {
force_update = !!dev->beacons[i] ^ !!skb;
-
- if (dev->beacons[i])
- dev_kfree_skb(dev->beacons[i]);
-
+ dev_kfree_skb(dev->beacons[i]);
dev->beacons[i] = skb;
__mt76x02_mac_set_beacon(dev, bcn_idx, skb);
} else if (force_update && dev->beacons[i]) {
diff --git a/drivers/net/wireless/st/cw1200/scan.c b/drivers/net/wireless/st/cw1200/scan.c
index c46b044b7f7b..988581cc134b 100644
--- a/drivers/net/wireless/st/cw1200/scan.c
+++ b/drivers/net/wireless/st/cw1200/scan.c
@@ -120,8 +120,7 @@ int cw1200_hw_scan(struct ieee80211_hw *hw,
++priv->scan.n_ssids;
}
- if (frame.skb)
- dev_kfree_skb(frame.skb);
+ dev_kfree_skb(frame.skb);
mutex_unlock(&priv->conf_mutex);
queue_work(priv->workqueue, &priv->scan.work);
return 0;
--
2.23.0
^ permalink raw reply related
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