Hi

I'm running Debian 10 with a AWUS052NH usb adapter. I have never had any problems with this device. Two days ago I turned on the machine and iwconfig wlan0 confirmed the device was up and running and yes, I have internet. However when I did iwlist wlan0 the output was:

Failed to read scan data : resource temporarily unavailable

iw wlan0 scan does the scan but is too verbose.

As I have not updated the driver for this device I don't think that could be the culprit. However, if I check Wicd network manager before I bring the interface up it lists all of the access points around me but after I connect it reverts to: no wireless networks found.
So what am I missing here?

Thanx for your help.

Try 'iwlist wlan0 scan'

Thanks for your reply.
Unfortunately when I said that I had tried iwlist wlan0 in my post I'd forgotten to mention that I had put the word 'scan' on the end of that command.
Sorry for the confusion.

# iwlist wlan0 scanning

or

# iw dev wlan0 scan

You can use grep and other things to only extract the bits you're interested in. Or pipe it to less and search. I wrote a bash script to parse iwlist and output one line per network with the info needed to connect to it. signal strength, mac address, essid, encryption on/off, and whatnot.

Thanks for your tip but unfortunately this doesn't bring me any closer to answering my question as to what happened to iwlist wlan0 scan and how can I get this function back.

$ man iwlist

iwlist has a "scanning" option, NOT a "scan" option. Although scan on my debian buster install does seem to execute the scanning option. I don't think this was the case in earlier versions. Maybe you're on an earlier version. Try scanning instead and it might work as expected. In either case I need to bring up my interface first.

# ip link set wlo1 up

And if I have other things running like ModemManager, NetworkManager, WiCD, wpa_supplicant, ... ... ... those can "get in the way" of CLI options that directly access the same hardware. One option if you are using network-manager is to use the nmtui tool to connect to a network. It lists them in that tool in an ncurses kind of way from the CLI. Although not available in all distros (the last time I used arch, it didn't have it). So if you intend to use iwlist, you might need to stop those other services first.

# systemctl stop ModemManager
# systemctl stop NetworkManager
# pkill wpa_supplicant
# dhcpcd -x
# dhclient -r

Or whatever else applies before using iwlist. YMMV

Sorry for the delay in replying

Thank you again for staying with me on this. To reply to your first suggestion: Iwlist wlan0 scanning gives the same 'failed to scan data' result as iwlist wlan0 scan.

Unfortunately, the output of iw dev wlan0 scan is identical to that of iw wlan0 scan. And yes, my version of Buster is completely up to date.

Stopping running services as you suggested had no effect.Your comment about writing a bash script to parse iwlist and output in order to get approximitely the same output on each cell that the iwlist scan yields would be ideal. However, as a linux noob the sum total of what I know about reading or writing scripts would neatly fit between two molecules.

Now if I could only discover why the iwlist command simply stopped working from one day to the next without any intervention on my part...

We can try
The correct output is nothing, but that might throw up something. Also use sudo. There's clever maintenance type stuff you can do with apt to fix some of these issues. The obvious one of uninstalling & reinstalling might work, there's a --fix-broken command, and all sorts of stuff in the man page. Have you done an updare & dist-upgrade rtecently? That fixes things too.

Thanks for your reply


ldd /usr/bin/iwlist |grep found no such file or directory. Does this tell you anything? There is an iwlist in sbin but substituting that in the above command returns nothing.

I always use sudo when executing these type of commands and just yesterday I did the latest update + upgrade.

Iwlist scan finds all the other interfaces but not wlan0.

Tomorrow I'll do an uninstall reinstall on the driver. Let you know how that works out.

Ok, iwlist works. So either it's not in /usr/bin, or ldd is awol. I have it in /sbin; it could also be /usr/sbin. For finding stuff, use 'which iwlist' or 'which ldd'

Odd behavior like that seems to suggest an unstable / bad driver. One trick to work with such conditions is to down the interface and modprobe -r the module and modprobe it back. Then use it again. Or reboot when it whacks out. Some devices only offer one off drivers for a specific version of the kernel. Fine as long as you stay on that version, but broke or unstable on all other versions of the kernel. If it's maintained, there might be some git repository for the module that you could compile to have a "good" driver. Which is otherwise not in the active kernel tree, or other licensing issues that prevents it from being included in the kernel sources.

Some distros have dkms methods to add the module via package in addition to the kernel which ships an older and differently licensed module. Like my r8168 module on one of my laptops for it's ethernet. Without the dkms module it loads the r8169 module that flakes out every 30+ minutes, which renders that network interface effectively useless. And the laptop effectively useless if you have dongle allergies. Sadly my new-est / best spec'd laptop, and yet it's spent the most time unplugged and off of any of my laptops. Even though I know of it's quirks and have a work around. But my other main laptop is roughly the same specs (2.4GHz quad core versus 2.5GHz quad core CPU), so I mostly use it. And several RPi 4b's for lower heat and wattage attributes. That other laptop also has the rtl8723de wifi chipset that wasn't available or in the default git for rtlwifi_new for it's first six+ months of ownership.

# apt-get install r8168-dkms
# ip link set enp1s0 down
# modprobe -r r8169
# modprobe r8168
# ip link set enp1s0 up

Not exactly what you need for your situation, but a methodology I've had to use in the past. Works in linux, yes. Out of the box, not so much.

To close this down.
I finally got around to a complete remove and purge plus reinstall of the Ralink driver and yes this simple little action eradicacted the problem. Now if only I'd thought of this in the first place. On the other hand, the problem with push button solutions is that you don't really learn anything. One of the reasons I migrated from Windows. It's a pity I hadn't seen yout last reply before, doing this, Shadow 7, since now I'll never know what the outcome would have been.

Thanks again everyone, for taking the time to help me out with this.

PS. Where is the button to mark this thread as solved?

I wouldn't say never. Problems seem to find a way to re-surface. Again, and again, and again. Stable is not a term "known" to the "modern" world.