Oops, something has gone wrong. Please contact your software vendor. Network Manager needs to be running,no WiFi adapter error in Kali Linux [Solved]

One question decides which half of this article you need: is this Kali running in VirtualBox or VMware?

If yes, there is no Wi-Fi adapter inside it and there never will be. Your hypervisor gives the guest a virtual Ethernet card. Internet works through NAT, which is exactly why people assume wireless is nearly working — it isn't there at all. Jump to the VM section.

If you're on a real installation, run these three and read the output rather than guessing:

iw dev                        # is there a wireless interface at all?
rfkill list                   # is the radio blocked?
sudo systemctl status NetworkManager

That message — "Oops, something has gone wrong. Please contact your software vendor" — names no cause on purpose. It is a front end admitting it gave up. The actual fault is always one of five things underneath it, and four of the five things people believe about it are wrong.

nmcli device status

Arjun Reinstalled Kali Three Times

Arjun is Jake's nephew. He's halfway through a cybersecurity course, and he fixes the Wi-Fi in his uncle's phone shop in exchange for lunch, which is a rate Jake considers extremely favourable.

His course reached the wireless module. Every exercise started with the same sentence: put your adapter into monitor mode. Arjun's Kali had no adapter to put into anything. What it had was a grey box saying "Oops, something has gone wrong. Please contact your software vendor."

So he reinstalled Kali. Same screen. Different ISO, reinstalled again. Same screen. A third reinstall took most of a Sunday and produced the same screen a fourth time.

Ethan let him finish the story before saying anything.

"How is that Kali running?"

"VirtualBox."

"Then you've reinstalled the operating system three times to fix a piece of hardware that isn't plugged into the computer you installed it on."

Arjun objected that the internet worked fine — the objection almost everybody makes, and the reason this trap catches so many people. Internet working is not evidence that Wi-Fi exists. It's evidence that your hypervisor built you a virtual network cable.

Hold that thought. We come back to what Arjun bought, and what it cost, at the end.

What That Message Actually Tells You

Two messages bring people here, and they are two halves of the same event.

"Oops, something has gone wrong. Please contact your software vendor." A graphical shell or applet reporting that an operation failed with no better explanation to offer. In the networking case, the applet asked NetworkManager over D-Bus for the list of network devices and got either no reply or an empty one. D-Bus, if you haven't met it, is the message bus desktop programs use to talk to background services — it's how the little Wi-Fi icon knows anything at all.

"No Wi-Fi adapter found." The same fact, stated more usefully: there is no wireless interface available to manage.

Neither message tells you why. That vacuum is why the advice around this error is so poor — with no cause named, everybody guesses, and the guesses get copied. So let's take the five things people believe, and check them.

Myth 1: "My Wi-Fi Card Has Failed" — Wrong

This is the first conclusion nearly everyone reaches, and for the largest group of Kali users the card is fine — it just isn't in the machine they're looking at.

Most people learning Kali run it in a virtual machine, which is sensible: you get an isolated system you can break and rebuild. But here is what the hypervisor actually hands the guest:

Your VM's network adapter emulates an Intel PRO/1000 or a VMware vmxnet3 — a wired card. Wired cards have no radio, no channels, no monitor mode and no SSID list. From inside the guest, wireless hardware simply doesn't exist. Confirm it in five seconds:

$ iw dev
(nothing)

$ iwconfig
eth0      no wireless extensions.
lo        no wireless extensions.

$ lspci | grep -i network
00:03.0 Ethernet controller: Intel Corporation 82540EM Gigabit Ethernet Controller

"No wireless extensions" is not a fault report. It is the kernel telling you, accurately, that eth0 is not a radio.

Why the hypervisor won't hand over your internal card

Hypervisors virtualise disks, network paths and USB, because those have clean, well-defined interfaces. An internal Wi-Fi card is a PCIe device with its own firmware, its own power states and a regulatory domain tied to the physical machine. VirtualBox and VMware Workstation don't attempt it.

The exception is genuine PCI passthrough on a hypervisor such as KVM with IOMMU enabled in the BIOS. That works, but it removes the card from the host completely — your laptop loses Wi-Fi while the VM has it — and it's a long afternoon of configuration. For a student following a course, a USB adapter is a fraction of the effort.

The fix: a USB adapter with passthrough

VirtualBox:

1. Install the Oracle Extension Pack. USB 2.0 and 3.0 passthrough will not work without it, and the version must match your VirtualBox version exactly.
2. Shut the VM down completely — not saved state, actually powered off.
3. Settings → USB. Enable the USB controller and pick USB 2.0 (EHCI) unless you know your adapter is happy on 3.0. Some adapters are unstable on the xHCI controller.
4. Click the + icon on the right and select your adapter from the list to create a device filter.
5. Start the VM and run lsusb. Your adapter should be listed.

VMware Workstation or Player:

1. Start the VM, then VM → Removable Devices.
2. Find your adapter and choose Connect (Disconnect from host).

Once lsusb shows the adapter inside Kali, everything in the rest of this article applies to it normally. It may still need firmware — that's the next myth.

Two more environments worth naming, because people ask:

• Kali on WSL — no wireless access at all, and no monitor mode. Networking is shared with Windows. It's a fine place to run command-line tools and a bad place to do wireless work.
• Hyper-V — same story as VirtualBox for internal cards, and USB passthrough is far more awkward. If you're choosing a hypervisor for a wireless course, don't pick this one.

Myth 2: "Reinstall NetworkManager" — Wrong

Half the forum answers for this error say sudo apt install --reinstall network-manager. It's the wrong tool for the most common bare-metal cause.

Reinstalling replaces program files. It doesn't install firmware, doesn't clear an rfkill block, doesn't change your configuration files, and doesn't create hardware. If the message appears because your wireless chip never got its firmware blob, reinstalling NetworkManager a hundred times changes nothing.

Missing firmware is the single most common real cause on a physical machine.

What firmware even is, and why it's missing

Most modern Wi-Fi chips ship with almost no permanent software on board. At every boot, the Linux driver loads a small binary file — the firmware blob — into the chip's memory to bring it to life. No blob, no radio: the driver loads, the device stays dark, and NetworkManager honestly reports that it has nothing.

These blobs are proprietary, so Debian — and therefore Kali — keeps them in a separate repository component called non-free-firmware. If that component isn't in your sources, apt behaves as though the packages don't exist.

Step 1 — identify your chipset, don't guess it

Almost every guide hands you a list of firmware packages to install at random. Find out what you actually have instead:

lspci -nnk | grep -iA3 net     # internal cards: vendor, device ID, driver in use
lsusb                          # USB adapters
sudo lshw -C network           # a fuller picture, including "UNCLAIMED"

A typical lspci -nnk block looks like this:

02:00.0 Network controller [0280]: Intel Corporation Wi-Fi 6 AX200 [8086:2723]
	Subsystem: Intel Corporation Device [8086:0084]
	Kernel driver in use: iwlwifi
	Kernel modules: iwlwifi

Three things to read there:

• The vendor — Intel here, which points at firmware-iwlwifi.
• [8086:2723] — the exact vendor:device ID. Searching that pair finds answers for your precise card instead of generic ones. Worth doing before you buy anything.
• "Kernel driver in use" — if this line is absent, no driver has claimed the card at all, which is a different problem from missing firmware. lshw will show it as UNCLAIMED.

If you'd rather see the whole hardware picture at once, our guide to finding your device model and hardware details in Kali covers the other commands worth knowing.

Step 2 — ask the kernel what it wanted

This is the step that turns guesswork into a two-minute fix:

sudo dmesg | grep -i firmware
sudo dmesg | grep -iE 'iwlwifi|ath|rtl|brcm|mt76'

You're looking for a line like:

iwlwifi 0000:02:00.0: Direct firmware load for iwlwifi-cc-a0-72.ucode failed with error -2
iwlwifi 0000:02:00.0: no suitable firmware found!

That's the entire diagnosis in one line. The kernel names the exact file it looked for and couldn't find; -2 simply means "no such file". Now you know it's firmware — not NetworkManager, not the driver, not the card.

Step 3 — fix your sources, then install

Check the repository line first, because installing before this fails confusingly:

cat /etc/apt/sources.list

It must read exactly this, with non-free-firmware at the end:

deb http://http.kali.org/kali kali-rolling main contrib non-free non-free-firmware

If it's missing, edit the file with sudo nano /etc/apt/sources.list, add the component, save with Ctrl+O and exit with Ctrl+X. Then:

sudo apt update
sudo apt install firmware-linux firmware-linux-nonfree firmware-misc-nonfree \
                 firmware-iwlwifi firmware-realtek firmware-atheros \
                 firmware-brcm80211 firmware-ti-connectivity
sudo reboot

Install only the one your chipset needs if you prefer; installing them all is harmless and costs a few tens of megabytes. The reboot matters. Firmware is loaded when the driver initialises, and the driver initialises at boot. A restart of NetworkManager will not do it.

The chicken-and-egg problem

You need the internet to download the firmware that gives you the internet. Three ways out:

• Plug in an Ethernet cable. Boring, instant, works.
• USB tether your phone. Connect by cable and enable USB tethering in Android settings — Kali picks it up as a wired connection with no configuration.
• Download the .deb on another machine from the Debian package archive, copy it across on a USB stick, and install it with sudo dpkg -i firmware-iwlwifi_*.deb.

Myth 3: "rfkill unblock all Fixes Any Block" — Wrong

rfkill is Linux's kill switch for radios, and the single biggest source of wasted hours in this topic — because there are two kinds of block and only one can be cleared by a command.

rfkill list

0: phy0: Wireless LAN
	Soft blocked: yes
	Hard blocked: no
1: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no

Soft blocked: yes means software switched the radio off — aeroplane mode, a desktop toggle, or a leftover from a previous session. One command clears it:

sudo rfkill unblock wifi
sudo rfkill unblock all

Hard blocked: yes is a different thing entirely. It reports the state of physical hardware: a slider on the side of the laptop, or an Fn key with an aeroplane or antenna icon, or in some cases a BIOS setting.

When the hard block won't clear even at the keyboard

Three real causes, in the order they're worth checking:

1. You're pressing the wrong key. On many laptops the wireless key needs Fn held down; on others Fn is inverted in BIOS and the key works on its own. Watch rfkill list before and after — if the state doesn't change, that key isn't the switch.
2. Windows Fast Startup, on a dual-boot machine. Fast Startup doesn't fully shut down; it hibernates the kernel. If Windows had the radio disabled, the hardware can still be powered off when Kali boots. Turn Fast Startup off in Windows, do a full shutdown, then boot Kali. This one is rarely documented and catches a lot of dual-booters.
3. A vendor driver module is missing. Some laptops expose the wireless switch through a platform module such as ideapad_laptop or dell_laptop. Without it, the kernel misreads the switch and reports a permanent hard block. Check dmesg | grep -i rfkill and try sudo modprobe ideapad_laptop if that's your hardware.

If the block clears and Wi-Fi returns, your saved networks are still there — and if you need to read a password back off the machine, recovering saved Wi-Fi passwords from the terminal shows where NetworkManager stores them.

Myth 4: "The Adapter Is Gone, So the Hardware Died" — Wrong

Here's the case that produces the most panic: Wi-Fi worked yesterday, and today the adapter is simply absent from the menu. Nothing has physically failed. Something is holding the interface, or NetworkManager isn't running to notice it. Check which, in this order.

Is NetworkManager actually running?

sudo systemctl status NetworkManager

Capital N, capital M. On Kali there is no service called network-manager, and half the commands people copy from Ubuntu forums use that name and fail with Unit network-manager.service not found. That error message has sent a lot of people down the wrong path.

Start it, and make it stay started:

sudo systemctl enable --now NetworkManager
sudo systemctl restart NetworkManager

enable is what makes it survive a reboot; --now also starts it immediately. Skip enable and you'll be back here tomorrow morning.

If it starts and then dies, read the reason rather than retrying:

journalctl -u NetworkManager -b --no-pager | tail -40

Is the interface marked "unmanaged"?

nmcli device status

DEVICE  TYPE      STATE       CONNECTION
eth0    ethernet  connected   Wired connection 1
wlan0   wifi      unmanaged   --

unmanaged means NetworkManager can see the card perfectly well and has been told to keep its hands off it. The graphical applet then shows nothing, and reports no adapter.

Test it immediately:

sudo nmcli device set wlan0 managed yes

If the adapter appears, you've found it. That change doesn't survive a reboot, so now fix the cause, which is one of two files.

File 1: NetworkManager.conf

sudo nano /etc/NetworkManager/NetworkManager.conf

Look for this block:

[ifupdown]
managed=false

Change it to managed=true, save, and restart the service. This setting is Debian's way of saying "the old ifupdown system is in charge here" — sensible on a server, wrong on a desktop where you want to click a network name and connect.

File 2: /etc/network/interfaces

cat /etc/network/interfaces

On a normal Kali desktop this file should contain essentially nothing but the loopback:

auto lo
iface lo inet loopback

If wlan0 or eth0 is listed there — usually because a tutorial told you to add it, or an installer wrote it during a network install — the older ifupdown system claims that interface and NetworkManager deliberately steps aside. Two programs configuring one card is a worse outcome than none, so this behaviour is intentional.

Comment out or delete the interface entries, leave the loopback lines, then:

sudo systemctl restart NetworkManager
nmcli device status

The airmon-ng trap — monitor mode left switched on

This one deserves its own heading: it's enormously common among people learning Kali, and almost nobody writes it down. You follow a wireless tutorial. It tells you to run:

sudo airmon-ng check kill
sudo airmon-ng start wlan0

Read what those two lines actually did:

• check kill stops NetworkManager and wpa_supplicant. That is its entire job — those services retune the card and ruin captures, so airmon-ng kills them deliberately.
• start wlan0 switches the card to monitor mode and, on most setups, renames the interface to wlan0mon.

So after the tutorial: NetworkManager is dead, wlan0 no longer exists under that name, and the interface that does exist is in a mode NetworkManager will not manage. The desktop correctly reports no Wi-Fi adapter. Nothing is broken. You switched it off yourself, two commands ago.

The clean way back:

sudo airmon-ng stop wlan0mon
sudo systemctl start NetworkManager
sudo systemctl start wpa_supplicant

If airmon-ng stop doesn't restore it, do it by hand:

sudo ip link set wlan0mon down
sudo iw dev wlan0mon set type managed
sudo ip link set wlan0mon name wlan0
sudo ip link set wlan0 up
sudo systemctl restart NetworkManager

Each line in order: take the interface down, change it from monitor back to managed mode, rename it, bring it up, and hand it back. You cannot rename or change the type of an interface that is up, which is the same rule that produces "Could not change MAC: interface up or insufficient permissions" when people try to spoof a MAC address without bringing the card down first.

Myth 5: "Some Chipsets Are Just Painful on Linux" — True

Four myths down. This one is true, and pretending otherwise would waste your evening. Wi-Fi support on Linux is not uniform. Some chips work the moment you install a firmware package. Others need an out-of-tree driver compiled against your kernel, break on every kernel upgrade, and have a bug tracker full of people with your exact laptop model.

Broadcom

The classic problem family. Many older MacBooks and a lot of budget Dell and HP laptops use Broadcom BCM43xx chips. Depending on the exact model you may need firmware-brcm80211, broadcom-sta-dkms or firmware-b43-installer — and these use different, competing drivers (brcmsmac, b43, and the proprietary wl). If two are loaded at once, neither works.

lspci -nnk | grep -iA3 net       # get the exact [14e4:xxxx] device ID first
sudo modprobe -r b43 brcmsmac    # unload the ones you don't want
sudo modprobe wl                 # load the one you do

Get the device ID before you install anything. Installing the wrong Broadcom package is how people end up with no wireless at all rather than merely broken wireless.

Newer Realtek laptop cards

RTL8821CE, RTL8723DE and similar chips shipped in a lot of budget laptops before mainline Linux support existed. Kali packages DKMS drivers for several of them:

sudo apt install linux-headers-$(uname -r)
sudo apt install realtek-rtl88xxau-dkms      # RTL8812AU / 8814AU USB adapters
sudo apt install realtek-rtl8188eus-dkms     # RTL8188EUS USB adapters

DKMS stands for Dynamic Kernel Module Support. It rebuilds the driver automatically whenever you install a new kernel — which is the whole point, because without it your Wi-Fi dies at every kernel upgrade. The linux-headers package is required for that rebuild, and missing headers is the usual reason a DKMS driver silently stops working.

What actually works well

Intel cards are the best-behaved internal hardware on Linux by a clear margin: mainline driver, firmware in one package, monitor mode supported. Atheros is close behind. If you're specifying a laptop for security work, that is a real buying criterion rather than a detail.

The honest recommendation

If you have an awkward chipset and you have already spent two evenings on it, stop. A known-good USB adapter costs less than the hours you're spending, works in a VM, works on bare metal, and can be dedicated to lab work so it never takes your internet down.

Buy by chipset, not by brand or by box copy — the same product name is often sold with three different chips across revisions:

Check the chipset in the seller's specification, and check the hardware revision. And note that a newer Kali release often carries a newer kernel with better hardware support out of the box — sometimes the fastest fix for a stubborn card is simply upgrading to the current Kali release.

It Works Now — Making Sure It Still Works Tomorrow

The most demoralising version of this problem is the one that comes back. Three causes, all preventable.

It's gone after a reboot

You ran start without enable. One command, once:

sudo systemctl enable NetworkManager
systemctl is-enabled NetworkManager      # should print: enabled

It broke after an upgrade

A kernel upgrade can arrive before the matching firmware, or a DKMS module can fail to rebuild because the headers for the new kernel aren't installed. Keep them in step:

sudo apt update && sudo apt full-upgrade
sudo apt install linux-headers-$(uname -r)
dkms status

full-upgrade rather than upgrade matters here: plain upgrade refuses to install new packages or remove old ones, which is exactly what a kernel transition needs to do. dkms status tells you whether your out-of-tree driver actually built for the kernel you're now running.

If you're not sure which release you're on, checking your Kali version in the terminal takes one command, and an old install left un-upgraded for two years is worth replacing with a verified current ISO rather than dragged forward.

It connects, then drops every few minutes

Usually power management switching the card off when it looks idle. Check and disable:

iw dev wlan0 get power_save
sudo iw dev wlan0 set power_save off

To make it permanent, create /etc/NetworkManager/conf.d/wifi-powersave.conf containing:

[connection]
wifi.powersave = 2

The value 2 means off. The honest trade-off: this costs battery life on a laptop. On a desktop or a machine that lives on mains power, there's no downside.

For a USB adapter that vanishes entirely after a few minutes rather than just dropping, the cause is USB autosuspend instead, and the fix is the same one described in our Kali Bluetooth troubleshooting guide — the two radios fail the same way for the same reason.

If Nothing Above Worked

Collect these four outputs before you ask anywhere. They are what anyone competent will ask for, and having them turns a week of back-and-forth into one reply:

lspci -nnk | grep -iA3 net
sudo dmesg | grep -iE 'firmware|iwlwifi|ath|rtl|brcm'
rfkill list
nmcli device status

Two things worth naming plainly:

Reinstalling Kali is almost never the answer. It doesn't add firmware, doesn't clear a hard block, and doesn't create hardware inside a VM. Arjun's three reinstalls cost him a weekend and changed nothing.

Some hardware genuinely will not work. A handful of very new chips have no Linux driver yet, and a very old card can be dropped from the kernel. If lspci shows the card, lshw shows it UNCLAIMED, and no driver exists for that device ID, no command fixes it. That is the point to buy a USB adapter and get on with your course.

One security note: be careful about pasting dmesg or NetworkManager configuration into public forums. Those files can contain MAC addresses, SSIDs of networks you've joined, and occasionally saved credentials. Strip them first. If you want your traffic isolated once you're online again, kernel-level Tor isolation with oniux is the more thorough option, and Kali Undercover mode is worth knowing if you're working somewhere public.

Questions You're Probably About to Ask

Why does Kali Linux say "Oops, something has gone wrong. Please contact your software vendor"?

It's a generic front-end failure message. The network applet asked NetworkManager for a list of devices and didn't get a usable answer, so it gave up without naming a cause. The real fault is underneath: NetworkManager isn't running, or it's running and genuinely has no wireless device to report because you're in a VM, firmware is missing, rfkill has blocked the radio, or the interface was left in monitor mode.

Why does Kali say "No Wi-Fi adapter found"?

Because at that moment there's no wireless interface for NetworkManager to manage. Run iw dev and ip link. No wlan device listed means the kernel has no wireless interface at all — a VM, missing firmware, or a disabled card. A device listed but still "no adapter" means it's unmanaged, rfkill-blocked, or in monitor mode.

Does Wi-Fi work in Kali Linux inside VirtualBox or VMware?

Not as Wi-Fi. Both give the guest a virtual Ethernet card, so internet works through NAT, but the host's internal wireless adapter is never passed through. There's no wlan0 inside the guest and there never will be. A USB Wi-Fi adapter with USB passthrough is the only route.

Can I use my laptop's built-in Wi-Fi card in a Kali VM?

No. An internal card sits on the PCIe bus and hypervisors don't virtualise it. Only full PCI passthrough on something like KVM with IOMMU can hand it over, and that takes the card away from the host entirely. For everyday use, a USB adapter is the practical answer.

How do I find out which Wi-Fi chipset I have?

lspci -nnk | grep -iA3 net for internal cards, lsusb for USB adapters. Both print a vendor and a vendor:product ID such as 8086:2723. Then sudo dmesg | grep -i firmware shows the exact firmware file the kernel tried to load and failed on — that filename tells you the package, instead of guessing from a list.

How do I install missing Wi-Fi firmware in Kali Linux?

sudo apt update, then sudo apt install firmware-linux firmware-iwlwifi firmware-realtek firmware-atheros firmware-brcm80211 firmware-misc-nonfree, then reboot. Firmware is loaded when the driver initialises at boot, so the reboot is genuinely required and not superstition.

What is non-free-firmware and why does apt not find my package?

Wireless firmware is proprietary binary code, so Debian and Kali keep it in a separate repository component called non-free-firmware. If your sources.list line doesn't end with it, apt doesn't know those packages exist and says "Unable to locate package". Add the component, run sudo apt update, and install again.

What is the difference between an rfkill soft block and a hard block?

A soft block is software and clears with sudo rfkill unblock wifi. A hard block comes from the hardware — a physical slider or an Fn key with an aeroplane icon — and no command can clear it. If rfkill list says Hard blocked: yes, press the key. On dual-boot laptops, Windows Fast Startup can also leave the radio hardware-disabled.

How do I restart NetworkManager in Kali Linux?

sudo systemctl restart NetworkManager — capital N, capital M. It isn't called network-manager on Kali, which is why so many copied commands fail with "Unit not found". Use sudo systemctl enable --now NetworkManager to start it and keep it starting at every boot.

Why did my adapter disappear after I ran airmon-ng?

airmon-ng start puts the card into monitor mode and usually renames it to wlan0mon, and airmon-ng check kill deliberately stops NetworkManager and wpa_supplicant so they can't interfere. NetworkManager won't manage a monitor-mode interface, so your Wi-Fi looks like it vanished. Run sudo airmon-ng stop wlan0mon, then sudo systemctl start NetworkManager.

What does unmanaged mean in nmcli device status?

NetworkManager can see the interface but has been told not to control it. Usually managed=false in the [ifupdown] section of /etc/NetworkManager/NetworkManager.conf, or an entry for that interface in /etc/network/interfaces. Fix the file, or run sudo nmcli device set wlan0 managed yes for an immediate test.

Does the /etc/network/interfaces file stop NetworkManager working?

It can. If an interface is listed there, the older ifupdown system claims it and NetworkManager steps aside rather than have two programs configure the same card. On a normal desktop install, leave only the loopback entry in that file, then restart NetworkManager.

Which USB Wi-Fi adapter works best with Kali Linux?

For plain internet, almost anything with a mainline driver. For monitor mode and packet injection, buy by chipset rather than brand: Atheros AR9271, MediaTek MT7612U and Ralink RT3070 are the least trouble. Realtek RTL8812AU works well but needs realtek-rtl88xxau-dkms installed first.

Why does Wi-Fi stop working after every reboot or upgrade?

Three usual causes: you started NetworkManager without enabling it; a kernel upgrade landed without matching firmware or a rebuilt DKMS module; or a previous airmon-ng session left things behind. Run sudo systemctl enable NetworkManager, then sudo apt full-upgrade so kernel, headers and firmware move together.

Does Wi-Fi work in Kali on WSL?

No. Kali on Windows Subsystem for Linux has no direct access to wireless hardware. Networking is shared with Windows, there's no wlan0, and monitor mode isn't possible. For real wireless work, use a bare-metal install or a VM with a passed-through USB adapter.

Is reinstalling Kali the fastest fix?

Almost never. A reinstall doesn't add missing firmware, doesn't clear an rfkill hard block, and doesn't create a wireless adapter inside a virtual machine. If the cause is one of those, you land on exactly the same screen an hour later. Identify the cause first with iw dev, rfkill list and dmesg.

What Arjun Bought

An AR9271 adapter, about seven hundred rupees, delivered on the Tuesday. Extension Pack installed, USB filter added, VM started, lsusb showed it, iw dev showed wlan0. Unboxing to working monitor-mode interface: under ten minutes.

Set against three reinstalls and a wasted Sunday, that's the whole argument of this article in one purchase. The card in his laptop was never broken. It was never in the machine he was troubleshooting.

On Ethan's advice he kept it as the lab adapter and left the laptop's own Wi-Fi alone — so the next time a tutorial says airmon-ng check kill, he stays online.

Related Guides

Originally published January 2020. Rewritten in 2026. The original version recommended service network-manager restart and reinstalling the package, and we updated the same. Thanks for Stopping by!