Hi,
we are not able to obtain any packets when packet capturing with the
Mediatek MT7921K in monitor mode on 2.4, 5 and 6 GHz.
tcpdump will show you 0 recorded packets. When doing a "iw dev wls1
scan" on a parallel running managed interface on the same phy, the
packet capture will contain beacons and probe responses from the scan
though.
Can anyone confirm that?
mt76 (https://github.com/openwrt/mt76/commits/master): commit
6fad970893dd26ef6e6c8344b958344254f6362a (HEAD -> master, origin/master,
origin/HEAD)
Kernel: 5.16.0-rc2-next-20211124+
WM Firmware Version: ____010000, Build Time: 20211014150922
Steps to reproduce:
sudo iw dev wls1 del
sudo iw phy phy0 interface add mon0 type monitor
sudo ip link set dev mon0 up
sudo iw dev mon0 set freq 6115
sudo tcpdump -i mon0 -w 6g-capture.pcap
Kinds regards, Jan
> Hi,
Hi Jan,
>
> we are not able to obtain any packets when packet capturing with the
> Mediatek MT7921K in monitor mode on 2.4, 5 and 6 GHz.
> tcpdump will show you 0 recorded packets. When doing a "iw dev wls1 scan" on
> a parallel running managed interface on the same phy, the packet capture
> will contain beacons and probe responses from the scan though.
> Can anyone confirm that?
>
> mt76 (https://github.com/openwrt/mt76/commits/master): commit
> 6fad970893dd26ef6e6c8344b958344254f6362a (HEAD -> master, origin/master,
> origin/HEAD)
> Kernel: 5.16.0-rc2-next-20211124+
> WM Firmware Version: ____010000, Build Time: 20211014150922
IIRC you need to disable runtime-pm and deep-sleep to proper enable monitor
mode:
echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/runtime-pm
echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/deep-sleep
Can you please give it whirl?
Regards,
Lorenzo
>
> Steps to reproduce:
> sudo iw dev wls1 del
> sudo iw phy phy0 interface add mon0 type monitor
> sudo ip link set dev mon0 up
> sudo iw dev mon0 set freq 6115
> sudo tcpdump -i mon0 -w 6g-capture.pcap
>
> Kinds regards, Jan
>
On Thursday, 2 December 2021 23:13:31 CET Lorenzo Bianconi wrote:
> IIRC you need to disable runtime-pm and deep-sleep to proper enable monitor
> mode:
>
> echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/runtime-pm
> echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/deep-sleep
>
> Can you please give it whirl?
Jan gave me the card. I've set it to a rather busy channel (2.4GHz channel
11), created a monitor interface, attached tcpdump and then waited what
happens. I didn't get anything and then I've tried to set runtime-pm and deep-
sleep to 0. This didn't change the behavior for me at lot. I saw two packets
and then it went silent again.
I wanted to try the same on a different card (ath11k) in the same system. But
it crashed my complete system - so I had to recreate the test setup. This time,
I've set runtime-pm + deep-sleep to 0 before creating mon0. After doing this,
it seemed to work.
Kind regards,
Sven
> On Thursday, 2 December 2021 23:13:31 CET Lorenzo Bianconi wrote:
> > IIRC you need to disable runtime-pm and deep-sleep to proper enable monitor
> > mode:
> >
> > echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/runtime-pm
> > echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/deep-sleep
> >
> > Can you please give it whirl?
>
> Jan gave me the card. I've set it to a rather busy channel (2.4GHz channel
> 11), created a monitor interface, attached tcpdump and then waited what
> happens. I didn't get anything and then I've tried to set runtime-pm and deep-
> sleep to 0. This didn't change the behavior for me at lot. I saw two packets
> and then it went silent again.
>
> I wanted to try the same on a different card (ath11k) in the same system. But
> it crashed my complete system - so I had to recreate the test setup. This time,
> I've set runtime-pm + deep-sleep to 0 before creating mon0. After doing this,
> it seemed to work.
interesting, adding Sean to the loop here.
It seems the fw is mainting a different state in this case.
@Sean: any pointers?
Regards,
Lorenzo
>
> Kind regards,
> Sven
From: Sean Wang <[email protected]>
>> On Thursday, 2 December 2021 23:13:31 CET Lorenzo Bianconi wrote:
>> > IIRC you need to disable runtime-pm and deep-sleep to proper enable
>> > monitor
>> > mode:
>> >
>> > echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/runtime-pm
>> > echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/deep-sleep
>> >
>> > Can you please give it whirl?
>>
>> Jan gave me the card. I've set it to a rather busy channel (2.4GHz
>> channel 11), created a monitor interface, attached tcpdump and then
>> waited what happens. I didn't get anything and then I've tried to set
>> runtime-pm and deep- sleep to 0. This didn't change the behavior for
>> me at lot. I saw two packets and then it went silent again.
>>
>> I wanted to try the same on a different card (ath11k) in the same
>> system. But it crashed my complete system - so I had to recreate the
>> test setup. This time, I've set runtime-pm + deep-sleep to 0 before
>> creating mon0. After doing this, it seemed to work.
>
>interesting, adding Sean to the loop here.
>It seems the fw is mainting a different state in this case.
fw cannot receive any frame on monitor mode in deeply doze mode
so it seemed to me we need a patch to explicitly disable pm runtime in driver when monitor interface is enabled until it is being disabled.
>
>@Sean: any pointers?
>
>Regards,
>Lorenzo
>
>>
>> Kind regards,
>> Sven
>
> From: Sean Wang <[email protected]>
>
> >> On Thursday, 2 December 2021 23:13:31 CET Lorenzo Bianconi wrote:
> >> > IIRC you need to disable runtime-pm and deep-sleep to proper enable
> >> > monitor
> >> > mode:
> >> >
> >> > echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/runtime-pm
> >> > echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/deep-sleep
> >> >
> >> > Can you please give it whirl?
> >>
> >> Jan gave me the card. I've set it to a rather busy channel (2.4GHz
> >> channel 11), created a monitor interface, attached tcpdump and then
> >> waited what happens. I didn't get anything and then I've tried to set
> >> runtime-pm and deep- sleep to 0. This didn't change the behavior for
> >> me at lot. I saw two packets and then it went silent again.
> >>
> >> I wanted to try the same on a different card (ath11k) in the same
> >> system. But it crashed my complete system - so I had to recreate the
> >> test setup. This time, I've set runtime-pm + deep-sleep to 0 before
> >> creating mon0. After doing this, it seemed to work.
> >
> >interesting, adding Sean to the loop here.
> >It seems the fw is mainting a different state in this case.
>
> fw cannot receive any frame on monitor mode in deeply doze mode
>
> so it seemed to me we need a patch to explicitly disable pm runtime in driver when monitor interface is enabled until it is being disabled.
ack, I agree, but I guess the point here is what is the difference (from the fw pov) if you disable
runtime-pm/deep-sleep before/after the vif is added. I guess it is supposed to
be the same, right?
Regards,
Lorenzo
>
> >
> >@Sean: any pointers?
> >
> >Regards,
> >Lorenzo
> >
> >>
> >> Kind regards,
> >> Sven
> >
>
From: Sean Wang <[email protected]>
>> From: Sean Wang <[email protected]>
>>
>> >> On Thursday, 2 December 2021 23:13:31 CET Lorenzo Bianconi wrote:
>> >> > IIRC you need to disable runtime-pm and deep-sleep to proper
>> >> > enable monitor
>> >> > mode:
>> >> >
>> >> > echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/runtime-pm
>> >> > echo 0 > /sys/kernel/debug/ieee80211/phy<x>/mt76/deep-sleep
>> >> >
>> >> > Can you please give it whirl?
>> >>
>> >> Jan gave me the card. I've set it to a rather busy channel (2.4GHz
>> >> channel 11), created a monitor interface, attached tcpdump and then
>> >> waited what happens. I didn't get anything and then I've tried to
>> >> set runtime-pm and deep- sleep to 0. This didn't change the
>> >> behavior for me at lot. I saw two packets and then it went silent again.
>> >>
>> >> I wanted to try the same on a different card (ath11k) in the same
>> >> system. But it crashed my complete system - so I had to recreate
>> >> the test setup. This time, I've set runtime-pm + deep-sleep to 0
>> >> before creating mon0. After doing this, it seemed to work.
>> >
>> >interesting, adding Sean to the loop here.
>> >It seems the fw is mainting a different state in this case.
>>
>> fw cannot receive any frame on monitor mode in deeply doze mode
>>
>> so it seemed to me we need a patch to explicitly disable pm runtime in driver when monitor interface is enabled until it is being disabled.
>
>ack, I agree, but I guess the point here is what is the difference (from the fw pov) if you disable runtime-pm/deep-sleep before/after the vif is added. I guess it is supposed to be the same, right?
yes, it is supposed to be the same.
>
>Regards,
>Lorenzo
>
>>
>> >
>> >@Sean: any pointers?
>> >
>> >Regards,
>> >Lorenzo
>> >
>> >>
>> >> Kind regards,
>> >> Sven
>> >
>>
>
On Saturday, 4 December 2021 01:55:04 CET [email protected] wrote:
> >ack, I agree, but I guess the point here is what is the difference (from the fw pov) if you disable runtime-pm/deep-sleep before/after the vif is added. I guess it is supposed to be the same, right?
>
> yes, it is supposed to be the same.
Two things which were noticed too:
First finding: If I run `iw dev mon0 del` after a non-working tcpdump dump
session then I get following error messages before my complete system freezes:
[ 492.812050] mt7921e 0000:04:00.0: Message 40000002 (seq 14) timeout
[ 492.818587] mt7921e 0000:04:00.0: chip reset
[ 495.883934] mt7921e 0000:04:00.0: Message 00000046 (seq 15) timeout
Second one: We cannot see beacons on 2.4Ghz and 5GHz when runtime-pm + deep-
sleep is set to 0.
Regarding the initial problem: following works (when ignoring the missing
beacons for now):
echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/runtime-pm
echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/deep-sleep
iw dev wlp4s0 del
iw phy0 interface add mon0 type monitor
ip link set up dev mon0
iw dev mon0 set channel 11
tcpdump -ni mon0
What is often not working:
iw dev wlp4s0 del
iw phy0 interface add mon0 type monitor
ip link set up dev mon0
iw dev mon0 set channel 11
tcpdump -ni mon0 &
sleep 10
echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/runtime-pm
sleep 5
echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/deep-sleep
What I have seem to break sometimes (but cannot reproduce reliably):
iw dev wlp4s0 del
iw phy0 interface add mon0 type monitor
ip link set up dev mon0
iw dev mon0 set channel 11
echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/runtime-pm
echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/deep-sleep
tcpdump -ni mon0
The channel 11 is rather busy. It is for example also used for our community
mesh network in the city center - so is rather easy for me to see that it is
able to sniff traffic or not.
Kind regards,
Sven
> On Saturday, 4 December 2021 01:55:04 CET [email protected] wrote:
> > >ack, I agree, but I guess the point here is what is the difference (from the fw pov) if you disable runtime-pm/deep-sleep before/after the vif is added. I guess it is supposed to be the same, right?
> >
> > yes, it is supposed to be the same.
>
> Two things which were noticed too:
>
> First finding: If I run `iw dev mon0 del` after a non-working tcpdump dump
> session then I get following error messages before my complete system freezes:
>
> [ 492.812050] mt7921e 0000:04:00.0: Message 40000002 (seq 14) timeout
> [ 492.818587] mt7921e 0000:04:00.0: chip reset
> [ 495.883934] mt7921e 0000:04:00.0: Message 00000046 (seq 15) timeout
>
> Second one: We cannot see beacons on 2.4Ghz and 5GHz when runtime-pm + deep-
> sleep is set to 0.
>
>
>
> Regarding the initial problem: following works (when ignoring the missing
> beacons for now):
>
> echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/runtime-pm
> echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/deep-sleep
> iw dev wlp4s0 del
> iw phy0 interface add mon0 type monitor
> ip link set up dev mon0
> iw dev mon0 set channel 11
> tcpdump -ni mon0
>
>
> What is often not working:
>
> iw dev wlp4s0 del
> iw phy0 interface add mon0 type monitor
> ip link set up dev mon0
> iw dev mon0 set channel 11
> tcpdump -ni mon0 &
> sleep 10
> echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/runtime-pm
> sleep 5
> echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/deep-sleep
>
>
> What I have seem to break sometimes (but cannot reproduce reliably):
>
> iw dev wlp4s0 del
> iw phy0 interface add mon0 type monitor
> ip link set up dev mon0
> iw dev mon0 set channel 11
> echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/runtime-pm
> echo 0 > /sys/kernel/debug/ieee80211/phy0/mt76/deep-sleep
> tcpdump -ni mon0
>
>
> The channel 11 is rather busy. It is for example also used for our community
> mesh network in the city center - so is rather easy for me to see that it is
> able to sniff traffic or not.
Hi Sven,
can you please try the patch below to see if it fixes the crash/hang in monitor
mode?
Regards,
Lorenzo
From 2502ead5ba1f580d63bbc65165acb0139dc94ed8 Mon Sep 17 00:00:00 2001
Message-Id: <2502ead5ba1f580d63bbc65165acb0139dc94ed8.1639689141.git.lorenzo@kernel.org>
From: Lorenzo Bianconi <[email protected]>
Date: Thu, 16 Dec 2021 20:40:16 +0100
Subject: [PATCH] mt76: mt7921: fix a possible race enabling/disabling
runtime-pm
Fix a possible race enabling/disabling runtime-pm between mt7921_pm_set
and mt7921_poll_rx().
Signed-off-by: Lorenzo Bianconi <[email protected]>
---
drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c | 3 ---
drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c | 6 ++++--
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c b/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c
index af43bcb54578..306e9eaea917 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt76_connac_mac.c
@@ -7,9 +7,6 @@ int mt76_connac_pm_wake(struct mt76_phy *phy, struct mt76_connac_pm *pm)
{
struct mt76_dev *dev = phy->dev;
- if (!pm->enable)
- return 0;
-
if (mt76_is_usb(dev))
return 0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c b/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
index 7cdfdf83529f..59b047dceca0 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/debugfs.c
@@ -276,7 +276,7 @@ mt7921_pm_set(void *data, u64 val)
struct mt7921_dev *dev = data;
struct mt76_connac_pm *pm = &dev->pm;
- mt7921_mutex_acquire(dev);
+ mutex_lock(&dev->mt76.mutex);
if (val == pm->enable)
goto out;
@@ -286,6 +286,7 @@ mt7921_pm_set(void *data, u64 val)
pm->stats.last_doze_event = jiffies;
}
pm->enable = val;
+ mt76_connac_pm_wake(&dev->mphy, &dev->pm);
ieee80211_iterate_active_interfaces(mt76_hw(dev),
IEEE80211_IFACE_ITER_RESUME_ALL,
@@ -293,8 +294,9 @@ mt7921_pm_set(void *data, u64 val)
mt76_connac_mcu_set_deep_sleep(&dev->mt76, pm->ds_enable);
+ mt76_connac_power_save_sched(&dev->mphy, &dev->pm);
out:
- mt7921_mutex_release(dev);
+ mutex_unlock(&dev->mt76.mutex);
return 0;
}
--
2.33.1
>
> Kind regards,
> Sven
On Thursday, 16 December 2021 22:13:41 CET Lorenzo Bianconi wrote:
> can you please try the patch below to see if it fixes the crash/hang in monitor
> mode?
Thanks. But I don't have the mediatek card with me and can only test this in
slightly over three weeks.
Kind regards,
Sven
Hi,
On Thursday, 16 December 2021 22:13:41 CET Lorenzo Bianconi wrote:
> can you please try the patch below to see if it fixes the crash/hang in monitor
> mode?
I have tested it now. But it seems like it was already applied. Otherwise I
would have provided my Tested-by.
The only problem I have with the monitor mode is the missing beacons (and
maybe more frames which I haven't yet identified).
Kind regards,
Sven
> Hi,
>
> On Thursday, 16 December 2021 22:13:41 CET Lorenzo Bianconi wrote:
> > can you please try the patch below to see if it fixes the crash/hang in monitor
> > mode?
>
> I have tested it now. But it seems like it was already applied. Otherwise I
> would have provided my Tested-by.
>
> The only problem I have with the monitor mode is the missing beacons (and
> maybe more frames which I haven't yet identified).
>
> Kind regards,
> Sven
Hi Sven,
can you please test my latest patch?
https://patchwork.kernel.org/project/linux-wireless/patch/f6ad709b1a64152b5955e71b7eef9f9c4c7f127e.1641893305.git.lorenzo@kernel.org/
This patch will automatically set/clear runtime-pm/deep-sleep adding/removing a
monitor vif.
Regards,
Lorenzo