When iwlist displays 5GHz frequencies but fails to complete a scan on Debian 11, the issue is almost always caused by regulatory domain restrictions or missing firmware. The wireless interface is blocked from scanning specific channels because the kernel enforces strict compliance rules based on your country code. Resolving this requires verifying and setting the correct regulatory domain via wpa_supplicant or iw reg set, ensuring proper driver support, and checking for hardware interference.
Understanding Regulatory Domain Restrictions
The primary reason a Wi-Fi scan appears to hang or fail on 5GHz bands is the wireless regulatory domain. Linux kernels enforce these domains to prevent users from transmitting on channels that are illegal in their geographic location. If the system does not know its current location, it defaults to a restrictive "world" mode, which often disables higher-frequency 5GHz channels like DFS (Dynamic Frequency Selection) bands. You can check your current regulatory domain by runningiw reg get. Look for the line starting with country. If it shows 00 (the default world domain), you are likely restricted. To fix this, you must explicitly set your country code using the ISO 3166-1 alpha-2 standard. For example, if you are in the United States, you would use:
sudo iw reg set US
This command updates the kernel's internal database of allowed frequencies. After executing this, try running your scan again. Note that changing the regulatory domain may require restarting the network manager service or reloading the wireless driver module for changes to take full effect. Be aware that incorrect country codes can lead to legal issues or interference with radar systems, so always verify your local regulations before modifying this setting.
Verifying Driver and Firmware Support
Even with the correct regulatory domain, scans can fail if the underlying driver lacks proper firmware or if the device is in a low-power state. Many modern Wi-Fi cards, particularly Intel AX series and Broadcom chips, require non-free firmware packages to operate fully on 5GHz bands. Debian 11 separates free and non-free software into different repositories. Check if your card is recognized correctly by runninglspci -nnk | grep -iA3 net. Look for the kernel driver in use. If the driver is listed as iwlwifi for an Intel card, ensure that the firmware-iwlwifi package is installed. You can install it via:
sudo apt update
sudo apt install firmware-iwlwifi
For Broadcom cards, you might need the bcmwl-kernel-source package. Without these proprietary blobs, the hardware may fall back to basic functionality, often limiting scan capabilities or disabling 5GHz entirely. Additionally, check for any firmware errors in the kernel log using dmesg | grep -i firmware. Missing files here will prevent the radio from initializing properly.
Using Wpa_Supplicant for Debugging
Ifiwlist continues to fail, switching to wpa_supplicant can provide more detailed diagnostics. The older iwlist tool is deprecated and sometimes struggles with modern drivers that rely on cfg80211. Instead of relying solely on legacy tools, configure wpa_supplicant to connect directly or perform a scan with verbose output.
Create a configuration file for your interface, typically named /etc/wpa_supplicant.conf, and add the following lines to enable debug logging:
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
debug=4
Then, start the daemon with:
sudo wpa_supplicant -i wlan0 -c /etc/wpa_supplicant.conf -d
Replace wlan0 with your actual interface name. The -d flag increases debug verbosity. Watch the terminal output; if you see messages about "regulatory domain" or "scan failure," it confirms the issue is policy-based rather than hardware-based. This method bypasses NetworkManager's abstraction layer, giving you direct access to the driver's status.
Checking for Hardware Interference and Power Management
Sometimes, the issue is not software configuration but physical or power-related constraints. Power management features in Linux can aggressively turn off Wi-Fi radios to save battery, causing them to become unresponsive during scans. Disable power management for your wireless interface using:sudo iw dev wlan0 set power_save off
Additionally, ensure that no other process is locking the interface. Tools like nmcli or NetworkManager might be interfering with manual scans. Stop the NetworkManager service temporarily to test:
sudo systemctl stop NetworkManager
Then attempt the scan again. If it succeeds, the issue lies in how NetworkManager manages the connection profile. Review your connection settings in the GUI or via nmtui to ensure the "Wi-Fi" tab allows scanning on all available bands. Also, consider physical interference; if you are near strong radar sources, DFS channels may be blocked until the radar clears, causing long scan timeouts.
Frequently Asked Questions
Why does my scan time out on 5GHz channels?
Timeouts usually occur when the system attempts to scan DFS channels that are currently occupied by radar signals. The kernel waits for a clear period, which can take several minutes. Switching to a non-DFS channel or adjusting your regulatory domain can resolve this delay.Is it safe to change the regulatory domain to 'US' if I am not in the USA?
No, it is not safe or legal. Using a foreign regulatory domain can cause interference with aviation radar and other critical services. Always use the country code corresponding to your physical location to comply with local laws and ensure optimal performance.How do I identify my Wi-Fi adapter model in Debian?
Runlspci -nnk | grep -i net for PCI adapters or lsusb for USB dongles. This command lists the vendor ID and product ID, allowing you to search online for specific driver requirements and firmware needs.
What should I do if NetworkManager conflicts with manual scans?
Stop the NetworkManager service usingsystemctl stop NetworkManager before running manual commands. Alternatively, disable auto-connect features in your connection profile to prevent the manager from overriding your manual scan attempts.