Start your 3-day free trial
Sign up to experience all premium features at no cost.
*Available only to new users. Each user is limited to one trial.
What to Do When Wi-Fi Is Not Working on Ubuntu
Kevin Wu
August 27, 2026· Updated October 4, 2026· 9 min read
When Wi-Fi is not working on Ubuntu, run nmcli device status and rfkill list first: together they show whether the adapter is missing, blocked, or present but not connecting, which tells you which stage to fix. The failure then falls into one stage: no adapter, a blocked radio, an absent network name, failed authentication, no address, or a connection without internet. Ubuntu’s wireless troubleshooter uses the same staged approach: identify the device, verify a connection, inspect the router, then consider drivers.［1］
Key Takeaways:
- Classify the failure as detection, radio, discovery, authentication, addressing, or internet access.
- Use
nmcli,rfkill, and hardware information first because they do not rewrite the network setup.- Investigate drivers only after the adapter and failure stage are identified from trustworthy evidence.
Step 1: If Wi-Fi is not working on Ubuntu, identify the failure stage
| Symptom | First branch |
|---|---|
| No Wi-Fi control or adapter | Hardware detection, firmware, or driver support. |
| Wi-Fi exists but is disabled | Hardware switch, Airplane mode, or rfkill. |
| Adapter works but SSID is absent | Range, hidden SSID, band/channel support, or router. |
| Password is rejected | Network selection, security mode, credentials, or time. |
| Connected but no address/internet | DHCP, captive portal, router, route, or DNS. |
Compare another device on the same network and this Ubuntu device on a trusted alternative network. If every device fails, use the router no-internet guide. If only names fail after IP connectivity is proven, use the Ubuntu DNS guide. If other devices or apps on this PC misbehave too, follow the general device troubleshooting order before changing Wi-Fi settings.
Keep the test conditions stable: use the same physical location, user session, and access point while classifying the symptom. A laptop that works after moving closer may have a signal, antenna, band, or roaming problem. One that fails only after resume may point toward power management or a driver state transition. These observations are more useful than a generic “sometimes broken” report.
Write down the last known working kernel and whether the problem appeared after an update, hardware change, or firmware setting change. Treat this as timing evidence, not proof of cause. Do not roll back packages or firmware until the responsible layer has been identified and a supported recovery path exists.
Step 2: Read NetworkManager and radio state
Run these non-destructive commands:
nmcli general status
nmcli device status
nmcli radio
rfkill list
nmcli reports NetworkManager status, devices, and radio state; its manual distinguishes device state from connection profiles.［2］ rfkill shows whether wireless devices are soft- or hard-blocked. A soft block can normally be cleared through the desktop control or rfkill unblock wifi; a hard block usually requires a physical switch, firmware setting, or platform-specific action. Do not try to override a hard block with random scripts.
If NetworkManager is not managing the interface on a server or managed system, stop and identify the actual network owner before changing profiles.
Read each command together. An enabled Wi-Fi radio does not prove that an adapter exists, and an adapter listed as unavailable may still be blocked, unmanaged, or missing firmware. If multiple wireless interfaces appear, identify the one physically in use before unblocking or changing anything.
Save a short before-state containing the interface name, device state, and soft/hard block result. Do not post full connection profiles: they may include SSIDs, usernames, certificate paths, or organization details. After one reversible action, rerun the same commands and compare only the relevant fields.
Step 3: Confirm that Ubuntu detects the adapter
Use read-only hardware information:
lspci -nnk
lsusb
sudo lshw -C network
The adapter vendor/device ID and the kernel driver in use are more useful than a generic “Wi-Fi missing” report. If the device is absent everywhere, inspect hardware, firmware settings, or a removable adapter. If it is listed without a driver, check the Ubuntu release’s official support and the hardware manufacturer.
Do not add a random PPA, pipe a driver installer into a shell, blindly blacklist kernel modules, or disable Secure Boot merely to make an unsigned driver load. Those actions can weaken boot integrity or remove a working fallback. Ubuntu software source choices explains why source provenance matters.
When reporting the adapter, include both the vendor/device ID and the kernel driver line. Product names alone can cover several hardware revisions. If the device appears in lsusb or lspci but no network interface exists, capture the relevant kernel message before reloading modules or rebooting; the first failure often contains the clearest firmware or initialization error.
For a removable adapter, test another known-good port without using an unpowered hub. For an internal adapter, confirm that firmware settings have not disabled wireless. Stop if opening the computer would affect warranty, safety, or organization ownership.
Step 4: Scan and connect when Ubuntu is not connecting to Wi-Fi
The desktop network menu is the normal connection path described by Ubuntu.［3］ For diagnostics, run:
nmcli device wifi list
nmcli connection show
Do not put a Wi-Fi password in a command that will remain in shell history or a support log. If the SSID is absent, move closer, check whether it is hidden, and verify that the adapter supports the router’s band and channel. Do not change the entire router when only this adapter cannot see one band.
For repeated authentication failures, verify the exact SSID and credentials on another trusted device. Organization Wi-Fi may require certificates, identity fields, or administrator-provided profiles; do not weaken the router’s security mode as a workaround.
If a saved profile may be stale, first record whether it contains organization certificates, a hidden SSID, a static address, or custom routes. Removing and recreating a simple home-network profile is recoverable when the password is known; deleting an enterprise profile without its setup package may not be. Use the narrowest recovery action for the profile you actually own.
When an SSID is visible but connection attempts loop, note whether failure occurs before or after a password prompt. A rejected credential, an unsupported security mode, and a DHCP timeout can look similar in the desktop menu but belong to different stages.
To see why an attempt failed, read this boot's NetworkManager log right after it with journalctl -b -u NetworkManager. A failure reason such as no-secrets or supplicant-timeout points to credentials, security mode, or an enterprise profile; ip-config-unavailable means association worked and the problem has moved to addressing in Step 5. Remove passwords, usernames, and certificate details before sharing any log lines.
Step 5: Separate address, portal, internet, and DNS
After association, inspect rather than reset:
nmcli -f GENERAL,IP4,IP6 device show
ip route
A connection without a usable address or default route points toward DHCP or profile configuration. A valid address and route with no internet points to a captive portal, router, upstream provider, proxy, or policy. A working IP path with failing hostnames belongs to DNS. Preserve the exact error and change one layer at a time.
Open a browser only after association and addressing succeed, and follow the network owner's normal captive-portal instructions. Do not install a certificate or disable HTTPS warnings to make a portal work. If the gateway is reachable but the wider internet is not, compare another device before editing Ubuntu routes.
If only DNS fails, preserve the resolver owner and current configuration. NetworkManager, systemd-resolved, a managed profile, or another approved tool may own it. Avoid replacing all name servers during a Wi-Fi investigation because that hides the original failure and crosses into a separate troubleshooting path.
Step 6: Investigate drivers only with device-specific evidence
Investigate drivers after proving that Ubuntu detects the hardware but cannot operate it, or after logs show a device/firmware error. Record the Ubuntu release, kernel, adapter ID, driver, and relevant boot-time message. Prefer Ubuntu repositories, documented Additional Drivers, or the hardware vendor’s supported package. Keep an older working kernel available when an update introduced the regression.
Test a supported live environment only when you understand that it is a comparison, not a repair. If Wi-Fi works there, the installed system's driver, firmware, profile, or policy remains suspect; if it fails there too, hardware support becomes more likely. Do not use the result to justify unsigned modules or an unverified installation script.
Summary
Classify the failure before editing configuration. Read NetworkManager, rfkill, and hardware state; confirm SSID and authentication; then separate address, portal, upstream, and DNS. Use official driver sources only, and do not bypass Secure Boot or blacklist modules without device-specific evidence and a rollback path.
FAQ
Why is there no Wi-Fi option in Ubuntu?
The adapter may be undetected, unmanaged, blocked, missing supported firmware, or disabled in hardware. Start with nmcli device status, rfkill list, and hardware IDs.
What is the difference between a soft and hard rfkill block?
A soft block is controlled by software. A hard block reflects a hardware or platform state and normally cannot be cleared by software alone.
Why can Ubuntu not see my SSID?
Range, a hidden name, band/channel compatibility, router configuration, or adapter state may be involved. Compare another network and device.
Should I type the Wi-Fi password into an nmcli command?
Avoid placing secrets in command history or shared logs. Use the desktop prompt or a secure supported method.
Does Connected prove internet access?
No. Address assignment, default route, captive portal, router upstream, and DNS remain separate layers.
Should I disable Secure Boot to install a driver?
Not as a generic fix. First verify official support and signed packages; disabling Secure Boot changes an important integrity boundary.
Can I install a driver from a random PPA or script?
No. Use Ubuntu repositories, documented support, or the device manufacturer, and keep a rollback path.
What should I send to support about Ubuntu Wi-Fi problems?
Send the Ubuntu and kernel versions, adapter ID, driver, nmcli/rfkill state, exact error, and comparison results. Remove SSIDs, MAC addresses, and credentials when unnecessary.
Disclaimer: Hardware support varies by Ubuntu release, kernel, firmware, and device model. Preserve a working boot option before driver changes. AethoVPN needs Ubuntu's Wi‑Fi interface and driver to establish ordinary connectivity first; it cannot load missing firmware or repair radio hardware.
Sources:
- Ubuntu Desktop Guide — Wireless network troubleshooter — https://help.ubuntu.com/stable/ubuntu-help/net-wireless-troubleshooting.html
- Ubuntu Manpage Repository — nmcli(1) — https://manpages.ubuntu.com/manpages/jammy/man1/nmcli.1.html
- Ubuntu Desktop Guide — Connect to a wireless network — https://help.ubuntu.com/stable/ubuntu-help/net-wireless-connect.html.en
Sources checked 4 October 2026.
Related Articles:
