2

I resolved the issue by switching to the ath10k drivers, which have now published drivers for my card. I've written up a step-by-step guide to what I did.

My Debian 8 laptop using 8192cu drivers intermittently fails to return any results when scanning for WiFi networks. How can I resolve the issue and allow my computer to consistently return complete results when scanning for WiFi networks?

EDIT 1: update the reason why I'm not using ath10k
EDIT 2: add lspci -nnk | grep -iA2 net

I'm running a Debian 8 laptop (Lenovo G50-80, with preloaded Windows replaced) and using a Kootek USB wireless dongle that uses the RTL8188CUS/RTL8192CU chipsets. (My onboard WiFi uses the ath10k drivers, which weren't available yet for my kernel last time I checked but they're not updated for my card's device ID last time I checked, so I'm forced to use a dongle for now. The PCI device and manufacturer ID of the onboard WiFi, as returned by lspci -nn, is 168c:0041.) I'm aware that the dongle I'm using is highly popular with the Raspberry Pi community.

I've downloaded the 8192cu.ko drivers, installed them, and successfully loaded them and blacklisted rtl8192cu; no error messages appear in dmesg -w, and I never have issues with getting the wlan0 interface to appear or getting the 8192cu module to appear in the output of lsmod whenever I plug in my dongle. But sometimes, sudo iwlist wlan0 scan returns

$ sudo iwlist wlan0 scan
wlan0     No scan results

$

even though I know I'm in the vicinity of multiple WiFi networks.

When I plug in the dongle, its blue light usually flashes a bit. The LED glows moderately brightly on a scan, and flashes very brightly when connecting to a network.

The WiFi works intermittently. Some days it works without a hitch ("it works" meaning I can successfully scan for and connect to a WiFi network). Other days I can use a workaround: unplug the dongle, plug it back in, spam sudo iwlist wlan0 scan if I feel like it, and repeat until it works. Some days—like all of this past week—it doesn't work at all, even after multiple reboots.

I've conducted several Google queries to attempt to resolve this issue. Most of my results seem to focus on people who aren't getting their dongle to show up on lsusb, or whose driver versions mismatch the kernel, or who are having issues pulling the interface up. None of those conditions apply here, which is why I'm asking this question.

I'm aware that I should test the dongle on a known-good computer. I haven't done this yet but might if you believe I should.

I use wpa_supplicant to connect to WiFi; I use NetworkManager for public networks and WPA-PSK, and a self-written script (basically runs wpa_supplicant and dhclient with a custom config file) for more complex ones.

I usually do not maintain the wireless access points that I connect to. That means I can't make configuration changes or inspect settings.

I periodically update my system with packages from the Debian security repos. That's never caused a kernel upgrade, though; only upgrades to bona fide .deb packages.

Files and transcripts. As mentioned above, these configurations work intermittently.

uname -a:

Linux hamming 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u4 (2016-02-29) x86_64 GNU/Linux

cat /etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/* # [this directory is empty]

# The loopback network interface
auto lo
iface lo inet loopback

lspci -nnk | grep -iA2 net:

02:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 10)
    Subsystem: Lenovo Device [17aa:3821]
    Kernel driver in use: r8169
03:00.0 Network controller [0280]: Qualcomm Atheros Device [168c:0041] (rev 20)
    Subsystem: Lenovo Device [17aa:3545]

The self-written script, with identifying details censored (lifted from somewhere on the Internet, I don't recall from where—maybe adapted from the Arch wiki or forum? since then I've added sanity checks and stdout verbosity for my own purposes):

#!/bin/bash
iface=wlan0

# check if sudo
if [[ "`id -u`" -ne 0 ]]; then
    echo '*** run this as root you idiot'
    exit 1
fi

# stop network manager
echo '*** stopping NM'
service network-manager stop

# stop any persistent wireless wpa2 auth sessions
echo '*** killing all wpa_supplicants'
killall wpa_supplicant

# shut down iface
echo '*** shutting down interface'
ifconfig $iface down

# set working mode of wireless device
echo '*** setting interface mode'
ifconfig $iface mode Managed

# enable iface
echo '*** enabling interface'
ifconfig $iface up

# apply dragonfly3 settings to device
echo '*** running wpa supplicant'
until wpa_supplicant -B -Dwext -i $iface -c ./connect-to-xxx.conf -dd; do
    echo "*** error level $?";
done
echo "*** error level $?"

# obtain an IP address
echo '*** obtaining IP address'
dhclient $iface
echo "*** error level $?"

echo '*** complete'

cat ./connect-to-xxx.conf, with identifying details censored:

ctrl_interface=/var/run/wpa_supplicant

network={
    ssid="xxx"
    key_mgmt=WPA-EAP
    eap=TTLS
    ca_cert="/path/to/ca/cert.cer"
    #scan_ssid=0
    #pairwise=CCMP TKIP
    #group=CCMP TKIP
    identity="myusername"
    password="mypassword"
    phase2="auth=MSCHAPv2"
}

I'm using a wired Ethernet connection to publish this question, so I don't have log transcripts from when I actually try to use the WiFi adapter. I'll save those and publish them here once I try connecting to the WiFi at the geographic location that usually gives me problems.

Community
  • 1
ameed
  • 151
  • 1
    ath10k is in jessie's default kernel, 3.16. I think it was added 3.11. I'd use that. Using a more recent kernel is also an option, and no big deal. – Faheem Mitha Mar 23 '16 at 08:59
  • 1
    Use a more recent kernel and avoid buying realtek in the future. http://unix.stackexchange.com/questions/252210/wi-fi-problems-using-asus-usb-n13-adapter/252215 as for Lenovo, they rebrand chipsets and give them different IDs... http://goughlui.com/2014/08/02/laptop-wireless-card-whitelists-an-upgrade-nightmare/ – Rui F Ribeiro Mar 23 '16 at 10:02
  • 3
    Where did you get the 8192cu driver from? Start a new question about the Atheros and include lspci -nnk | grep -iA2 net – Jeremy31 Mar 23 '16 at 11:26
  • a year or so ago (when my eeepc-based AP died) I set up a linux-based wifi access point using a cheap usb wifi adaptor that used the 8192cu driver. After spending nearly a week trying to get it to work reliably i chucked it out and replaced it with an equally cheap usb wifi adaptor that uses the ath9k driver. I'll never use adaptors that use 8192cu again, because the hardware is crap - RTL stuff is never great but their 8188/8192 chips are far worse than their usual mediocre efforts. btw, as @FaheemMitha says, ath10k is supported by default in jessie. – cas Mar 24 '16 at 01:36
  • For those of you who recommended that I use ath10k--I realized the real reason why I don't use it: last time I checked (admittedly a while ago), I realized that the ath10k stable backport for my kernel didn't have my card's device ID. I've updated the post with more information. – ameed Mar 25 '16 at 06:34
  • @Jeremy31 I've added the output of that command to the post. – ameed Mar 25 '16 at 06:37
  • 1
    There have been fixes posted on the internet, do a search for Linux 168c:0041 – Jeremy31 Mar 25 '16 at 10:17
  • @Jeremy31 Seems like most of the suggested solutions involve either pulling updated drivers from a git repo or updating to a 4.3 kernel (Debian doesn't have backports from 4.3 and the latest 4.2s don't support 168c:0041). I'll look into it. – ameed Mar 25 '16 at 21:54
  • 1
    Actually you need the firmware from a specific github site. Can't debian use backports from https://www.kernel.org/pub/linux/kernel/projects/backports/stable/ – Jeremy31 Mar 25 '16 at 22:01
  • The ath10k drivers and firmware worked. I'll post a question and answer shortly; thanks everyone! – ameed Mar 26 '16 at 00:14

2 Answers2

3

I assume your USB dongle doesn't have an external antenna, it's also possible varying condition and a (large) number of neighboring networks will affect what signal you can get, if any. Things like an active microwave, and other factors can affect signal too, keep an eye on those.

Your internal wifi chip most likely benefits from an antenna going around the edges of the laptop screen, as such it will get much better signal. To get the ath10k driver working, you will need to also install the firmware-atheros package from the non-free repository. As @Jeremy31 mentioned, opening a new questions about the Atheros chip installation, including its information, would give you the best chance of getting an optimal setup.

MagicFab
  • 167
0

Consensus seems to be that I should ditch the WiFi dongle and try and get the ath10k chip working. There are some updated backports; I'll build them, see if they support my card, and possibly make a new question with the results. For now, my initial query has been resolved; thanks, everyone.

ameed
  • 151