Congratulation to the Fedora team and all the developers building such great new developments in the recent 39 release. DNF5 is from my experience a BIG improvement on packaging speed and connecting to mirrors.
Currently, when my system goes into sleep I am unable to get connected to the wired or wifi network.
I have noticed there are a few people from past releases of fedora but thought perhaps there is a simple fix.
Is anyone able to offer any insights into this?
I have recently tried systemctl restart NetworkManager.service
Are you using Fedora 39 Workstation and Gnome? Here, I have a 39 Workstation configured with a web server so I donât want it to sleep, and another system where I use wake-on-lan when I need to an ssh session. If you want to prevent the system from sleeping, see: Talk: GNOME suspends after 15 minutes of user inactivity, even on AC power.
Are you trying to connect to the sleeping F38 workstation from another PC or is the problem that you donât have networking when the system wakes from sleep?
We need to determine whether this is a power management issue (network interface goes to
Power Management is an area where vendor support for linux is important. Whenever there are major changes to the kernel, as with a new Fedora release, vendors that donât provide open source drivers have to make changes. Please paste the output from running inxi -Fzxx in a terminal (as text using the </> button) so we can the make and model of the PC and network hardware and the network drivers used.
In the short term, you need a way to manually enable networking. I think others with similar network issue were able to use Gnome Settings to bring networking back.
Make sure you have fully updated Fedora and also the vendorâs âBIOSâ firmware so you arenât chasing a problem that is already solved and because it is easier for others to duplicate your configuration.
There is a very good chance that journalctl will have details needed to understand the problem, but deeply buried under the massive detail journalctl provides. You can use journalctl -b -g <string> using wifi, a kernel module name, or a kernel network device name (typically enp1s0 or wlo1) for <string>.
Edit: typo: -s replaced by -g in the journalctl example.
Both ethernet and wifi are ASUS variants of widely used chips, so you have to rely on ASUS firmware updates when you update the kernel. One workaround may be to use LTS kernels.
Wake from sleep issues often occur with newer kernels as linux power management is different from Windows and is often done differently by vendors.
Linux Hardware Data Base probes for [10ec:8178 lists couple alternative drivers. WiFi support in linux often lags behind the release schedule, so I find it helpful to have a USB WiFi dongle for use when onboard WiFi has a problem.
hmm thats a shame i may need an LTS kernel. I never had this issue with all other versions of Fedora.
I have heard some people say upgrading to Fedora 39 fixed this issue.
I use this machine as my daily workstation I guess for know Iâll just keep resetting it if the systemctl restart NetworkManager.service and see if that resolves it.
If not I shall upgrade to fedora 39 and see.
I know about installing other kernels but that seems a bit risky with the other hardware since I am not sure how the other peripherals and devices would respond to that. For me its Fedora or nothing/
Perhaps silverblue may be a better option as I can roll back to other kernel versions with ease
That may just mean the kernel interfaces used by your vendorâs firmware didnât change until 6.6.
The LTS kernel may help with older systems from vendors that donât update their firmware for the current kernels. You already have a 6.6 kernel. I would expect F38 with a 6.6 kernel to use the same firmware as F39, but I donât recall if F39 gets firmware updates that arenât in F38. On F39, the firmware packages I have are:
This indicates that you have locally network connection but you canât access the internet. You can see this also in the status for the NetworkManager.service, In my it says:
NetworkManager state is now CONNECTED_GLOBAL
resolvectl should reveal you the DNS addresses. They have to be set by connection. If empty try to verify if you can set a manual dns like 8.8.8.8 or 1.1.1.1 or whatever you prefer.
No, mine works fine. Just when I used bridged networking I had sometimes a lag to get network up and running after sleep.
You can also try to switch off and on the network with nmcli n off and with nmcli n on
I made me a helper-script to combine this commands like nmcli c show to combine them to one command.
Yesterday and today it has started to also drop out randomly (lose connection)
I am also using an alternative DNS resolver (nextdns), perhaps that may be affecting it I thought. I have disconnected that and will see if it resolves.
I wouldnt imagine it would disconnect the device though, but I could be wrongâŚ
isaiah@fedora-office:~$ journalctl -fk
Jan 16 10:51:08 fedora-office kernel: usblp0: removed
Jan 16 10:51:08 fedora-office kernel: usblp 1-6:1.0: usblp0: USB Bidirectional printer dev 5 if 0 alt 0 proto 2 vid 0x04F9 pid 0x028B
Jan 16 10:51:13 fedora-office kernel: gnome-shell[1345]: memfd_create() called without MFD_EXEC or MFD_NOEXEC_SEAL set
Jan 16 10:51:13 fedora-office kernel: rfkill: input handler disabled
Jan 16 10:51:14 fedora-office kernel: usb 1-3: 3:1: cannot get freq at ep 0x84
Jan 16 10:51:14 fedora-office kernel: usb 1-3: 3:1: cannot get freq at ep 0x84
Jan 16 10:51:16 fedora-office systemd-journald[642]: /var/log/journal/d8452f05a2e444ed8f4e55d858e8e489/user-1000.journal: Journal file uses a different sequence number ID, rotating.
Jan 16 10:51:17 fedora-office kernel: rfkill: input handler enabled
Jan 16 10:51:18 fedora-office kernel: rfkill: input handler disabled
Jan 16 10:51:18 fedora-office kernel: logitech-hidpp-device 0003:046D:407B.0007: HID++ 4.5 device connected.
That should not happen. There have been changes to linux power management, and it is quite possible that hardware vendors havenât made required firmware updates. Some network modules have options to maintain network connectivity in low-power modes. modinfo e1000e mentions âSmartPowerDownâ. From README and manual page from Intel Linux Driver e1000e v3.0.4.1 :
SmartPowerDownEnable
Valid Range: 0-1
Default Value: 0 (disabled)
Allows Phy to turn off in lower power states. The user can turn off this parameter in supported chipsets.
ah I see. So can I customise the settings to allow this to happen. I have another network card I can try but this is a wifi network card, the âwiredâ connection is going straight into the mother board (ASUS), so it may be my firmware is not yet up to date yet?
