AR9271 stops receiving packets after several seconds to a several hours on monitor mode on any given channel, on every OS and card #126
Comments
melyux
changed the title
melyux
changed the title
|
@erikarn , hm... should we do some periodic recalibration? |
|
lol uhm, yes? :)
Are you telling me ath9k_htc is not doing any periodic calibration either
in firmware or in the host side? I expected the host side is doing some
stuff
…-a
On 23 February 2017 at 22:11, Oleksij Rempel ***@***.***> wrote:
@erikarn <https://github.com/erikarn> , hm... should we do some periodic
recalibration?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7c0XS12mZFrXa7IXfz9wEnwSgWVIks5rfnSkgaJpZM4MKxUF>
.
|
|
Not 100% sure if we are not doing. But is sounds like not, at least not for monitoring mode. |
|
Yes, we should be, even in monitor mode.
…-adrian
On 23 February 2017 at 22:30, Oleksij Rempel ***@***.***> wrote:
Not 100% sure if we are not doing. But is sounds like not, at least not
for monitoring mode.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7U6DUSWkOCuiXkwbYiwomVtITD7gks5rfnkYgaJpZM4MKxUF>
.
|
|
Interesting. I have had similar effects when being in monitor mode and having set fcsfail, i.e. frames with wrong checksum are also forwarded. I could reproduce this by using my EZ-Wifibroadcast distribution, enabling fcsfail in monitor mode and then running it near sensitivity limit, so that there are something like 50% of wrong checksum frames being received. Then sometimes, it would just stop receiving packets, like you described, no more ifconfig packets/bytes updates. Never tried to switch channel though when that happened. But I remember ifconfig down/up didn't work. Without FCS Fail, this never happened, have been running these cards for several days in monitor mode constantly receiving ~700 1024 byte frames per second. |
|
@melikyuksel can check if fcsfail ist set on you system? |
|
@olerem The I'm testing all this on fresh installations, and that flag is turned off by default when using both |
|
Not sure what the default is, I explicitly set it with When I use Edit: I'm also using AR9271 cards, same as you, TPLink 722 and Alfa AWUSH036NHA. |
|
I suspect that your cards would also stop receiving frames irregardless of |
|
in this case, after monitoring is stalled, ifconfig will show you identical or similar amount of packages |
|
I started monitore test: Currently it is running one hour. |
|
I left two running overnight as well (and they didn't stall, because they never stall overnight for some reason), and one just stalled at 5,138,158 RX packets (1.0 GiB), while the other stalled 5 hours later at 13,240,931 RX packets (2.3 GiB) so far. Is there some way to debug the situation when they stall? The ath9k_htc debug system itself show no difference for when it's running vs. when it's stalled. |
I have tested it with detached antennas on the receiving wifi sticks (PCB Antennas on 722N also disabled) all they could hear was the packets coming from my transmitting wifi sticks (i.e. the videostream).
This was not the case with my tests, the transmitting stick sends something around 700 frames per second. When being near, lost frames or frames with failed FCS are almost zero, maybe one per 5 minutes or so. Then it runs for days. So my theory so far is, that it's not the actual number of frames that causes this (i.e. "overloading" the card when there are too many frames). I think it's that some special combination of garbage data causes the card to crash (some invalid combinations of whatever fields in the IEEE802.11 header, wrong length field that causes a read past where it shouldn't read, something like that). This would explain that it can be reproduced quicker when there are more failed FCS frames, the probability that some frame contains "garbage the cards don't like" is higher. However, this explanation of course doesn't line up with your results with fcs fail not enabled. Still, I feel quite confident that this does never happen with my EZ-Wifibroadcast distribution, maybe you could test it with that? This way we'd have completely the same setup, only variable left would be local circumstances like other wifi networks. You can download it from here: https://github.com/bortek/EZ-WifiBroadcast/wiki, write it to an SDcard, edit wifibroadcast-1.txt on the boot partition (only FREQ=XXXX needs to be changed) put it in the Pi and let it run. SSH login is standard l:root p:raspberry. If you want local console access, switch over to tty10. |
|
@rodizio1 Sure, I'll test it with EZ-Wifibroadcast. Do I just boot it up and put the interface in monitor mode, or do I need a second device like it says on the page? |
|
No second device needed (as long as you don't want to transmit and receive live video), just write the image onto an SDcard and boot it up. Cards will automatically be in monitor mode on channel 13 after bootup. You can use up to three wifi sticks. |
|
Hiya,
can you turn on NFCAL debugging and see what it's doing?
…-adrian
|
|
@erikarn How is that done? |
|
https://wireless.wiki.kernel.org/en/users/Drivers/ath9k/debug
compile ath9k/ath9k_htc with debugging, then enable the CALIBRATE bit as
mentioned there, and check dmesg
it should be doing NF cal every 30 seconds or so.
…-adrian
On 25 February 2017 at 13:22, melikyuksel ***@***.***> wrote:
@erikarn <https://github.com/erikarn> How is that done?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7fPtjhLtXHy1RktJgbZXahDqy7H0ks5rgJuDgaJpZM4MKxUF>
.
|
|
It doesn't do periodic noisefloor calibration. Only when changing channels. |
|
Just got the EZ-Wifibroadcast image running for one card, and on the other card enabled the calibrate bit. No messages in dmesg even with the bit set though, and the packets haven't stalled on either yet as of 5 minutes in. |
|
hiya,
ok, let's figure out how/why behind doing periodic calibrations. That
sounds like a bit of a bug.
…-adrian
On 25 February 2017 at 14:21, melikyuksel ***@***.***> wrote:
Just got the EZ-Wifibroadcast image running for one card, and on the other
card enabled the calibrate bit. No messages in dmesg even with the bit set
though, and the packets haven't stalled on either yet.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7dGeR4cy4-myu2qMnOnDyNSPe6Noks5rgKlUgaJpZM4MKxUF>
.
|
|
So, the EZ-Wifibroadcast image card has stalled with the |
|
they're supposed to be in 'dmesg'. type dmesg, don't look at console output.
If it only is logged during NIC startup then yeah, let's figure out how to
fix that!
…-adrian
On 26 February 2017 at 02:32, melikyuksel ***@***.***> wrote:
So, the EZ-Wifibroadcast image card has stalled with the fcsfail option
untouched (which I assume means it's off). The card with calibrate bit
enabled has not stalled yet as of 12 hours later, and there are no messages
in dmesg at all about it. Are they really supposed to be in dmesg, or
maybe somewhere else?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7RKQLCQpTNZKaGY6O3LCEXJTx2CGks5rgVTBgaJpZM4MKxUF>
.
|
|
I'm definitely not seeing any periodic messages in dmesg from any of the cards, but I don't think there's anything on startup either. @rodizio1 Do you know what the message is supposed to look like? It's strange because |
Well, crap :) That makes my "bad content frames" theory invalid or we have two different issues here. Yes, it doesn't forward fcsfail frames by default. I'll make something that allows to inject a lot of frames for testing to verify your "too much frames" theory. This is what I get with debug=0xffffffff module parameter, NF calibration is done, but only on ifconfig up or channel change: Note, the lines starting with "ATH:" (in uppercase) are printk's that I added myself to the source to see which function the driver calls. |
|
That's strange, I wasn't even getting these messages when I had 0xffffffff set. I have the kernel compiled for debugging ath9k_htc and set the bit and everything. |
|
I have these wireless related debugging settings in the kernel .config file: |
|
Thanks, turns out I neglected to enable Here it is for the other card after it similarly froze and I manually changed the channel to 2: And after switching back to channel 1: There are no new messages in |
|
@rodizio1 Here's something to try: I wrote a script to switch through all the channels 1–11 every 10 minutes and return back to channel 1 for another 10 minutes, and found that it begins stalling a lot faster after this. It stops stalling of course when the next channel hopping session begins. My script also gets the packets seen in ifconfig and prints something out if it doesn't change within 3 seconds, so that's how I know it's stalled. |
|
the bug is that we should be doing periodic nfcal and other calibrations or
the nics will slowly go deaf.
…-a
On 26 February 2017 at 14:06, melikyuksel ***@***.***> wrote:
@rodizio1 <https://github.com/rodizio1> Here's something to try: I wrote
a script to switch through all the channels 1–11 every 10 minutes and
return back to channel 1 for another 10 minutes, and found that it begins
stalling a lot faster after this. It stops stalling of course when the next
channel hopping session begins. My script also gets the packets seen in
ifconfig and prints something out if it doesn't change within 3 seconds, so
that's how I know it's stalled.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7fUahynkbeCWlbRakqqHOEybUP9bks5rgfdigaJpZM4MKxUF>
.
|
|
Sounds good, but why would that deafening process depend on the volume of packets (or some certain type of error packet?) as seems to be the case? Does more traffic accelerate the deafening? Apart from the conspicuous lack of periodic calibration messages, the only things I've noticed is this message occasionally in and the extreme increase in the frequency of the stalling when channels are switched occasionally. If I run a script to change the channel once every 10 minutes, the cards sometimes begin to stall within minutes or seconds of being set to a channel. For this area, at least. |
|
@melikyuksel , it has nothing to do with number of packages. My adapter was running for some days now, and it is still working. More noise in the air will force the adapter to increase the noise floor level on rx line. The noise is not always at same level, it can have spikes. So if adapter will apply the filter at the level of this spike, then we will get deaf. |
|
@olerem Thanks for the explanation, it makes a lot of sense (although not quite sure why switching channels often triggers a very quick deafening... maybe more noise is introduced during the switching process?). Is there anything one could do to add the calibration to the -htc themselves at the moment? |
|
@melikyuksel , ... "Some one should make this code common, between ath9k and ath9k-htc.", most probably i will not find time to do this. So every one is welcome to contribute ... it is open source. |
|
@melikyuksel Those crashes/issues you see while switching channels is a different issue. I also have these problems, something is buggy there, also happens when switching to promiscous mode sometimes. @olerem/erikarn: How can you guys be sure that it's the missing periodic noise floor calibration that is causing the issue? Why can I reproduce this without any noise-spikes being present, just by receiving a lot of bad-FCS frames? Different issue? |
|
@rodizio1 True. I ended up writing a script to check for ath9k_htc interfaces, check if they're on monitor mode, and then check the RX packages every 5 seconds. If the packets stop increasing, it just quickly switches the channel and then switches it back. This seems to have "solved" these issues, but now I'm having the issue when multiple ath9k_htc cards don't start that you were having in the other thread. That's a whole another matter in itself... It's a pity we bought so many of these cards. |
|
It looks like HTC NICs do calibration: ath9k_htc_start_ani() will start the
ani work, and ath9k_htc_ani_work() will do the actual ANI, shortcal,
longcal work.
The trouble(!) is, the ani_work is only added in certain circumstances,
which is "technically" correct for ANI, but wrong for shortcal/longcal.
Eg - in ath9k_htc_add_interface(), it's only started if it's an AP, and ANI
is enabled. For STA mode in ath9k_htc_bss_info_changed(), it's only started
if it's associated, and number of associated vifs is 1.
For monitor mode, it's not doing ANI, which means its not doing periodic
calibration.
So as a test, let's just enable it always for monitor mode.
diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
index a553c91..a4f84c2 100644
…--- a/drivers/net/wireless/ath/ath9k/htc_drv_main.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_main.c
@@ -1104,6 +1104,11 @@ static int ath9k_htc_add_interface(struct
ieee80211_hw *hw,
ath9k_htc_start_ani(priv);
}
+ if (vif->type == NL80211_IFTYPE_MONITOR) {
+ printk("%s: starting ANI, monitor mode\n", __func__);
+ ath9k_htc_start_ani(priv);
+ }
+
ath_dbg(common, CONFIG, "Attach a VIF of type: %d at idx: %d\n",
vif->type, avp->index);
And I'll go look at tidying this code up to always run the ANI routine in
hostap/STA/monitor/mesh mode so periodic calibration runs, then just skips
ANI if ANI is configured as disabled. This whole "don't do ANI" stuff is
conflating with the "do periodic calibration" stuff, and that's why your
NICs go deaf. :-)
-adrian
On 9 March 2017 at 09:56, melikyuksel ***@***.***> wrote:
@rodizio1 <https://github.com/rodizio1> True. I ended up writing a script
to check for ath9k_htc interfaces, check if they're on monitor mode, and
then check the RX packages every 5 seconds. If the packets stop increasing,
it just switches the channel and then switches it back. This seems to have
"solved" these issues, but now I'm having the issue when multiple ath9k_htc
cards don't start that you were having in the other thread. That's a whole
another matter in itself...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7fA2nOr1pDDXQFU0EHzI1zOFzeYcks5rkD1GgaJpZM4MKxUF>
.
|
|
@erikarn I would love to try this patch on the Raspberry Pi, but I can't seem to recompile the ath9k module on there without somehow messing up its ability to handle more than 2 AR9271 devices at the same time (seen in the other issue thread). I'll try it later with a fresh install. I will be trying this on Debian however! EDIT: Managed to get the patch applied to both Debian and Raspbian and get all the cards up, and I'm testing them right now. |
|
hiya,
please do test it out. I'll get linux-next going again on something
laptop-y next week so I can fully figure out what's going on with all of
this calibration nonsense. :)
…-adrian
On 12 March 2017 at 00:23, melikyuksel ***@***.***> wrote:
@erikarn <https://github.com/erikarn> I would love to try this patch on
the Raspberry Pi, but I can't seem to recompile the ath9k module on there
without somehow messing up its ability to recognize more than 2 AR9271
devices at the same time (seen in the other issue thread). I will be trying
this, however, on Debian!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7a_nmxzI6ZXilxLeFsD9oGUMorsgks5rk6uPgaJpZM4MKxUF>
.
|
|
@erikarn I seem to have had the first surrender, where one of the cards stopped after 50 minutes (with channel hopping being done every 10 minutes). But where is that Just checking in case the patch didn't go through for some reason. I wrote a test module ("hello world!") with |
|
It's supposed to show up when the interface is created. If it's not
printing it out, then it's not starting.
Which kernel version are you using? Does ti really not show up in 'dmesg' ?
…-adrian
On 12 March 2017 at 18:00, melikyuksel ***@***.***> wrote:
@erikarn <https://github.com/erikarn> I seem to have had the first
surrender, where one of the cards stopped after 50 minutes (with channel
hopping being done every 10 minutes). But where is that printk message
supposed to show up? I checked dmesg and did not see it there, but I
modified some of the messages in hif_usb.c at the same time, and I *do*
see those. Those use the dev_info function, apparently:
dev_info(&hif_dev->udev->dev, "ath9k_htc: Transferred FW: %s, size: %ld\n",
hif_dev->fw_name, (unsigned long) hif_dev->fw_size);
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7c_R3pMI780ADKPCrQZKn2_P7XCwks5rlJUsgaJpZM4MKxUF>
.
|
|
@erikarn This is 4.4.50. It doesn't show up in dmesg, but expected lines from the other files do show up. Just not this one. |
|
ok, need to figure out why that is. Can someone else help out enabling the
ANI timer like I have in that patch? It should make things work.
…-adrian
|
|
I have added the patch now to Raspberry Kernel 4.4.11. It seems the "if (vif->type ..." condition does not match. Commented out the if condition and then I get the "ath9k_htc_add_interface: starting ANI, monitor mode" debug line in dmesg. |
|
ok, does that fix it?
also, can you printk the vif->type value? What interface type are you
creating?
…-adrian
On 20 March 2017 at 08:01, Rodizio ***@***.***> wrote:
I have added the patch now to Raspberry Kernel 4.4.11. It seems the "if
(vif->type ..." condition does not match. Commented out the if condition
and then I get the "ath9k_htc_add_interface: starting ANI, monitor mode"
debug line in dmesg.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7aaKljKSjnJwNyRtS8jImASEuKZ2ks5rnpS7gaJpZM4MKxUF>
.
|
|
@erikarn Had the chance to test it. The |
|
Yes, I can confirm this. dmesg debug log only appears once after plugging the card. Is this sufficient, i.e. will the chip still do noise floor calibration after it has been "ifconfig upped/downed" and put into monitor mode? |
|
hi,
ok, we need to figure out how to get it to start ANI whenever the interface
is created as well as down/up. It should always be doing period noise
calibration when the NIC is up.
…-adrian
On 5 April 2017 at 09:16, Rodizio ***@***.***> wrote:
Yes, I can confirm this. dmesg debug log only appears once after plugging
the card.
Is this sufficient, i.e. will the chip still do noise floor calibration
after it has been "ifconfig upped/downed" and put into monitor mode?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7Yv7Rm2WJ3mgskZUhMF5vogsbAlqks5rs75ugaJpZM4MKxUF>
.
|
|
Did you manage to solve this issue? I am having the same problem with COMPEX WLE350NX-7B mPCIe module (AR9580) and kernel 3.2.70. I tried all your suggestions with same results.. |
|
thank you all，I according to your explanation，Modify the code，The original short time is deaf。Can now listen to 10 hours more。 device：AR9271USB [321921.310000] ath: phy21: ath9k_htc_ani_work()----------debug for me root@openwrt:~# ifconfig mon21 |
|
heh, send me a diff :)
…-adrian
On 8 May 2017 at 19:59, zimiao815 ***@***.***> wrote:
thank you all，I according to your explanation，Modify the code，The original
short time is deaf。Can now listen to 10 hours more。
Have the effect ！！！
According to the following debug information I should do next？？？？
thank you very mach
device：AR9271USB
`
[321921.310000] ath: phy21: ath9k_htc_ani_work()----------debug for me
[321921.310000] ath: phy21: shortcal @3216213
<32162131>
[321921.310000] ath: phy21: listenTime=22232025 OFDM:1 errs=99/s CCK:5
errs=150/s ofdm_turn=1
[321921.410000] ath: phy21: ath9k_htc_ani_work()
[321921.410000] ath: phy21: listenTime=22232122 OFDM:1 errs=99/s CCK:5
errs=150/s ofdm_turn=1
[321921.510000] ath: phy21: ath9k_htc_ani_work()
[321921.510000] ath: phy21: listenTime=22232219 OFDM:1 errs=99/s CCK:5
errs=150/s ofdm_turn=1
[321921.610000] ath: phy21: ath9k_htc_ani_work()
[321921.610000] ath: phy21: listenTime=22232316 OFDM:1 errs=99/s CCK:5
errs=150/s ofdm_turn=1
[321921.710000] ath: phy21: ath9k_htc_ani_work()
[321921.710000] ath: phy21: listenTime=22232413 OFDM:1 errs=99/s CCK:5
errs=150/s ofdm_turn=1
***@***.***:~# ifconfig mon21
mon21 Link encap:UNSPEC HWaddr 00-12-7B-20-55-C8-7F-86-00-00-
00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:34265001 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8844607858 (8.2 GiB) TX bytes:0 (0.0 B)
***@***.***:~# ifconfig mon21
mon21 Link encap:UNSPEC HWaddr 00-12-7B-20-55-C8-7F-BA-00-00-
00-00-00-00-00-00
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:34265001 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:8844607858 (8.2 GiB) TX bytes:0 (0.0 B)
`
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#126 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABGl7WwbOVRejK_O104UuYiV7fKDGc01ks5r39aogaJpZM4MKxUF>
.
|
/drivers/net/wireless/ath/ath9k/htc_drv_main.c--- /drivers/net/wireless/ath/ath9k/htc_drv_main.c 2017-05-04 18:40:15.596674578 +0800
|
|
@erikarn but a long time will still be in the future is deaf。should do ? [ 3140.990000] ath: phy4: shortcal @284099 [ 3141.090000] ath: phy4: listenTime=194 OFDM:0 errs=0/s CCK:0 errs=0/s ofdm_turn=1 [ 3141.190000] ath: phy4: listenTime=291 OFDM:0 errs=0/s CCK:0 errs=0/s ofdm_turn=1 [ 3141.290000] ath: phy4: listenTime=388 OFDM:0 errs=0/s CCK:0 errs=0/s ofdm_turn=1 [ 3141.390000] ath: phy4: listenTime=97 OFDM:0 errs=0/s CCK:0 errs=0/s ofdm_turn=0 [ 3141.490000] ath: phy4: listenTime=194 OFDM:0 errs=0/s CCK:0 errs=0/s ofdm_turn=0 [ 3141.590000] ath: phy4: listenTime=291 OFDM:0 errs=0/s CCK:0 errs=0/s ofdm_turn=0 [ 3141.690000] ath: phy4: listenTime=389 OFDM:0 errs=0/s CCK:0 errs=0/s ofdm_turn=0 |
|
I've tried this now, seems to work. That is, ANI seems to be enabled, I get periodic log messages when debug is enabled. Haven't had time yet to do any real-world testing though. I've tried creating a patch using this commandline: However, when I try to apply it, I get this: Sorry, don't have time to bother with this 1970ies unix software weirdness now, maybe somebody else can create a proper patch. |
Both the current and previous version seem to have the issue. After anywhere from 20 seconds to 3 hours or so of being in monitor mode, the interface stops receiving packets. It seems to die more quickly during busier times when it receives more packets. The
ifconfigcount stops increasing, and the driver debugdebug_fsnumbers also become static. The only way to get it to receive again is to change the channel (changing to another channel and then immediately switching back works; I don't know whether the card is slipping to a non-WiFi frequency or something, sinceiwstill reports it as being on the same frequency as it was before, and it makes no changes to the frequency if it thinks the card is already on the channel that is specified). It doesn't seem to be able to stay on one channel for very long.I've tried this with several Atheros AR9271 chipset cards, like the ALFA AWUS036NHA and TP-Link TL-WN722N. They all have the same issue. I've tried it on Debian, Kali, Raspbian, Raspbian Lite, and Arch, and I've gotten identical behavior. I've tried a powered USB hub, an unpowered hub, and no hub at all. I've tried it on a MacBook, a Virtual Machine, a Mac Mini, a Raspberry Pi, and a Pi Zero. I've tried it with all sorts of different antenna. I've tried power supplies of various amperages. I've tried it with all other processes killed. I've switched intermediary USB cables around and gotten rid of them altogether. Power save is off in both module parameters and in
iw.dmesgand syslog show no errors or events when this happens. The packets just silently stop coming in until the channel is changed. The activity LED on the cards stop blinking and turn solid. Other non-Atheros wireless adapters work fine on every system for weeks on an end without stopping packet reception.To reproduce, put any AR9271 wireless card into monitor mode and take it into a relatively crowded area. Don't change the channel (or do it, it might die faster if you do, it's Russian roulette). It may take seconds or hours, but it is guaranteed to stop receiving packets indefinitely after a certain point within the day.
The text was updated successfully, but these errors were encountered: