Identifying the cause: laptop losing connectivity intermittently (FIXED)
Last updated on May 30th, 2025Intermittent network connectivity issues can be very frustrating to diagnose. Having just had to resolve such an issue myself, I thought I’d share a guide for others, using my experience as an example.
Identify issue frequency
The first step is to understand how intermittent your connectivity issue really is. I wrote a network connectivity monitoring python script to monitor for issues every few seconds and alert (through sound and text output) to connection failures. You can run this on Linux or Windows by simply saving the code to a file with a .py extension, and then calling it from your python installation e.g. python3 pingtest.py.
In my case, I was surprised by the result which showed a more frequent issue than I’d expected, and a fairly consistent pattern too (loss approximately every 4-5 minutes).
Armed with the knowledge of the frequency (and a sound-based alert each time the issue occurs), you can dig deeper into the cause.
Internet connection stability
It’s always sensible when diagnosing an issue to start wider (somewhere with no issue) and narrow down to identify the breadth of the impact.
Your home router should provide details of “uptime” (how long it has remained connected to the Internet). If you haven’t recently unplugged or restarted your router, this should generally be multiple days. If it is only second, minutes or hours, it may be sensible to return it later, to see if this remains the case. If it does, call your provider to report this instability.
In my case, whilst I was confident the issue was isolated to a single device, I logged into my home router. It showed the uptime was around 60 days… a reassuring sign.
Wifi signal strength
The next layer to check was the wifi signal (as my connectivity issues were over wifi). Metal objects, electrical equipment (e.g. TV) and other wifi networks can affect a device’s ability to maintain a good connection with the router.
From a smartphone
I use a few apps on my Android phone to check wifi networks. My favourite is WiFi Analyzer. I use the premium (paid) version, but the free version works just as well if you’re OK with adverts in the app. Using such an app helps ensure there are no overlapping signals from neighbouring wifi networks etc. You can also see the signal strength and easily move around to check the strength around your property.
From the affected device
Once you’re happy the signal doesn’t overlap with neighbours and looks good from a smartphone, it’s time to check the signal strength the affect device is seeing. A low signal strength on just one device (in the same location as unaffected devices) may point to a physical antenna issue in the device).
In Windows operating systems, running netsh wlan show interfaces from the Command Prompt will show the signal strength as a percentage under “signal”. You’ll want to target at least 60% to minimise the risk of issues.
In Linux operating systems such as Ubuntu, running iw dev wlp3s0 link provides details about the current connection including signal strength in decibel milliwatts (dBm) under “signal”. You will need to replace wlp3s0 with your wifi network adaptor’s name.
If you’re not familiar with Linux, you can find your network adaptor name by running ls /sys/class/net (provides a simple output), ifconfig (more complex output but easier to type) or nmcli connection show (won’t work if you don’t have NetworkManager installed, though it is commonly installed in Linux distros by default).
Wifi network adaptors tend to start with “wl” (for wireless LAN) or “ww” (for wireless WAN), ethernet (cabled) connections tend to start with “en”, and loopback (virtual links internally) devices tend to start with “lo”.
When looking at wifi signal in decibel milliwatts, closer to zero is best. Anything between -30 dBm and -60 dBm is ideal:
- -30 dBm: This is maximum possible signal strength (you’re probably standing beside your router)
- -60 dBm: Should provide a good, reliable connection
- -70 dBm: OK for basic web browsing. Not ideal for phone calls/streaming
- -80 dBm: Likely to provide an unstable connection
- -90 dBm and beyond: Unlikely to be usable
Power saving on network adaptor
The power saving settings on network adaptors are renowned as a potential cause on connectivity issues so well worth turning off temporarily at least, to see if it resolves your issue.
You can turn wifi power saving off permanently in Windows by:
- Open Device Manager
- Under “Network Adaptors” find your wifi adaptor and open the properties for it
- On the “Advanced” tab, look through the settings for your adaptor (these vary by adaptor) and see if yours has a power saving option. If it does, make a note of the current setting and choose a suitable alternative setting to disable it.
You can check the wifi power saving mode in Linux by running: sudo iw dev wlp3s0 get power_save. You will need to replace wlp3s0 with your wifi network adaptor’s name.
You can turn wifi power saving off temporarily in Linux by running: sudo iw dev wlp3s0 set power_save off
This will immediately take effect, but is not persistent and will revert after a reboot or network adaptor reset. If this successfully resolves your issue, you can make it permanent by running nmcli connection modify "MyWifi" wifi.powersave 2 where “MyWifi” is your wifi SSID. Then restart your wifi connection (turn it off and on), you can do this with this command if you like: nmcli connection up "MyWifi", again replacing “MyWifi” with your wifi SSID.
Update network adaptor drivers
If still not resolved it’s worth checking you are running suitably up-to-date network adaptor drivers at this point.
For Windows users, you’ll want to visit your device vendor’s support pages, and download the latest driver.
For Linux users, you may want to do likewise, or use Linux generic drivers (the default in most distros). You can check the driver you’re using by running lspci -k | grep -A 3 "Network controller"
In my case, I use Linux generic drivers and felt it was unlikely to be the cause of the issue, so didn’t make any changes. As a possible cause this shouldn’t be forgotten if you also choose to skip this step.
Check journal / Event Viewer logs
Both Linux and Windows have core logs that may show signs of the issue occurring. In Windows this is Event Viewer, in Linux it is system and user journals.
With the script still running, we can await until an alert goes off and then check recent entries in these logs.
On my Linux device I ran journalctl -u NetworkManager --since "2 minutes ago" shortly after an alert. Windows users should open the Event Viewer and refresh shortly after an issue, or check events around the time of a known connectivity issue.
In my case, the Linux journal showed a long list of NetworkManager activity everytime the alert went off, for example:
May 17 13:21:14 artexic-laptop NetworkManager[1886]: [1747484474.7398] device (wlp3s0): supplicant interface state: completed -> authenticating
May 17 13:21:14 artexic-laptop NetworkManager[1886]: [1747484474.7399] device (p2p-dev-wlp3s0): supplicant management interface state: completed -> authenticating
May 17 13:21:14 artexic-laptop NetworkManager[1886]: [1747484474.7614] device (wlp3s0): supplicant interface state: authenticating -> associating
May 17 13:21:14 artexic-laptop NetworkManager[1886]: [1747484474.7615] device (p2p-dev-wlp3s0): supplicant management interface state: authenticating -> associating
May 17 13:21:14 artexic-laptop NetworkManager[1886]: [1747484474.7680] device (wlp3s0): supplicant interface state: associating -> disconnected
May 17 13:21:14 artexic-laptop NetworkManager[1886]: [1747484474.7681] device (p2p-dev-wlp3s0): supplicant management interface state: associating -> disconnected
May 17 13:21:14 artexic-laptop NetworkManager[1886]: [1747484474.8675] device (wlp3s0): supplicant interface state: disconnected -> scanning
May 17 13:21:14 artexic-laptop NetworkManager[1886]: [1747484474.8676] device (p2p-dev-wlp3s0): supplicant management interface state: disconnected -> scanning
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.7948] device (wlp3s0): supplicant interface state: scanning -> authenticating
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.7949] device (p2p-dev-wlp3s0): supplicant management interface state: scanning -> authenticating
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8079] device (wlp3s0): supplicant interface state: authenticating -> associating
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8103] device (p2p-dev-wlp3s0): supplicant management interface state: authenticating -> associating
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8179] device (wlp3s0): supplicant interface state: associating -> associated
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8180] device (p2p-dev-wlp3s0): supplicant management interface state: associating -> associated
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8357] device (wlp3s0): supplicant interface state: associated -> 4way_handshake
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8358] device (p2p-dev-wlp3s0): supplicant management interface state: associated -> 4way_handshake
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8746] device (wlp3s0): supplicant interface state: 4way_handshake -> completed
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8770] device (wlp3s0): ip:dhcp4: restarting
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8775] dhcp4 (wlp3s0): canceled DHCP transaction
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8776] dhcp4 (wlp3s0): activation: beginning transaction (timeout in 45 seconds)
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8777] dhcp4 (wlp3s0): state changed no lease
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8778] dhcp4 (wlp3s0): activation: beginning transaction (timeout in 45 seconds)
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8782] device (wlp3s0): ip:dhcp6: restarting
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8837] dhcp6 (wlp3s0): canceled DHCP transaction
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8838] dhcp6 (wlp3s0): activation: beginning transaction (timeout in 45 seconds)
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8838] dhcp6 (wlp3s0): state changed no lease
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8840] dhcp6 (wlp3s0): activation: beginning transaction (timeout in 45 seconds)
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.8843] device (p2p-dev-wlp3s0): supplicant management interface state: 4way_handshake -> completed
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.9061] dhcp6 (wlp3s0): state changed new lease
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.9125] dhcp4 (wlp3s0): state changed new lease, address=192.168.1.12, acd pending
May 17 13:21:19 artexic-laptop NetworkManager[1886]: [1747484479.9138] dhcp4 (wlp3s0): state changed new lease, address=192.168.1.12
This would repeat multiple times for each disconnection.
Reading through the log entries, it’s clear the device is reconnecting to the router each time an issue is seen. The 4way_handshake entries suggest it is renegotiating the security keys for the connection, which could explain the disruption to the connection.
You may need to perform Internet searches of keywords from your errors to understand exactly what the errors relate to.
My issue: lease duration
Given the messages in my journal output, I wanted to look into the lease further. I checked my home router, which showed an indefinite lease was in-place. This seemed like a positive thing in terms of avoiding disconnections. However, this turned out to be the cause.
You can run nmcli -f DHCP4 con show "MyWifi" | grep "dhcp_lease_time" on Linux (if nmcli is installed), where “MyWifi” is your wifi SSID, to check your current wifi lease time.
Whilst my router had a lease defined, checking the client itself (for Ubuntu desktop NetworkManager, configured under /etc/dhcp/dhclient.conf) I found that a 5-minute timeout was set locally. This would likely cause the local client to seek a new lease, even when the router was happy the current lease was still valid.
I’m not sure why NetworkManager has a locally defined lease timeout as standard, but I commented it out in /etc/dhcp/dhclient.conf to finally resolve my connectivity issues.
If this isn’t the cause of your issues, I would still recommend changing your lease setting to a numeric value of 24 hours or less if yours is indefinite or greater than 24 hours, to see if this resolves your issue.
Other factors to check
If you’re still experiencing issues, I would recommend considering:
Disabling IPv6
You can temporarily disable IPv6 on Linux by running the below:
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1
sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1If this resolves the issue, you’ll need to edit /etc/sysctl.conf to maintain this configuration after reboots.
Add these lines to /etc/sysctl.conf to disable ipv6 permanently:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1Change wifi band
Whilst you’d normally leave a device to automatically choose wifi bands, if you have at least two bands running (e.g. 2.4GHz, 5GHz, and 6Ghz), you may want to try turning all but one option off on your router, or instructing your device to connect to one partcular band, to see if this resolves your issue.
On Linux you can switch to a different band by running something like nmcli connection modify "MyWifi" 802-11-wireless.band a followed by nmcli connection up "MyWifi" where “MyWifi” is your wifi SSID. You can set the band to “a” or “bg”:
- a: Forces the connection to use the 5GHz band (802.11a)
- bg: Forces the connection to use the 2.4GHz band (802.11b/g)
NetworkManager doesn’t currently support forcing 6GHz, so “ax” (for Wifi 6E) and “be” (for Wifi 7) will return an error for now. Hopefully this will change in the future.
I hope this guide was helpful in tracing the root cause of your network connectivity issue. If not, please do share any other checks that helped you in the comments so others can benefit too.