Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) Issues
This card has worked fine on multiple distros (mint18/19, parrotOS, kali, centOS, Redhat, ubuntu live USBs (Xubuntu, Kubuntu, Ubuntu proper)), some for many months at a time.
After installing Ubuntu Mate 17.10/18.04/18.10 the wifi began dropping seemingly at random, running a continuous ping would reply:
~$ ping www.google.com
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=646 ttl=56 time=10.1 ms
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=647 ttl=56 time=10.0 ms
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=648 ttl=56 time=10.7 ms
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=649 ttl=56 time=12.1 ms
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=650 ttl=56 time=12.2 ms
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
ping: sendmsg: No buffer space available
and so on.
At this point there is no network connection, SSH sessions drop, local NAS connections drop, unable to ping main router.
Restarting the card via. gui or ifconfig soon causes it to work again for a short period of time before the issue starts again.
Fixes attempted include:
- creating “ath9k.conf” adding the nohwcrypt=1 flag..issue not fixed!.
# echo “options ath9k nohwcrypt=1” | sudo tee /etc/modprobe.d/ath9k.conf
# restart - Restarting with an older kernel version via. the grub>advanced options>older version..issue not fixed!.
- Forcing the card to exclusively use B/G bands (dmesg showed “Reason: 3=DEAUTH_LEAVING)”, often related to the attempt to band hop.)
Setting chosen in the edit network connections menu on Mate..issue not fixed!.
I found a single message on a related forum post mentioning installing the ath9k firmware package on newer versions of ubuntu.
#Installed the package via.
# sudo apt install firmware-ath9k-htc
I’d have assumed this would be inbuilt with the newer kernels, but it’s worth a try.
Result after ~1 hour of working:
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=4280 ttl=56 time=10.3 ms
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=4281 ttl=56 time=10.4 ms
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=4282 ttl=56 time=1065 ms
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=4283 ttl=56 time=342 ms
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=4290 ttl=56 time=10.5 ms
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=4291 ttl=56 time=11.0 ms
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=4292 ttl=56 time=13.1 ms
64 bytes from lhr48s22-in-f4.1e100.net (216.58.204.228): icmp_seq=4293 ttl=56 time=15.2 ms
From 192.168.1.47 icmp_seq=4353 Destination Host Unreachable
From 192.168.1.47 icmp_seq=4354 Destination Host Unreachable
From 192.168.1.47 icmp_seq=4355 Destination Host Unreachable
From 192.168.1.47 icmp_seq=4356 Destination Host Unreachable
From 192.168.1.47 icmp_seq=4357 Destination Host Unreachable
#Related: I plugged in a USB wireless adaptor (Alfa networks), and attempted to use that for a while. I started to have the same buffer
space issue. This makes me think it’s more a system config issue than specific hardware issue.