You are not logged in.
Yesterday I was fighting all day with a strange issue of my Laptop's wifi refusing to work every time I closed/reopened the lid.
This morning, I got up and wanted to get some more info on the issue but it just vanished into thin air. I cannot get it to break again.
Here's what was happening yesterday:
While in broken state after suspending through lid close:
- "nmcli device wifi list" only showed nothing
- "ip link" showed my wifi card as "state DOWN", "ip link set dev <name> up" had no visible effect
While in working state:
- "nmcli device wifi list" showed only the network I was connected to but none of the nearby networks
- ip link behaved normally
Today though, all issues are gone. Nmcli shows all nearby networks, wifi works before and after suspending.
Here's my question:
The next time everything breaks, what are all the places I can find useful diagnostics info about the current state of the wifi card and why it is behaving badly?
Offline
For the last question,
sudo journalctl -b
collects and provides almost all of the logs relevant to any of this, including kernel/driver messages and information from your network management software, for the boot you're currently on. If you know the timeframe of the issue (e.g. to investigate what actually happened "yesterday") you could also look at the journal from a problematic timeframe with e.g. -b-1 for the boot prior to your current one or several time based filters: https://wiki.archlinux.org/title/System … ing_output
For a quick in-between check what output do you get from
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
post that wrapped between [ code ] [ /code ] tags without the spaces.
Last edited by V1del (2024-10-11 08:26:28)
Online
Thanks for the reply!
I have been looking at journal entries by NetworkManager and did a quick search for mentions of the card's driver iwlwifi, but couldn't spot any obvious errors (although I don't really know how to interpret all of the messages by NM). Is there anything else I should be looking for?
Here is the output you requested:
dbus-org.freedesktop.nm-dispatcher.service | system
display-manager.service | system
getty@tty1.service | getty.target.wants
lm_sensors.service | multi-user.target.wants
NetworkManager.service | multi-user.target.wants
NetworkManager-wait-online.service | network-online.target.wants
p11-kit-server.socket | sockets.target.wants
pipewire-pulse.socket | sockets.target.wants
pipewire-session-manager.service | user
pipewire.socket | sockets.target.wants
remote-fs.target | multi-user.target.wants
systemd-userdbd.socket | sockets.target.wants
wireplumber.service | pipewire.service.wants
Is this about the issue of having multiple conflicting network managers (e.g. both NetworkManager and dhcpcd)?
Offline
Yes, but that's not the problem in your case.
How many parallel windows intallations do you have?
Offline
There is one instance of Windows 11.
Edit: Based on your signature i guess i'll remark that I have disabled windows fast-start and hibernation completely.
Are there more places to get info about what the wifi driver and card are doing at the moment?
So far I have been looking at NetworkManager's nmcli and nmtui, journalctl and ip link to get an idea of what's happening.
But that doesn't seem to paint a full picture.
For example, right now I can control the "state" property shown by ip link without issue with "ip link set dev wlp3s0 up/down"
However, while in the broken state (which I sadly have been unable to reproduce today which is still puzzling me because yesterday it has been happening all day),
that command has been silently failing without producing visible change.
Last edited by lger0 (2024-10-11 16:02:38)
Offline
Edit: Based on your signature i guess i'll remark that I have disabled windows fast-start and hibernation completely.
Blast. Yes, was a trick question
rfkill, but the problem will more likely be that the driver or device doesn't respond and the relevant errors for that will be in the system journal.
You don't have to wait for the next incident, "sudo journalctl -b -δ", δ=1,2,3,… allows you to inspect journals of previous boots.
Offline