Getting an Old Ralink Wi-Fi Adapter Working for Pentesting in Parrot OS
A guide on how to get an old Ralink Wi-Fi adapter working for pentesting purposes in Parrot OS.
I recently decided to spend some time at wireless pentesting, so I set up a Parrot OS virtual machine on my Windows 11 desktop. While digging through some old hardware, I found a generic H802.11N USB Wi-Fi adapter and thought it would be perfect for a small wireless lab.
What I expected to be a quick plug‑and‑play setup turned into a much longer troubleshooting session involving Linux drivers, kernel behavior, and a few annoying crashes.
If you are dealing with an older Ralink‑based USB adapter that refuses to work properly in monitor mode, this might save you some time.
The setup
Here is what I was working with:
- Host: Windows 11 desktop with Ethernet
- Hypervisor: VMware Workstation 17 Player
- Guest OS: Parrot OS, which is Debian‑based
- Adapter: Generic H802.11N USB Wi‑Fi adapter with a Ralink RT5370 chipset
I passed the USB adapter directly into the VM using VMware’s Removable Devices menu, while leaving the default virtual network adapter on NAT mode so the VM could still access the internet through Ethernet.
Parrot recognized the adapter right away. When I ran ip a, the interface showed up normally as wlx....
┌─[user@parrot]─[~]
└──╼ $ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 00:1c:25:2a:4c:7e brd ff:ff:ff:ff:ff:ff
inet 192.168.23.128/24 brd 192.168.23.255 scope global dynamic noprefixroute ens33
valid_lft 1702sec preferred_lft 1702sec
3: wlxe84f061da160: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether ca:4a:e5:21:a6:b1 brd ff:ff:ff:ff:ff:ff permaddr e8:3e:01:2f:a1:64
At that point, everything looked fine. The system clearly saw the device.
The problem
The trouble started when I tried to switch the adapter into monitor mode.
I first tried doing it manually:
┌─[user@parrot]─[~]
└──╼ $sudo ip link set wlxe84f061da160 down
┌─[user@parrot]─[~]
└──╼ $sudo iw dev wlxe84f061da160 set type monitor
┌─[user@parrot]─[~]
└──╼ $sudo ip link set wlxe84f061da160 up
RTNETLINK answers: No such file or directory
That last command returned an error. Oddly enough, iwconfig still showed the adapter in monitor mode, so at first I decided to skip it like nothing happened. But...
┌─[✗]─[user@parrot]─[~]
└──╼ $sudo airodump-ng wlxe84f061da160
ioctl(SIOCSIFFLAGS) failed: No such file or directory
Failed initializing wireless card(s): wlxe84f061da160
The adapter was not actually behaving correctly.
Trying airmon‑ng
Next I tried airmon-ng to let it handle the monitor mode switch:
┌─[user@parrot]─[~]
└──╼ $sudo airmon-ng check kill
Killing these processes:
PID Name
867 wpa_supplicant
┌─[user@parrot]─[~]
└──╼ $sudo airmon-ng start wlxe84f061da160
PHY Interface Driver Chipset
phy1 wlxe84f061da160 rt2800usb Ralink Technology, Corp. RT5370
Interface wlxe84f061da160mon is too long for linux so it will be renamed to the old style (wlan#) name.
(mac80211 monitor mode vif enabled on [phy1]wlan0mon)
(mac80211 station mode vif disabled for [phy1]wlxe84f061da160)
It did create a monitor interface, but the result was still the same when I tried to capture traffic:
┌─[user@parrot]─[~]
└──╼ $sudo airodump-ng wlan0mon
ioctl(SIOCSIFFLAGS) failed: No such file or directory
Failed initializing wireless card(s): wlan0mon
The clue
At that point, I tested whether the interface could even be brought up manually:
┌─[✗]─[user@parrot]─[~]
└──╼ $sudo ifconfig wlxe84f061da160 up
SIOCSIFFLAGS: No such file or directory
That was the key clue. The adapter was not just misbehaving. It was effectively dropping out as soon as the system tried to activate it in monitor mode.
What was going on
At first, I suspected a few different things:
- VMware USB passthrough problems
- Driver issues with
rt2800usb - Power management quirks
I even tried module options like nohwcrypt=1, but none of that solved the problem.
The real issue turned out to be much simpler: the system was missing the proper firmware.
The rt2800usb driver was present, but the firmware files the adapter needed were not installed. So when the system tried to bring the radio up, the hardware failed and disconnected.
The fix
1. Install the firmware
After restarting NetworkManager to get internet access back, I installed the missing firmware with the following command:
┌─[user@parrot]─[~]
└──╼ $sudo apt install firmware-misc-nonfree firmware-ralink -y
Note, selecting 'firmware-misc-nonfree' instead of 'firmware-ralink'
Installing:
firmware-misc-nonfree
In my case, Debian pulled in firmware-misc-nonfree, which includes the Ralink firmware. I also saw some libkmod: ERROR warnings about CAN bus drivers like can-dev.ko.xz, but those were unrelated and could be ignored.
2. Final result
After reconnecting the adapter, I enabled monitor mode again:
┌─[user@parrot]─[~]
└──╼ $sudo airmon-ng start wlxe84f061da160
Then I ran the capture:
┌─[user@parrot]─[~]
└──╼ $sudo airodump-ng wlan0mon
This time it worked. No crashes, no disappearing adapter, just clean packet capture:
CH 2 ][ Elapsed: 6 mins ][ 2026-03-29 09:56
BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID
3C:84:AA:05:AA:82 -1 0 0 0 1 -1 <length: 0>
B0:AA:D2:11:CB:B4 -1 0 0 0 5 -1 <length: 0>
Final thoughts
If you are using an older Ralink chipset like the RT5370 in a Linux VM and you run into errors such as ioctl(SIOCSIFFLAGS) failed: No such file or directory, do not assume it is only a driver or virtualization problem.
Check the firmware first.
It is a small thing, but without it, the adapter simply cannot function properly, especially in monitor mode.