Debian 12 WiFi Idle Drops: Fix SSH & Apache Issues

Most likely the laptop’s Wi‑Fi radio or the router is dropping the client during short idle periods — a classic debian wifi symptom on battery‑aged or power‑managed hardware. On wifi debian 12 this commonly comes from Wi‑Fi power saving (NetworkManager/TLP/driver), aggressive AP/router inactivity timeouts, or buggy firmware; the visible effect is fast ssh disconnects and Apache becoming unreachable until the adapter is reset. Start by checking the interface power_save state and NetworkManager logs, then disable Wi‑Fi power save (temporary and persistent), update drivers/firmware, and add SSH keep‑alives; if you need a reliable home server, use wired Ethernet.

Contents

• Why Debian WiFi drops idle connections (wifi debian 12)
• Diagnostics — how to tell if the interface, driver, or router is the culprit (network manager debian)
• Fix 1 — Disable Wi‑Fi power save (wifi power save)
• Fix 2 — Prevent ssh disconnects with keep‑alives (ssh disconnect)
• Fix 3 — Driver, firmware, NetworkManager and AP settings
• Quick troubleshooting checklist & commands you can run now
• Sources
• Conclusion

Why Debian WiFi drops idle connections (wifi debian 12)

Short idle losses like you describe (works for a few seconds, stays alive while you hammer it, then dies after 10–15 s of inactivity) point to the radio or AP deciding the client is idle and effectively stopping traffic. A few common mechanisms cause that behavior:

• Wi‑Fi adapter power management (the interface goes into power_save or runtime suspend). The adapter may stop transmitting/receiving until it’s re‑woken, so TCP connections (SSH, HTTP) look dead until you restart the radio.
• Router/AP “client inactivity” or aggressive power save on the access point — some home routers aggressively disassociate quiet clients.
• Driver or firmware crashes on idle (older laptop, outdated linux‑firmware or driver bugs). You’ll often see messages in dmesg/journal when that happens.
• NAT or firewall timeouts — less likely for a 10–15 s drop (those are usually minutes), but keep‑alives can help if the router is removing mappings.

Why does active use keep services working? Because any packet (page refresh, background SSH traffic) prevents the radio from sleeping and keeps the router’s state fresh. So “it works when I use it” is a huge hint: traffic = alive; silence = sleep or disassociation.

For background reading and Debian‑specific tips see the Debian Wi‑Fi HowTo and community threads on power management and SSH keep‑alives: https://wiki.debian.org/WiFi/HowToUse and https://askubuntu.com/questions/1386217/wifi-power-management-keeps-turning-on.

Diagnostics — how to tell if the interface, driver, or router is the culprit (network manager debian)

Before changing configs, gather a few facts so you know what you’re fixing.

What to check now (run these while the server is responsive, and again immediately after an idle drop):

1. Is the interface actually up?

ip addr show
nmcli device status

2. Is power save enabled?

iw dev wlpXs0 get power_save
# or
iwconfig wlpXs0

If the output shows Power Management:on or power_save enabled, that’s a prime suspect.

3. Any kernel/driver messages during the drop?

sudo journalctl -f -u NetworkManager
# in another terminal, reproduce the drop
sudo dmesg --ctime | tail -n 50

4. Does the machine still respond to ARP/pings locally while services are “down”?
   From another LAN machine:

ping 192.168.1.2 -c 5
arping -I <iface> 192.168.1.2

If pings fail immediately after idle, the interface is likely down or disassociated. If ping succeeds but TCP connections fail, that’s a different problem.

5. Is traffic arriving at the server while it’s “unreachable”?
   On the server:

sudo tcpdump -i wlpXs0 port 22 or port 80

If no packets show up, the radio or AP dropped the client. If packets arrive but no response is sent, the server’s network stack or firewall may be blocking replies.

6. Check the router/AP logs and Wi‑Fi settings (client inactivity timeout, power saving or “AP isolation”).

If the evidence points to power save or disassociation (most likely given 10–15 s), proceed to disabling Wi‑Fi power save.

Fix 1 — Disable Wi‑Fi power save (wifi power save)

Temporary test (no reboot, session only)

sudo iw dev wlpXs0 set power_save off
iw dev wlpXs0 get power_save # should say "off"

If that immediately fixes the symptom (server stays reachable when idle), make it persistent.

NetworkManager persistent fix (recommended for many setups)

sudo tee /etc/NetworkManager/conf.d/wifi-powersave.conf > /dev/null <<EOF
[connection]
wifi.powersave = 2
EOF

sudo systemctl restart NetworkManager

This tells NetworkManager to turn off Wi‑Fi power management. See community steps here: https://askubuntu.com/questions/1386217/wifi-power-management-keeps-turning-on and Debian guidance: https://wiki.debian.org/WiFi/HowToUse.

TLP (if you use TLP/power management)

• Install and edit /etc/tlp.conf, set:
• WIFI_PWR_ON_AC=off
• WIFI_PWR_ON_BAT=off
• Then restart TLP:

sudo apt install tlp
sudo systemctl enable --now tlp
sudo tlp start

Driver/module option (Intel iwlwifi example)

echo 'options iwlwifi power_save=0' | sudo tee /etc/modprobe.d/iwlwifi.conf
sudo update-initramfs -u
# Reboot to apply, or reload module if safe

Realtek and other chips have different module options — check lspci -nnk or lsusb and search for vendor/module-specific params.

Why multiple methods? NetworkManager can override lower‑level settings, and TLP may re‑apply power saving on suspend/resume. Use the method that matches your stack (NetworkManager + TLP is common on laptops).

After changes, verify:

iw dev wlpXs0 get power_save
nmcli connection show <your-connection> | sed -n '1,40p'

If disabling power save fixes the problem, you’ve solved the root cause. If not, keep reading.

Fix 2 — Prevent ssh disconnects with keep‑alives (ssh disconnect)

Keep‑alives don’t stop the adapter from sleeping, but they help with NAT/router timeouts and will often mask the issue if the AP/router is the only device closing the session.

Client‑side (recommended, no server change needed)
Add to ~/.ssh/config:

Host *
 ServerAliveInterval 60
 ServerAliveCountMax 3

Or use the command line:

ssh -o ServerAliveInterval=60 user@192.168.1.2

Server‑side (optional)
Edit /etc/ssh/sshd_config and set:

ClientAliveInterval 60
ClientAliveCountMax 3

Then:

sudo systemctl reload sshd

Notes:

• ServerAliveInterval (client) sends packets from the client to the server; that keeps NAT/routers from forgetting the mapping. See practical tips here: https://superuser.com/questions/699676/how-to-prevent-ssh-from-disconnecting-if-its-been-idle-for-a-while and https://www.cyberciti.biz/tips/open-ssh-server-connection-drops-out-after-few-or-n-minutes-of-inactivity.html.
• OpenSSH has newer directives (OpenSSH 9.2+) such as ChannelTimeout and UnusedConnectionTimeout for different behaviors — see a discussion and examples on ServerFault: https://serverfault.com/questions/1162826/how-to-ensure-that-ssh-drops-the-connection-after-8-hours-of-no-typing

Remember: keep‑alives are a workaround for router/NAT timeouts. If the adapter truly suspends, keep‑alives won’t help because packets never reach the server.

Fix 3 — Driver, firmware, NetworkManager and AP settings

If power saving is off and keep‑alives don’t help, dig deeper:

1. Update firmware/drivers

sudo apt update
sudo apt install --reinstall linux-firmware
sudo apt upgrade
# reboot if kernel or firmware updated

Older firmware or kernel drivers frequently cause link drops on idle.

2. Check the actual kernel module and vendor driver

lspci -nnk | grep -iA3 net
lsusb
modinfo <module-name>

Search for module‑specific parameters you can disable (power_save, swlps, etc.). Community threads on permanently disabling power management for particular chipsets can be found here: https://unix.stackexchange.com/questions/269661/how-to-turn-off-wireless-power-management-permanently.

3. If you run iwd vs wpa_supplicant:

• On Debian 12 you may prefer iwd for some cards. If both services fight, disable the unused supplicant:

sudo systemctl disable --now wpa_supplicant

Check the Debian Wi‑Fi howto for iwd tips: https://wiki.debian.org/WiFi/HowToUse.

4. Router/AP side:

• Log into 192.168.1.1 and search for “inactivity timeout”, “sleep mode”, “WMM APSD”, or “station timeout”. Turn off aggressive power saving or increase inactivity thresholds.
• Check for router firmware updates. Consumer routers sometimes have bugs that drop quiet clients.

5. If reliability is essential: use wired Ethernet. It’s the simplest and most robust fix for a home server.

Quick troubleshooting checklist & commands you can run now

A short, prioritized list to run on the server while you reproduce the failure.

1. Confirm interface and power save:

ip a
iw dev wlpXs0 get power_save
iwconfig wlpXs0

2. Watch logs while you idle the connection:

sudo journalctl -f -u NetworkManager
sudo dmesg --follow

3. Temporary disable power save and test:

sudo iw dev wlpXs0 set power_save off
# Then open another device and idle; see if problem recurs

4. Test keep‑alive workaround:

ssh -o ServerAliveInterval=60 user@192.168.1.2
# Or add ServerAliveInterval to ~/.ssh/config

5. If disabling power_save helped, make it persistent (NetworkManager conf) and restart NetworkManager:

sudo tee /etc/NetworkManager/conf.d/wifi-powersave.conf > /dev/null <<EOF
[connection]
wifi.powersave = 2
EOF
sudo systemctl restart NetworkManager

6. If the problem persists, update firmware and drivers:

sudo apt update && sudo apt upgrade
sudo apt install --reinstall linux-firmware
sudo reboot

7. Capture packets to confirm whether traffic reaches the server:

sudo tcpdump -i wlpXs0 port 22 or port 80 -w /tmp/trace.pcap
# Analyze with tcpdump -r or Wireshark on another machine

Follow that sequence and you’ll either cure the issue or gather the logs needed to target a driver/firmware bug or a router setting.

Sources

• Debian Wiki — WiFi/HowToUse: https://wiki.debian.org/WiFi/HowToUse
• Ask Ubuntu — WiFi power management keeps turning on: https://askubuntu.com/questions/1386217/wifi-power-management-keeps-turning-on
• Unix & Linux — How to turn off Wireless power management permanently: https://unix.stackexchange.com/questions/269661/how-to-turn-off-wireless-power-management-permanently
• Server Fault — How to ensure that SSH drops the connection after 8 hours of no typing? (OpenSSH notes): https://serverfault.com/questions/1162826/how-to-ensure-that-ssh-drops-the-connection-after-8-hours-of-no-typing
• Superuser — How to prevent SSH from disconnecting if it’s been idle for a while: https://superuser.com/questions/699676/how-to-prevent-ssh-from-disconnecting-if-its-been-idle-for-a-while
• nixCraft / Cyberciti — OpenSSH server connection drops out after inactivity: https://www.cyberciti.biz/tips/open-ssh-server-connection-drops-out-after-few-or-n-minutes-of-inactivity.html
• 2DayGeek — Automatically disconnect idle or inactive SSH sessions: https://www.2daygeek.com/automatically-disconnect-inactive-idle-ssh-sessions-linux/
• GoLinuxCloud — Keep idle SSH session active or disconnect: https://www.golinuxcloud.com/disconnect-idle-ssh-session-tcpkeepaliv-linux/

Conclusion

This is almost certainly a network-level issue: the Wi‑Fi radio is being put to sleep or the AP/router is disassociating idle clients, causing ssh disconnects and Apache to appear offline until the adapter is resurrected. The fastest path to a reliable home server is to disable Wi‑Fi power save (NetworkManager/TLP or module options), update firmware/drivers, add SSH keep‑alives to work around NAT timeouts, and—when feasible—move the server to wired Ethernet. Start with the simple checks and the NetworkManager wifi.powersave tweak; if that doesn’t fix it, collect kernel logs and driver info and we can dig into firmware or router bugs.