LinuxLists.cc - [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

[permalink] [raw]

Subject: Re: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

On 28.05.24 00:01, Christian Heusel wrote:
>
> Savyasaachi reports that scanning for other stations in monitor mode
> does not work anymore with his RTL8821CE wireless network card for linux
> kernels after 6.8.9.

Thx for the report. A few remarks:

Please be more specific in cases like this, as "kernels after 6.8.9" can
mean "6.8.10+", "6.10-rc", or "6.9.y" (apparently it is the latter).
Yes, this is nitpicking, which is why I normally would not have said
anything -- but because you frequently report bugs it's likely in
everybody's interest to bring this up.

In a case like this it would also be good if the reporter could give
latest mainline a try, as (1) a fix might already be in there and (2)
some developers do not care at all about bugs in stable kernels (and
they are free to do so!). See
https://linux-regtracking.leemhuis.info/post/frequent-reasons-why-linux-kernel-bug-reports-are-ignored/
for details.

And sorry, there is something else: from the dmesg it looks a lot like
this report is from a patched vendor kernel that among others seems to
enable features like "forced interrupt request threading"
(https://github.com/zen-kernel/zen-kernel/wiki/Detailed-Feature-List ).
Such changes even if small and done carefully can lead to bugs like this
(yes, that particular feature I mentioned can be enabled through a
kernel parameter as well, but some developers would consider this to be
an unsupported configuration). The absolut minimum you should have done
is to mention that; but normally you never want to use such kernels for
reporting bugs upstream, as the problem might not be present in the
upstream code.

Ciao, Thorsten

> His workflow was putting the adapter in monitor mode by running
> "airmon-ng start wlan0" and then capture the surrounding stations with
> "airodump-ng wlan0".
>
> We have bisected the issue together in the issue in the Arch Linux
> bugtracker[0] down to the following commit:
>
> 0a44dfc070749 ("wifi: mac80211: simplify non-chanctx drivers")
>
> Savyasaachi (in CC) offered to be available for questions and further
> debugging in this thread and some general debugging outputs are
> attached/below.
>
> Reported-by: Savyasaachi Vanga <[email protected]>
> Bisected-by: Christian Heusel <[email protected]>
>
> Cheers,
> Chris
>
> [0]: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/54
>
> ---
>
> #regzbot link: https://gitlab.archlinux.org/archlinux/packaging/packages/linux/-/issues/54
> #regzbot introduced: 0a44dfc070749
> #regzbot title: wifi: RTL8821CE does not work in monitor mode
>
> ---
>
> lsusb:
>
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> Bus 003 Device 002: ID 0bda:c829 Realtek Semiconductor Corp. Bluetooth Radio
> Bus 003 Device 003: ID 0c45:6739 Microdia Integrated_Webcam_FHD
> Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>
> lspci:
>
> 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne Root Complex
> 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne IOMMU
> 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
> 00:01.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge
> 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge
> 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
> 00:02.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne PCIe GPP Bridge
> 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Renoir PCIe Dummy Host Bridge
> 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus
> 00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Renoir Internal PCIe GPP Bridge to Bus
> 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 51)
> 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
> 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 0
> 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 1
> 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 2
> 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 3
> 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 4
> 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 5
> 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 6
> 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Cezanne Data Fabric; Function 7
> 01:00.0 Non-Volatile memory controller: Micron Technology Inc 2210 NVMe SSD [Cobain] (rev 03)
> 02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8211/8411 PCI Express Gigabit Ethernet Controller (rev 15)
> 03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe Wireless Network Adapter
> 04:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Barcelo (rev c2)
> 04:00.1 Audio device: Advanced Micro Devices, Inc. [AMD/ATI] Renoir Radeon High Definition Audio Controller
> 04:00.2 Encryption controller: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 10h-1fh) Platform Security Processor
> 04:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne USB 3.1
> 04:00.4 USB controller: Advanced Micro Devices, Inc. [AMD] Renoir/Cezanne USB 3.1
> 04:00.5 Multimedia controller: Advanced Micro Devices, Inc. [AMD] ACP/ACP3X/ACP6x Audio Coprocessor (rev 01)
> 04:00.6 Audio device: Advanced Micro Devices, Inc. [AMD] Family 17h/19h HD Audio Controller
> 05:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 81)
> 05:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 81)

2024-05-28 08:30:48

[permalink] [raw]

Subject: Re: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

On 28.05.24 00:01, Christian Heusel wrote:
>
> Savyasaachi reports that scanning for other stations in monitor mode
> does not work anymore with his RTL8821CE wireless network card for linux
> kernels after 6.8.9.
> [...]

So back to the real problem:

@wifi developers: Is there some bigger problem in 6.9.y related to
monitoring mode that is affecting a lot of drivers/users?

I'm asking because I noticed another report that sounded related. To
quote: https://bugzilla.kernel.org/show_bug.cgi?id=218884

"""
> Michael 2024-05-24 17:04:51 UTC
>
> Some features are broken since kernel 6.9.1 when running monitor mode.
>
> First bug:
> Switching a channel via "NL80211_ATTR_WIPHY_FREQ" does not switch the channel/frequency.
>
> That is not a device driver problem, because all device drivers (Mediatek, Ralink, Realtek, ...) are affected.
>
> To reproduce:
> set monitor mode (by iw)
> change channel (by iw)
> check if channel has been changed (by iw)
> record traffic and check radiotap header (Channel frequency)
>
> More information is here:
> https://github.com/ZerBea/hcxdumptool/discussions/454
> https://github.com/morrownr/8821au-20210708/issues/133#issuecomment-2125425552
> confirmed by other users:
> https://github.com/morrownr/8821au-20210708/issues/133#issuecomment-2125392151
>
>
> Second bug:
> frame injection is broken
>
> To reproduce:
> Try to send a 80211 frame via raw socket (PF_PACKET). It is not transmitted over the air
> https://github.com/ZerBea/hcxdumptool/discussions/454
>
>
> In monitor mode, none of the WiFI tools (iw, Wireshark, airodump-ng, aireplay-ng, hcxdumptool, hcxlabtool is able to switshc the channel or to transmit 80211 frames since kernel 6.9
>
> [tag] [reply] [−]
> Private
> Comment 1 Michael 2024-05-26 09:00:58 UTC
>
> BTW:
> Testing monitor mode mode these days is no easy task, because most of the device drivers are not working as expected:
> https://bugzilla.kernel.org/show_bug.cgi?id=218528
> https://bugzilla.kernel.org/show_bug.cgi?id=217465
> https://bugzilla.kernel.org/show_bug.cgi?id=218528
> https://github.com/openwrt/mt76/issues/839
>
> And now, since kernel 6.9.1, the mac stack is broken, too.
>
"""

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.

2024-05-28 12:16:30

by Christian Heusel

[permalink] [raw]

Subject: Re: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

On 24/05/28 07:22AM, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 28.05.24 00:01, Christian Heusel wrote:
> >
> > Savyasaachi reports that scanning for other stations in monitor mode
> > does not work anymore with his RTL8821CE wireless network card for linux
> > kernels after 6.8.9.
>
> Thx for the report. A few remarks:
>
> Please be more specific in cases like this, as "kernels after 6.8.9" can
> mean "6.8.10+", "6.10-rc", or "6.9.y" (apparently it is the latter).
> Yes, this is nitpicking, which is why I normally would not have said
> anything -- but because you frequently report bugs it's likely in
> everybody's interest to bring this up.
>

Thanks for the remarks! I'll try to improve on giving more specific
information for these things in the future!

>
> In a case like this it would also be good if the reporter could give
> latest mainline a try, as (1) a fix might already be in there and (2)
> some developers do not care at all about bugs in stable kernels (and
> they are free to do so!). See
> https://linux-regtracking.leemhuis.info/post/frequent-reasons-why-linux-kernel-bug-reports-are-ignored/
> for details.
>

The mainline kernel (6.10rc1) does not work aswell as per Savyasaachi's
tests. I have attached the journal from that run to this email.

> And sorry, there is something else: from the dmesg it looks a lot like
> this report is from a patched vendor kernel that among others seems to
> enable features like "forced interrupt request threading"
> (https://github.com/zen-kernel/zen-kernel/wiki/Detailed-Feature-List).
> Such changes even if small and done carefully can lead to bugs like this
> (yes, that particular feature I mentioned can be enabled through a
> kernel parameter as well, but some developers would consider this to be
> an unsupported configuration). The absolut minimum you should have done
> is to mention that; but normally you never want to use such kernels for
> reporting bugs upstream, as the problem might not be present in the
> upstream code.

Yes that one is my bad, this was just a journal I had still lying around
as it was part of the initial stages of the bugreport. The bisection was
of course done on the mainline tree without any additional patchsets
involved and as I said above the journal from the mainline boot is now
attached.

Cheers,
chris

Attachments:

(No filename) (0.00 B)
signature.asc (849.00 B)
Download all attachments

2024-05-31 05:58:24

[permalink] [raw]

Subject: Re: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

On 28.05.24 10:21, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 28.05.24 00:01, Christian Heusel wrote:
>>
>> Savyasaachi reports that scanning for other stations in monitor mode
>> does not work anymore with his RTL8821CE wireless network card for linux
>> kernels after 6.8.9.
>> [...]

Hmm, the wifi developers did not reply to the inquiry quoted below. :-/
Guess I'll have to take a closer look a the linked bugzilla report then.

Anyway: Christian, Savyasaachi, I noticed a submission of a patch
referencing the culprit with a Fixes: tag; it talks about package loss,
but it still made me wonder if that might be related somehow:
https://lore.kernel.org/all/[email protected]/

Ciao, Thorsten

> So back to the real problem:
>
> @wifi developers: Is there some bigger problem in 6.9.y related to
> monitoring mode that is affecting a lot of drivers/users?
>
> I'm asking because I noticed another report that sounded related. To
> quote: https://bugzilla.kernel.org/show_bug.cgi?id=218884
>
> """
>> Michael 2024-05-24 17:04:51 UTC
>>
>> Some features are broken since kernel 6.9.1 when running monitor mode.
>>
>> First bug:
>> Switching a channel via "NL80211_ATTR_WIPHY_FREQ" does not switch the channel/frequency.
>>
>> That is not a device driver problem, because all device drivers (Mediatek, Ralink, Realtek, ...) are affected.
>>
>> To reproduce:
>> set monitor mode (by iw)
>> change channel (by iw)
>> check if channel has been changed (by iw)
>> record traffic and check radiotap header (Channel frequency)
>>
>> More information is here:
>> https://github.com/ZerBea/hcxdumptool/discussions/454
>> https://github.com/morrownr/8821au-20210708/issues/133#issuecomment-2125425552
>> confirmed by other users:
>> https://github.com/morrownr/8821au-20210708/issues/133#issuecomment-2125392151
>>
>>
>> Second bug:
>> frame injection is broken
>>
>> To reproduce:
>> Try to send a 80211 frame via raw socket (PF_PACKET). It is not transmitted over the air
>> https://github.com/ZerBea/hcxdumptool/discussions/454
>>
>>
>> In monitor mode, none of the WiFI tools (iw, Wireshark, airodump-ng, aireplay-ng, hcxdumptool, hcxlabtool is able to switshc the channel or to transmit 80211 frames since kernel 6.9
>>
>> [tag] [reply] [−]
>> Private
>> Comment 1 Michael 2024-05-26 09:00:58 UTC
>>
>> BTW:
>> Testing monitor mode mode these days is no easy task, because most of the device drivers are not working as expected:
>> https://bugzilla.kernel.org/show_bug.cgi?id=218528
>> https://bugzilla.kernel.org/show_bug.cgi?id=217465
>> https://bugzilla.kernel.org/show_bug.cgi?id=218528
>> https://github.com/openwrt/mt76/issues/839
>>
>> And now, since kernel 6.9.1, the mac stack is broken, too.
>>
> """
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> If I did something stupid, please tell me, as explained on that page.
>
>

2024-06-03 00:48:06

[permalink] [raw]

Subject: RE: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

Thorsten Leemhuis <[email protected]> wrote:
> On 28.05.24 10:21, Linux regression tracking (Thorsten Leemhuis) wrote:
> > On 28.05.24 00:01, Christian Heusel wrote:
> >>
> >> Savyasaachi reports that scanning for other stations in monitor mode
> >> does not work anymore with his RTL8821CE wireless network card for linux
> >> kernels after 6.8.9.
> >> [...]
>
> Hmm, the wifi developers did not reply to the inquiry quoted below. :-/
> Guess I'll have to take a closer look a the linked bugzilla report then.
>
> Anyway: Christian, Savyasaachi, I noticed a submission of a patch
> referencing the culprit with a Fixes: tag; it talks about package loss,
> but it still made me wonder if that might be related somehow:
> https://lore.kernel.org/all/[email protected]/
>
> Ciao, Thorsten
>
> > So back to the real problem:
> >
> > @wifi developers: Is there some bigger problem in 6.9.y related to
> > monitoring mode that is affecting a lot of drivers/users?
> >
> > I'm asking because I noticed another report that sounded related. To
> > quote: https://bugzilla.kernel.org/show_bug.cgi?id=218884
> >
> > """
> >> Michael 2024-05-24 17:04:51 UTC
> >>
> >> Some features are broken since kernel 6.9.1 when running monitor mode.
> >>
> >> First bug:
> >> Switching a channel via "NL80211_ATTR_WIPHY_FREQ" does not switch the channel/frequency.
> >>
> >> That is not a device driver problem, because all device drivers (Mediatek, Ralink, Realtek, ...) are
> affected.

We have a draft fix of rtw88 driver for RTL8821CE, but as mentioned some drivers
are affected, so I don't plan to send out the patch. Instead we are looking for
the fix of cfg80211/mac80211.

Ping-Ke

2024-06-06 13:36:28

[permalink] [raw]

Subject: Re: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

On 28.05.24 00:01, Christian Heusel wrote:
>
> Savyasaachi reports that scanning for other stations in monitor mode
> does not work anymore with his RTL8821CE wireless network card for linux
> kernels after 6.8.9.
>
> His workflow was putting the adapter in monitor mode by running
> "airmon-ng start wlan0" and then capture the surrounding stations with
> "airodump-ng wlan0".
>
> We have bisected the issue together in the issue in the Arch Linux
> bugtracker[0] down to the following commit:
>
> 0a44dfc070749 ("wifi: mac80211: simplify non-chanctx drivers")

Johannes, Kalle, if you have a minute, what's the overall situation
regarding that commit and related regression fixes for drivers that are
affected by it?

Afaics it is like this:

One regression caused by that commit was already fixed with
2f7cf3b61d8522 ("wifi: mt76: mt7915: add missing chanctx ops"); two more
will soon be fixed once 2f7cf3b61d8522 ("wifi: mt76: mt7915: add missing
chanctx ops") and 819bda58e77bb6 ("wifi: rtlwifi: Ignore
IEEE80211_CONF_CHANGE_RETRY_LIMITS") are mainlined.

But there was no reply to the regression report this thread is about.
And Ping-Ke from Realtek even wrote "We have a draft fix of rtw88 driver
for RTL8821CE, but as mentioned some drivers are affected, so I don't
plan to send out the patch." So apparently Ping-Ke is waiting for some
statement from you how to proceed.
https://lore.kernel.org/all/[email protected]/

There there is another report about problems caused by this patch where
the user has a mt7601u -- but also broadly (and thus likely incorrectly)
claims that all drivers are affected:
https://bugzilla.kernel.org/show_bug.cgi?id=218884 (I mentioned that
report a few days ago in this thread already without any reaction so far
afaics).

That all looks a bit concerning (and makes me wonder if temporary
reverting 0a44dfc070749 might be wise). :-/ But I might be missing
something here, that's why it would be good if you could provide a quick
evaluation of the situation.

Ciao, Thorsten

2024-06-11 15:29:21

[permalink] [raw]

Subject: Re: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

On Mon, 2024-06-03 at 00:47 +0000, Ping-Ke Shih wrote:
>
>
> We have a draft fix of rtw88 driver for RTL8821CE, but as mentioned some drivers
> are affected, so I don't plan to send out the patch. Instead we are looking for
> the fix of cfg80211/mac80211.
>

Guess you didn't find it :)

Just got pinged (sp?) about this, can you share the driver fix so I can
take a look what the issue is about?

johannes

2024-06-12 00:57:33

[permalink] [raw]

Subject: RE: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

Johannes Berg <[email protected]> wrote:
>
> On Mon, 2024-06-03 at 00:47 +0000, Ping-Ke Shih wrote:
> >
> >
> > We have a draft fix of rtw88 driver for RTL8821CE, but as mentioned some drivers
> > are affected, so I don't plan to send out the patch. Instead we are looking for
> > the fix of cfg80211/mac80211.
> >
>
> Guess you didn't find it :)

You are right. That is not easy to me. :)

>
> Just got pinged (sp?) about this, can you share the driver fix so I can
> take a look what the issue is about?
>

Please reference patch below. I copy this idea from rtw89 [1], which the main
stuff is to add WANT_MONITOR_VIF and case NL80211_IFTYPE_MONITOR in add_interface().
Additionally check whether bssid is NULL.

Many other drivers like rtlwifi, rtl8xxxue ... don't declare WANT_MONITOR_VIF, so
I think it would be better to fix this by mac80211 instead of fixing these drivers
one by one.

diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c
index 0acebbfa13c4..b90d026519e2 100644
--- a/drivers/net/wireless/realtek/rtw88/mac80211.c
+++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
@@ -191,6 +191,7 @@ static int rtw_ops_add_interface(struct ieee80211_hw *hw,
bcn_ctrl = BIT_EN_BCN_FUNCTION | BIT_DIS_TSF_UDT;
break;
case NL80211_IFTYPE_STATION:
+ case NL80211_IFTYPE_MONITOR:
rtw_add_rsvd_page_sta(rtwdev, rtwvif);
net_type = RTW_NET_NO_LINK;
bcn_ctrl = BIT_EN_BCN_FUNCTION;
diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index 7ab7a988b123..d51c7cad79da 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -2231,6 +2231,7 @@ int rtw_register_hw(struct rtw_dev *rtwdev, struct ieee80211_hw *hw)
ieee80211_hw_set(hw, HAS_RATE_CONTROL);
ieee80211_hw_set(hw, TX_AMSDU);
ieee80211_hw_set(hw, SINGLE_SCAN_ON_ALL_BANDS);
+ ieee80211_hw_set(hw, WANT_MONITOR_VIF);

if (sta_mode_only)
hw->wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION);
diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireless/realtek/rtw88/phy.c
index 37ef80c9091d..b1b7892266f0 100644
--- a/drivers/net/wireless/realtek/rtw88/phy.c
+++ b/drivers/net/wireless/realtek/rtw88/phy.c
@@ -627,6 +627,9 @@ static void rtw_phy_parsing_cfo_iter(void *data, u8 *mac,
u8 *bssid = iter_data->bssid;
u8 i;

+ if (!vif->bss_conf.bssid)
+ return;
+
if (!ether_addr_equal(vif->bss_conf.bssid, bssid))
return;
diff --git a/drivers/net/wireless/realtek/rtw88/rx.c b/drivers/net/wireless/realtek/rtw88/rx.c
index 84aedabdf285..43aa5dd6f2cc 100644
--- a/drivers/net/wireless/realtek/rtw88/rx.c
+++ b/drivers/net/wireless/realtek/rtw88/rx.c
@@ -104,6 +104,9 @@ static void rtw_rx_addr_match_iter(void *data, u8 *mac,
struct rtw_rx_pkt_stat *pkt_stat = iter_data->pkt_stat;
u8 *bssid = iter_data->bssid;

+ if (!vif->bss_conf.bssid)
+ return;
+
if (!ether_addr_equal(vif->bss_conf.bssid, bssid))
return;

[1] https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next.git/commit/drivers/net/wireless/realtek/rtw89?id=cd9b6b3baf5278c73c91e242d41387684fc7f8d8

2024-06-12 07:07:14

[permalink] [raw]

Subject: Re: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

On Wed, 2024-06-12 at 00:56 +0000, Ping-Ke Shih wrote:

> > Just got pinged (sp?) about this, can you share the driver fix so I can
> > take a look what the issue is about?
> >
>
> Please reference patch below. I copy this idea from rtw89 [1], which the main
> stuff is to add WANT_MONITOR_VIF and case NL80211_IFTYPE_MONITOR in add_interface().

Ah, OK, but that gives me a hint. Yes, I see the issue now.

OK it's not trivial and it might leave ath12k still not working (though
not sure it ever did before? or maybe I'm missing something...), but I
think I can fix this. Let's see.

johannes

2024-06-12 07:58:50

[permalink] [raw]

Subject: Re: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

On Wed, 2024-06-12 at 09:07 +0200, Johannes Berg wrote:
> On Wed, 2024-06-12 at 00:56 +0000, Ping-Ke Shih wrote:
>
>
> > > Just got pinged (sp?) about this, can you share the driver fix so I can
> > > take a look what the issue is about?
> > >
> >
> > Please reference patch below. I copy this idea from rtw89 [1], which the main
> > stuff is to add WANT_MONITOR_VIF and case NL80211_IFTYPE_MONITOR in add_interface().
>
> Ah, OK, but that gives me a hint. Yes, I see the issue now.
>
> OK it's not trivial and it might leave ath12k still not working (though
> not sure it ever did before? or maybe I'm missing something...), but I
> think I can fix this. Let's see.
>

I don't have any of the affected hardware, could someone test this?

https://p.sipsolutions.net/619a4ce4a197b2b4.txt

diff --git a/net/mac80211/driver-ops.c b/net/mac80211/driver-ops.c
index dce37ba8ebe3..254d745832cb 100644
--- a/net/mac80211/driver-ops.c
+++ b/net/mac80211/driver-ops.c
@@ -311,6 +311,18 @@ int drv_assign_vif_chanctx(struct ieee80211_local *local,
might_sleep();
lockdep_assert_wiphy(local->hw.wiphy);

+ /*
+ * We should perhaps push emulate chanctx down and only
+ * make it call ->config() when the chanctx is actually
+ * assigned here (and unassigned below), but that's yet
+ * another change to all drivers to add assign/unassign
+ * emulation callbacks. Maybe later.
+ */
+ if (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
+ local->emulate_chanctx &&
+ !ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
+ return 0;
+
if (!check_sdata_in_driver(sdata))
return -EIO;

@@ -338,6 +350,11 @@ void drv_unassign_vif_chanctx(struct ieee80211_local *local,
might_sleep();
lockdep_assert_wiphy(local->hw.wiphy);

+ if (sdata->vif.type == NL80211_IFTYPE_MONITOR &&
+ local->emulate_chanctx &&
+ !ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
+ return;
+
if (!check_sdata_in_driver(sdata))
return;

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index dc42902e2693..4a49e834a9f5 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -1121,9 +1121,6 @@ int ieee80211_add_virtual_monitor(struct ieee80211_local *local)
struct ieee80211_sub_if_data *sdata;
int ret;

- if (!ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
- return 0;
-
ASSERT_RTNL();
lockdep_assert_wiphy(local->hw.wiphy);

@@ -1145,11 +1142,13 @@ int ieee80211_add_virtual_monitor(struct ieee80211_local *local)

ieee80211_set_default_queues(sdata);

- ret = drv_add_interface(local, sdata);
- if (WARN_ON(ret)) {
- /* ok .. stupid driver, it asked for this! */
- kfree(sdata);
- return ret;
+ if (ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF)) {
+ ret = drv_add_interface(local, sdata);
+ if (WARN_ON(ret)) {
+ /* ok .. stupid driver, it asked for this! */
+ kfree(sdata);
+ return ret;
+ }
}

set_bit(SDATA_STATE_RUNNING, &sdata->state);
@@ -1187,9 +1186,6 @@ void ieee80211_del_virtual_monitor(struct ieee80211_local *local)
{
struct ieee80211_sub_if_data *sdata;

- if (!ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
- return;
-
ASSERT_RTNL();
lockdep_assert_wiphy(local->hw.wiphy);

@@ -1209,7 +1205,8 @@ void ieee80211_del_virtual_monitor(struct ieee80211_local *local)

ieee80211_link_release_channel(&sdata->deflink);

- drv_remove_interface(local, sdata);
+ if (ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
+ drv_remove_interface(local, sdata);

kfree(sdata);
}
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 283bfc99417e..963ed75deb76 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -1843,7 +1843,7 @@ int ieee80211_reconfig(struct ieee80211_local *local)

/* add interfaces */
sdata = wiphy_dereference(local->hw.wiphy, local->monitor_sdata);
- if (sdata) {
+ if (sdata && ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF)) {
/* in HW restart it exists already */
WARN_ON(local->resuming);
res = drv_add_interface(local, sdata);

2024-06-12 08:45:43

[permalink] [raw]

Subject: Re: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

On Wed, 2024-06-12 at 08:43 +0000, Ping-Ke Shih wrote:
>
> Tested on 6.9.2 with RTL8822CE.
>
> Before this patch, it can capture packets but always stays on channel 1.
> With this patch, I switch channel 1 --> 36 --> 149 --> 11.
> All are expected.
>

OK cool, no warnings?

johannes

2024-06-12 08:49:29

[permalink] [raw]

Subject: RE: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

Johannes Berg <[email protected]> wrote:
> On Wed, 2024-06-12 at 08:43 +0000, Ping-Ke Shih wrote:
> >
> > Tested on 6.9.2 with RTL8822CE.
> >
> > Before this patch, it can capture packets but always stays on channel 1.
> > With this patch, I switch channel 1 --> 36 --> 149 --> 11.
> > All are expected.
> >
>
> OK cool, no warnings?
>

no kernel warnings, no compiler warnings.

I did additionally simple connection test, still no warnings.

Ping-Ke

2024-06-12 08:58:59

[permalink] [raw]

Subject: RE: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

Johannes Berg <[email protected]>
> On Wed, 2024-06-12 at 09:07 +0200, Johannes Berg wrote:
> > On Wed, 2024-06-12 at 00:56 +0000, Ping-Ke Shih wrote:
> >
> >
> > > > Just got pinged (sp?) about this, can you share the driver fix so I can
> > > > take a look what the issue is about?
> > > >
> > >
> > > Please reference patch below. I copy this idea from rtw89 [1], which the main
> > > stuff is to add WANT_MONITOR_VIF and case NL80211_IFTYPE_MONITOR in add_interface().
> >
> > Ah, OK, but that gives me a hint. Yes, I see the issue now.
> >
> > OK it's not trivial and it might leave ath12k still not working (though
> > not sure it ever did before? or maybe I'm missing something...), but I
> > think I can fix this. Let's see.
> >
>
> I don't have any of the affected hardware, could someone test this?
>
> https://p.sipsolutions.net/619a4ce4a197b2b4.txt
>

Tested on 6.9.2 with RTL8822CE.

Before this patch, it can capture packets but always stays on channel 1.
With this patch, I switch channel 1 --> 36 --> 149 --> 11.
All are expected.

Thanks for the quick fix!
Ping-Ke

2024-06-12 09:13:59

by Vasanthakumar Thiagarajan

[permalink] [raw]

Subject: Re: [REGRESSION][BISECTED] wifi: RTL8821CE does not work in monitor mode

On 6/12/2024 12:37 PM, Johannes Berg wrote:
> On Wed, 2024-06-12 at 00:56 +0000, Ping-Ke Shih wrote:
>
>
>>> Just got pinged (sp?) about this, can you share the driver fix so I can
>>> take a look what the issue is about?
>>>
>>
>> Please reference patch below. I copy this idea from rtw89 [1], which the main
>> stuff is to add WANT_MONITOR_VIF and case NL80211_IFTYPE_MONITOR in add_interface().
>
> Ah, OK, but that gives me a hint. Yes, I see the issue now.
>
> OK it's not trivial and it might leave ath12k still not working (though
> not sure it ever did before? or maybe I'm missing something...), but I
> think I can fix this. Let's see.
>

Monitor mode is not yet supported in ath12k, this feature is work in progress.

Vasanth

2024-06-12 10:24:02