[Bug Report] Network dies very shortly after first boot when computer has been turned off for a few hours

[UnconnectedBedna]

Describe the bug:

The network dies after 1-4 minutes every time the computer is started after a longer shutdown period IF systemd hook is present in mkinticpio. Works fine if I change the hook to udev.
After a reboot the network works normally again.
Relevant discussion on arch forum: https://bbs.archlinux.org/viewtopic.php?pid=2272632

Include the following information:

• OpenSnitch version: 1.7.2
• OS: ArchLinux
• Window Manager: KDE
• Kernel version: Linux bednaArch 6.17.8-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 14 Nov 2025 06:54:20 +0000 x86_64 GNU/Linux

To Reproduce:

1. Have opensnitd.service enabled
2. Start computer after being turned off for a few hours
3. Experience network no longer working after a very short time

Post error logs:

• Run opensnitchd -check-requirements to see if your kernel is compatible.

        Checking system requirements for kernel version 6.17.8-arch1-1
------------------------------------------------------------------------------

        Checking => CONFIG_KPROBES=y
        Checking => CONFIG_KPROBES_ON_FTRACE=y
        Checking => CONFIG_HAVE_KPROBES=y
        Checking => CONFIG_HAVE_KPROBES_ON_FTRACE=y
        Checking => CONFIG_KPROBE_EVENTS=y

        * kprobes        ✔

        Checking => CONFIG_UPROBES=y
        Checking => CONFIG_UPROBE_EVENTS=y

        * uprobes        ✔

        Checking => CONFIG_FTRACE=y

        * ftrace         ✔

        Checking => CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
        Checking => CONFIG_FTRACE_SYSCALLS=y

        * syscalls       ✔

        Checking => CONFIG_NETFILTER_NETLINK_QUEUE=[my]
        Checking => CONFIG_NFT_QUEUE=[my]
        Checking => CONFIG_NETFILTER_XT_TARGET_NFQUEUE=[my]

        * nfqueue        ✔

        Checking => CONFIG_NETFILTER_NETLINK=[my]
        Checking => CONFIG_NETFILTER_NETLINK_QUEUE=[my]
        Checking => CONFIG_NETFILTER_NETLINK_ACCT=[my]
        Checking => CONFIG_PROC_EVENTS=[my]

        * netlink        ✔

        Checking => CONFIG_INET_DIAG=[my]
        Checking => CONFIG_INET_TCP_DIAG=[my]
        Checking => CONFIG_INET_UDP_DIAG=[my]
        Checking => CONFIG_INET_DIAG_DESTROY=[my]

        * net diagnostics        ✔

• Post last 15 lines of the log file /var/log/opensnitchd.log

There are only two lines in the log from the failing boot, then I rebooted and the last two are from the new boot:

[2025-11-20 17:52:38]  IMP  Start writing logs to /var/log/opensnitchd.log

[2025-11-20 18:00:23]  IMP  Got signal: terminated
[2025-11-20 18:01:03]  IMP  Start writing logs to /var/log/opensnitchd.log
[2025-11-20 18:03:11]  IMP  UI connected, dispathing queued alerts: 0

From journalctl grep opensnitch from boot dropping network:

Nov 20 18:52:38 bednaArch opensnitchd[910]: [2025-11-20 17:52:38]  IMP  Starting opensnitch-daemon v1.7.2
Nov 20 18:52:38 bednaArch opensnitchd[910]: [2025-11-20 17:52:38]  WAR  Error loading network aliases: open /etc/opensnitchd/network_aliases.json: no such file or directory
Nov 20 18:52:38 bednaArch opensnitchd[910]: [2025-11-20 17:52:38]  INF  Loading network aliases from /etc/opensnitchd/network_aliases.json ...
Nov 20 18:52:38 bednaArch opensnitchd[910]: [2025-11-20 17:52:38]  INF  Loading configuration file /etc/opensnitchd/default-config.json ...
Nov 20 18:52:38 bednaArch opensnitchd[910]: [2025-11-20 17:52:38]  INF  Loading rules from /etc/opensnitchd/rules/ ...
Nov 20 18:52:39 bednaArch opensnitchd[910]: found /usr/lib/libc.so.6
Nov 20 18:55:24 bednaArch drkonqi-coredump-processor[1762]: "/usr/bin/python3.13" 1764 "/var/lib/systemd/coredump/core.opensnitch-ui.1000.e73dd29210fb408fa6dffd52e72ded47.1764.1740713441000000.zst"
Nov 20 18:55:24 bednaArch drkonqi-coredump-processor[1762]: "/usr/bin/python3.13" 1851 "/var/lib/systemd/coredump/core.opensnitch-ui.1000.0d4dc1b81a504726abd42cf03d62d9ab.1851.1740748382000000.zst"
Nov 20 19:00:23 bednaArch opensnitchd[910]: Timed out while sending packet to queue channel 3525605494
Nov 20 19:00:23 bednaArch opensnitchd[910]: Timed out while sending packet to queue channel 3525605494
Nov 20 19:00:25 bednaArch systemd[1]: opensnitchd.service: Deactivated successfully.
Nov 20 19:00:25 bednaArch systemd[1]: opensnitchd.service: Consumed 2.276s CPU time, 111.3M memory peak.

Full journalctl log from boot dropping network: bootlog4.log

Additional context:

The errors displayed in journalctl seems to happens every boot, not just the failing ones.
/etc/opensnitchd/network_aliases.json does not exist on my system.
Installed opensnitch via arch stable repos.

If I disable opensnitd.service the issue goes away, hence pointing to opensnitch being related to this some way.

Edit
Additional information: Having other firewalls active, for example plasma firewall (with opensnitchd.service masked) also seems to cause this issue.

[gustavo-iniguez-goya]

hi @UnconnectedBedna ,

Thanks for this detailed report! I'll take a look at this issue and try to reproduce it.

What's the DefaultAction option of /etc/opensnitchd/default-config.json? and is there any error in /var/log/opensnitchd.log? It'd be interesting to see the logs in DEBUG level (truncate the log -> power off the PC -> power on -> backup the log with he issue reproduced).

/etc/opensnitchd/network_aliases.json does not exist on my system.

That file should be installed by the aur package, it's available here: https://github.com/evilsocket/opensnitch/blob/master/daemon/network_aliases.json

[UnconnectedBedna]

The default action in /etc/opensnitchd/default-config.json is deny.

{
    "Server": {
        "Address": "unix:///run/user/1000/opensnitch//osui.sock",
        "Authentication": {
            "Type": "simple",
            "TLSOptions": {
                "CACert": "",
                "ServerCert": "",
                "ClientCert": "",
                "ClientKey": "",
                "SkipVerify": false,
                "ClientAuthType": "no-client-cert"
            }
        },
        "LogFile": "/var/log/opensnitchd.log"
    },
    "DefaultAction": "deny",
    "DefaultDuration": "once",
    "InterceptUnknown": false,
    "ProcMonitorMethod": "ebpf",
    "LogLevel": 2,
    "LogUTC": true,
    "LogMicro": false,
    "Firewall": "nftables",
    "FwOptions": {
        "ConfigPath": "/etc/opensnitchd/system-fw.json",
        "MonitorInterval": "15s",
        "QueueBypass": true
    },
    "Rules": {
        "Path": "/etc/opensnitchd/rules/",
        "EnableChecksums": false
    },
    "Ebpf": {
        "EventsWorkers": 8,
        "QueueEventsSize": 0
    },
    "Stats": {
        "MaxEvents": 250,
        "MaxStats": 25,
        "Workers": 6
    },
    "Internal": {
        "GCPercent": 100,
        "FlushConnsOnStart": true
    }

There are no errors in /var/log/opensnitchd.log (when set to important logging).
If I monitor events after the network has died, I can see requests going through as allowed.

I also want to point out so it is clear: When booting (after the system has been turned off for a few hours), the network works fine, it dies after a few minutes forcing me to reboot. Using nmcli down/up does not work, only a reboot solves the issue. sudo systemctl soft-reboot does NOT solve the issue, only a "hard" reboot does, and after rebooting the network works without issues.
Shutting down the system for a shorter period and then starting it up again does NOT cause this issue.

I'll activate debug logging and provide the log when network drops.
I can only make one test per day since the computer needs to be shut off for a few hours for it to happen, and today I reconfirmed that having opensnitch and plasma firewall disabled removes the issue (and it does).
Moving forward I will only focus on opensnitch and keep plasma firewall disabled, because plasma firewall (in extension UFW) was just an extra layer, opensnitch firewall should do the same thing and it is easier to nail down the problem if I only focus on one of the firewalls.

That file should be installed by the aur package, it's available here: https://github.com/evilsocket/opensnitch/blob/master/daemon/network_aliases.json

I saw the file on the github repo, but pacman -F /etc/opensnitchd/network_aliases.json does not return anything.
Are you saying I should use the AUR package over using the package in the stable arch repos?
Or can I just copy the file "as is" from github and use that? (and why is it not included in the arch repos?)

Name            : opensnitch
Version         : 1.7.2-2
Description     : A GNU/Linux application firewall
Architecture    : x86_64
URL             : https://github.com/evilsocket/opensnitch
Licenses        : GPL-3.0-or-later
Groups          : None
Provides        : None
Depends On      : glibc  hicolor-icon-theme  libnetfilter_queue  libnfnetlink  python  python-grpcio  python-protobuf  python-slugify  python-pyqt5  python-pyinotify  python-notify2  python-packaging
Optional Deps   : logrotate: logfile rotation
                  python-qt-material: extra ui themes
                  python-pyasn: display network name of IP
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : opensnitch-ebpf-module
Installed Size  : 20,44 MiB
Packager        : George Rawlinson <[email protected]>
Build Date      : 2025-11-09T07:52:27 CET
Install Date    : 2025-11-09T20:34:27 CET
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature
Backup Files    : /etc/logrotate.d/opensnitch [unmodified]
                  /etc/opensnitchd/default-config.json [modified]
                  /etc/opensnitchd/system-fw.json [modified]
Extended Data   : pkgtype=pkg

Might be relevant:
I have used opensnitch since I had to use the AUR to enable the ebpf module but have since removed the AUR epbf module since it is now baked in the arch repos. Maybe this is causing some kind of issue?

Again, this only happens if I have systemd in mkinitcpio hooks. If I remove systemd and use udev instead, this issue does not happen.
I will update with information when the issue is happening with logging set to debug.

[gustavo-iniguez-goya]

The default action in /etc/opensnitchd/default-config.json is deny.

Try changing it to allow and see if the issue persists.

Or can I just copy the file "as is" from github and use that? (and why is it not included in the arch repos?)

Yeah, copy the file from our repo in order to get rid of the error. The AUR package mantainer should include it in the package.

Some notes after reading the arch forum post:

• You had an issue with a USB wifi card.
• This issue occurs with and without OpenSnitch being enabled.
• This issue also occurs with OpenSnitch disabled and firewalld disabled.
• mkinitpcio hooks that works fine: HOOKS=(base udev autodetect microcode modconf keyboard keymap block filesystems)
• mkinitpcio hooks that doesn't work: HOOKS=(base systemd autodetect microcode modconf keyboard keymap block filesystems)
• When the network stops working nothing works, not a ping, not dns, nothing.
  • but the IPs respond with icmp-unreachable (From bednaArch (192.168.99.10) icmp_seq=1 Destination Host Unreachable)
• Looking at the logs, you have dozens of crashes of many processes of the system (firefox, KDE plasma, brave, steam, spotify, xwayland, sddm authenticator, ...) Something is really bad with your hardware or the Arch installation.

I've configured the HOOKS with systemd and udev, and in both cases the network works as expected.

Moving forward I will only focus on opensnitch and keep plasma firewall disabled, because plasma firewall (in extension UFW) was just an extra layer, opensnitch firewall should do the same thing and it is easier to nail down the problem if I only focus on one of the firewalls.

Perfect. In fact, I'd suggest you to disable opensnitch completely: systemctl disable opensnitchd ; systemctl stop opensnitch.
I even suggest you to rename the binary, to be super sure that it doesn't start: mv /usr/bin/opensnitchd /usr/bin/opensnitchd.bak.
And verify that you don't have netfilter rules added: nft list ruleset. Delete them with nft flush ruleset.

Then, without opensnitch running and no netfilter rules, verify if the network dies or not.

Actually, I'd go even further:

• do not even start KDE, not even the X. Disable sddm so it doesn't start on boot up.
• when the systems boots up, log in the terminal, and monitor network connectivity.
• be sure that you don't have netfilter rules: nft flush ruleset.
• if the network doesn't die after a few days (sometimes your network dies after ~6h, so you should be really sure that it works), then start sddm and more services one by one.

[UnconnectedBedna]

A little misunderstanding I think. The issue does NOT happen with opensnitch disabled.

• mkinitcpio hook that works in combination with opensnitch: HOOKS=(base udev autodetect microcode modconf keyboard keymap block filesystems)
• mkinitcpio hook that does NOT work in combination with opensnitch: HOOKS=(base systemd autodetect microcode modconf keyboard keymap sd-vconsole block filesystems)

The crashes are old (if you are talking about the drkonqi logs), and the service should be disabled, I just don't know how to get rid of them so they spit those out every boot.
There are applications mentioned in there that has not been installed for months. I just didn't know the old logs were spit out into the boot log, I just found out when starting to look deeper into this issue, I have only looked for warnings and above when looking at my journalctl before.
Those errors are probably from when plasma 6 was released, it WAS buggy and that was when I disabled drkonqi because I became annoyed by constantly being interrupted with an error report rather than the graphical interface just restarting immediately.
I can't say I have any issues running KDE any longer.

The wifi was an old issue no longer present. The only thing wonky about my wifi is that I can't disable it in uefi, it's still available even if I do.
In fact, when lan drops with the issue I describe in this report, I can activate wifi and that works perfectly. So all of this only involves my lan.
I only mentioned it in the beginning on the arch post because it was also network related and wanted to be clear up front instead of it turning out to be related later when looking for solutions.

The issue at hand is triggered by having two things:

• A firewall
• systemd mkinitcpio hook

If I remove one of the points above, my network works flawlessly.
So reason dictates it is something in either firewall or systemd.

I have tried by both masking and just disabling opensnitcd.service. And in both situations there is no problem with the network at boot so masking or renaming binary is not necessary, disabling it is enough.

Also noteworthy, after network drops:

• Why is not a soft-reboot enough?
• Why does the network not ever fail again after a reboot?
• Why is it not working with systemd hook but working with udev? (in combination with opensnithd.service enabled)

Tomorrow I will reboot with opensnitch enabled and logging with debug level and provide the output here, maybe that will tell me something.

I will not be able to let the system run for days without a desktop environment. I am using this computer as my daily driver and need it. The "sometimes it drops after 6hr" was ONCE, it has never happened again.

[UnconnectedBedna]

Here is a debug log on a boot where network failed after a few minutes.

opensnitch.log

Are you interested in finding out why this happens?
Otherwise I will just use the workaround, ie not having systemd in my mkinitcpio hooks and move on.
I only do this because everything points to something involving firewall and systemd and thought developers wanted to know, even if it is "just" some bug with specific hardware in certain configurations.
Let me know if you want to, otherwise you can close this issue with wontfix.

But I would really appreciate if you responded to one question.
You keep talking about the AUR when opensnitch exists in stable arch repos. Are you recommending using the AUR over the stable arch repos for opensnitch?

Edit
Adding network_aliases.conf to my system renders opensnitch useless, ie, opensnitch can no longer control the traffic and nothing shows up in events. So that is probably why the arch repo has that file removed.

[gustavo-iniguez-goya]

thank you @UnconnectedBedna ,

Are you interested in finding out why this happens?

Yes, asbolutely! Maybe I won't respond instantly, but I'll try to investigate this issue.

Reviewing the logs shows that around 22:24:51 the system tries to query your internal DNS as usual (...xx.20), but it doesn't seem to work, and after more or less 1 minute there're no new domains resolved.

From the logs I cannot tell why it fails, but I can suggest one thing: try using only 1.1.1.1 or 8.8.8.8 as the DNS nameserver, and see if it makes any difference.

There's also a "network event" at 22:24:31: local addr added: {LinkAddress:{IP:xxx.xxx.xx.10 Mask:ffffff00} like a connection or interface reconfiguration. A bit suspicious actually given the timing.

On the other hand: change the configuration option ProcMonitorMethod to proc and try to reproduce it.

In any case, it's not very clear to me that we're the ones at fault here, that's why we need to reproduce this issue using the absolute basics: no extra background services running, no backup services, no nfs services, no vmwares, no VM NATs, no steam, no deno, etc, etc.

So this is what I'd do:

• Change the DNS nameserver to 1.1.1.1 o 8.8.8.8
• Stop background services: backups, nfs mounts, vm networks, whatever, etc, ...
• When the network stops working:
  • write down the time when it stops working, to know exactly the moment it started to fail.
  • ping your internal DNS IP to see if it's alive,
  • list the rules with nft list ruleset and verify that this rule exists udp sport 53 queue to 20.
  • flush out the rules: nft flush ruleset and verify if the ping to IPs and DNS works.
  • stop opensnitch and verify if the network works (pings, DNS, etc).

mkinitcpio hook that does NOT work in combination with opensnitch: HOOKS=(base systemd autodetect microcode modconf keyboard keymap sd-vconsole block filesystems)
Why is it not working with systemd hook but working with udev? (in combination with opensnithd.service enabled)

That's the default HOOKS list, except fsck and kms. I've tested it and the network works fine and doesn't die with either udev or systemd. Given that your HOOKS= option is almost identical to the default one, I'd expect other users to experience this issue as well, and so far no one has reported a similar issue.

By the way, did you try the default HOOKS list? with fsck + kms, just in case ...

The crashes are old (if you are talking about the drkonqi logs), and the service should be disabled, I just don't know how to get rid of them so they spit those out every boot.

You have plenty of coredumps under /var/lib/systemd/coredump/ (since the filenames don't have a timestamp, I don't know if they're new or not).

If you don't need them just delete them as root, and if you're not going to analyze them you can disable systemd-coredump: systemctl disable systemd-coredump.

[UnconnectedBedna]

It is advised against using fsck with btrfs IIRC, so I don't want to use that mkinitcpio hook.
I removed the logs in /var/lib/systemd/coredump/, but that was not enough, I had to journalctl --rotate --vacuum-time=1s --unit=systemd-coredump to actually remove them from the systemd journal logs. (thank you for almost 4GiB of extra space xD)
Side note: Disabling systemd-coredump is done by editing an override file according to arch wiki

Things I did before shutting down the computer:

• Disabled urbackupclient
• Disabled NFS (disabled the systemd.automount unit so it does not get mounted)
• Removed my pihole (192.168.99.20) as DNS and made 1.1.1.1 the only DNS server
• Changed Process monitor method from ebpf to proc
• Changed logging method from important to debug
• Shut down computer

Startup the next day:
I had an emergency and had to run to the toilet after powering on the computer but managed to ping devices on my network directly after login and that worked. So I don't have an exact time when it stopped working, but when returning a few minutes later, the network was no longer functioning and pinging 192.168.99.20 no longer worked.
I think the second non responsive ping is:

�[2m[2025-11-25 13:06:59]�[0m �[2m�[30m�[100m DBG �[0m [procmon exec event] 187981316827, pid:2281 tgid:2281 ping, /usr/bin/ping -> /usr/bin/zsh

because it looks like I opened obsidian for my notes directly after that (electron used with obsidian).

Here is the output of nft list ruleset:

table inet filter {  
       chain forward {  
               type filter hook forward priority filter; policy accept;  
       }  
  
       chain output {  
               type filter hook output priority filter; policy accept;  
       }  
  
       chain input {  
               type filter hook input priority filter; policy drop;  
               udp sport 53 queue flags bypass to 0  
               ip saddr 192.168.99.152 accept  
               ip saddr 192.168.99.100 accept  
               ip saddr 192.168.99.60 accept  
               ip saddr 192.168.99.30 accept  
               ip saddr 192.168.99.20 accept  
               ip saddr 192.168.99.16-192.168.99.17 accept  
               iifname "lo" accept  
               ct state established,related accept  
       }  
}  
table inet nat {  
       chain filter-prerouting {  
               type filter hook prerouting priority filter; policy accept;  
       }  
  
       chain prerouting {  
               type nat hook prerouting priority dstnat; policy accept;  
       }  
  
       chain postrouting {  
               type nat hook postrouting priority srcnat; policy accept;  
       }  
  
       chain input {  
               type nat hook input priority srcnat; policy accept;  
       }  
  
       chain output {  
               type nat hook output priority 100; policy accept;  
       }  
}  
table inet mangle {  
       chain prerouting {  
               type filter hook prerouting priority mangle; policy accept;  
       }  
  
       chain postrouting {  
               type filter hook postrouting priority mangle; policy accept;  
       }  
  
       chain output {  
               type filter hook output priority mangle; policy accept;  
               icmp type { echo-reply, destination-unreachable, echo-request } accept  
               meta l4proto != tcp ct state related,new queue flags bypass to 0  
               tcp flags & (fin | syn | rst | ack) == syn queue flags bypass to 0  
       }  
  
       chain forward {  
               type filter hook forward priority mangle; policy accept;  
       }  
}

list the rules with nft list ruleset and verify that this rule exists udp sport 53 queue to 20.

Mine is udp sport 53 queue flags bypass to 0

I flushed the rules with nft flush ruleset and confirmed they were empty with nft list ruleset, stopped opensnitchd.service and tried to ping again but same error, no response.
I then rebooted. After reboot I only changed logging in opensnitch from debug to important.

Here is the log. It starts with the boot and includes the reboot and when I switched back logging from debug to important in opensnitch.
opensnitchd.log

I have since restored the system as it was before, ebpf, my nfs mount and backup software running again so if you want me to revert any settings before further testing please let me know.

Thank you for taking time trying to figure this out. ❤️

Edit
I just realized, I changed back to using HOOKS=(base udev autodetect microcode keyboard keymap modconf block filesystems) before first reboot of the day yesterday when the network failed and forgot about it. So now this issue is present both with and without systemd hook. That was NOT the case before, so now I no longer have a workaround (except for disabling opensnitch that is). :(

[gustavo-iniguez-goya]

thank you! some notes:

0. using proc discards one issue we had some months ago when using ebpf, related to network interface events (fixed in v1.7.2 anyway [Bug Report] OpenSnitch breaks DNS in Fedora 42 (eBPF incompatible with Kernel 6.14) #1343, and it only affected systemd-resolved 257 + kernels 6.14.x, but I wanted to be sure).
1. where do you configure the filter-input firewall rules for the 192.168.99.x IPs, /etc/nftables.conf?
   1. if that's the case disable it, or comment the rules. Leave only OpenSnitch rules, and all chains policies set to ACCEPT.

You should only have this configuration after rebooting with OpenSnitch rules:

table inet mangle {    
       chain input {  
               type filter hook input priority filter; policy accept;  
               udp sport 53 queue flags bypass to 0  
       }  
       chain output {  
               type filter hook output priority mangle; policy accept;  
               icmp type { echo-reply, destination-unreachable, echo-request } accept  
               meta l4proto != tcp ct state related,new queue flags bypass to 0  
               tcp flags & (fin | syn | rst | ack) == syn queue flags bypass to 0  
       }  
}

Another thing to try if disabling the additional rules doesn't work:

create a new rules directory: mkdir /etc/opensnitchd/rules2
change the path of the rules in the file /etc/opensnitchd/default-config.json:

(...)
    "Rules": {
        "Path": "/etc/opensnitchd/rules2"
    },

It'll ask you to allow connections again. Just allow everything, and see if the network doesn't die.

[gustavo-iniguez-goya]

hey @UnconnectedBedna , any update on this issue?

[UnconnectedBedna]

Not really.
Nothing I do makes sense, no errors in logs anywhere and using ifconfig down|up works sporadically, ie sometimes it's enough, but more often I have to redo it 2-3 times while a reboot always works.
The only thing I can add is that if I for example load a webpage in firefox and network "drops" firefox continues to "load", ie no error message there either. So if I do an down/up with ifconfig, the webpage continues to load correctly after the "up", witch indicates to me that the requests are "hanging in the air" somewhere until network is available again, hence no errors in logs...
But again, I have no clue what I am dealing with here and is completely out of my depth... :-(

I was thinking I might be able to create a live install with a firewall installed so I could make 100% sure there is nothing on my installation that creates this behavior. Using a live env like f.ex cachy makes little sense since the problem is with a firewall installed @ boot.

There is also the recommendation to start removing features with ethtool, but to be honest, the air has gone out of me and I've gotten used to rebooting once after long shutdown.

I did get a response from gigabyte about not being able to turn off wifii on the mobo one day after a new bios was released informing me to "update the firmware" (witch I had already done) but no changes in behavior and I still can't turn off wifi in uefi.
I also got confirmation that if I disable wifi in uefi, my enp interface changes from enp14 to enp13, even though wifi is still not disabled in hardware according to rfkill list. This is in my mind with very limited knowledge a pointer to it being really low level coding errors somewhere, or a hardware error, ie my hardware is starting to break down, but it is still very strange to me that there are absolutely no errors in any logs.

So to summarize, I have no idea what to do other than starting disabling features with ethtool. Do you think that would actually lead somewhere?

Edit.
I REALLY appreciate you following up and checking in on progress! Let's see if "Santa" brings a little donation to you and the project this year... :)

[gustavo-iniguez-goya]

oof, honestly I'd not touch ethtool. Before doing that, as I commented in another post, I'd try to reproduce the issue with a minimal system: every single firewall and non-essential service disabled. And I'd switch off any device in the network.

Just your computer, the router and nothing else. Start using common DNS servers (1.1.1.1, 8.8.8.8), static IP, and see if the network doesn't die in days or weeks, or months! xd

If you're super sure that the computer works, then enable opensnitch without rules, allowing everyhing by default, and keep non-essential services stopped. And see what happens.

In any case, using the system from a live iso would be a really good test.

[UnconnectedBedna]

I did all of above except "then enable opensnitch without rules, allowing everything by default, and keep non-essential services stopped", I guess I can try that too.
Is removing all rules enough (or just disabling them) or is a new clean installation a requirement for this? And do you mean to also set it to incoming=allow all, outgoing=allow all?
Changing dns to 1.1.1.1, disabling all services relying on network and flushing ruleset was done in a few posts above this and did not change anything.

However I did not try to boot the first time in the morning directly to a live environment. But since my installation works without having a firewall active, I don't really see why booting a live usb, also without a firewall would prove anything different. But then again, correlation vs causation and I am in deep water not knowing exactly how things work...
So I'll do it to make absolutely sure the issue does not happen on a live env.

I just checked the arch post I made and there is a response from a user who has this issue without any firewall so it might not be connected to firewall after all. Correlation vs causation...

[ryan-steed-usa]

My intention isn't to hijack your conversation. I'm also unsure whether this type of troubleshooting is appropriate here (since it seems like OpenSnitch isn't the problem). Forgive me and disregard if necessary.

To summarize:

• Wired Realtek RTL8125 network stops responding after an unpredictable duration when any netfilter based firewall is enabled (not limited to OpenSnitch).
• Use of systemd or udev mkinitcpio hook makes no difference nor does kernel version.
• Bouncing the interface with NetworkManager doesn't restore connectivity, neither does flushing the rules, only a full poweroff/reboot succeeds.
• Mainboard is a Gigabyte X670 AORUS ELITE AX with BIOS version F36 dated 07/31/2025.

Questions:

• Does the problem occur using only a wireless connection? Do you frequently keep both connections active?
• Have you tried resetting the adapter using ifconfig? sudo ifconfig enp13s0 down and sudo ifconfig enp13s0 up (I've encountered cases where these NetworkManager operations fail).
• Do pings to localhost or the interface IP fail?
• Have you inspected packets using Wireshark or tcpdump during the problem?
• You mentioned using ethtool, was that to test toggling interface options like offload/checksum? If not, might be worth a try.
• Power management troubleshooting (BIOS, kernel, daemon, etc.)?
• Have you tested using the propriety r8125 driver with the r8169 module blacklisted?
• BIOS update? It looks like your board might have a new update available: F37e dated Sep 18, 2025 with note "Enhance system stability and performance", could be worth testing.
• Are you using memory with the XMP/EXPO profile enabled? Does it use an OC (overclock) mode exceeding 5200 MT/s (the supported chipset maximum)? It might be worthwhile to down-clock the RAM frequency for testing.
• Can you replicate the problem with a live boot environment of some type (with netfilter enabled)?
• You've performed basic hardware stability testing like memtest86/mprime?

We've similar configurations (including Archlinux + KDE + OpenSnitch) but I don't encounter any of these problems. Although, I'm on the B650 platform with RTL8125BG, not X670. My 192G memory kit cannot run stable at its SPD XMP profile frequency with my 9950X 🤷🏽‍♂️.

[UnconnectedBedna]

My intention isn't to hijack your conversation. I'm also unsure whether this type of troubleshooting is appropriate here (since it seems like OpenSnitch isn't the problem).

Well, depends I guess. If it is a problem with any netfilter firewall, it could be in opensnitch interest to find out WHY, and IF related report it upstream. Me reporting "my network dies" upstream would never lead anywhere compared to a report after a full fledged investigation like this.

Does the problem occur using only a wireless connection? Do you frequently keep both connections active?

Unknown, test required. I do not use wifi very often, but id DOES work when lan drops. I always have wifi soft disabled and activate it on those rare occasions I need it.
I will need to do some tests to see if only using wifi with lan disabled in the uefi could potentially reproduce this issue.

Have you tried resetting the adapter using ifconfig? sudo ifconfig enp13s0 down and sudo ifconfig enp13s0 up (I've encountered cases where these NetworkManager operations fail).

I have now, this boot. And this fixes the network without a reboot. Typing this +45mins after ifconfig down/up on a boot where network dropped.
Edit. And today I had to bring it down/up 3 times for network to keep functioning. It worked immediately after down/up, but within a few seconds it stopped and I had to redo it again three times. End edit.

Do pings to localhost or the interface IP fail?

God damn it, I read this on my phone before starting the computer and still forgot to try it. I will try tomorrow.
Edit. Yes, 127.0.0.1 and 192.168.99.10 is reachable even when nothing outside the computer is. End edit.

Have you inspected packets using Wireshark or tcpdump during the problem?

I have not, and I frankly do not posses the knowledge how to do that. :(

You mentioned using ethtool, was that to test toggling interface options like offload/checksum? If not, might be worth a try.

I only used ethtool once in the OP on arch forums. And that was to try to provide information about the hardware.
I do not posses the knowledge to know what to try.

Power management troubleshooting (BIOS, kernel, daemon, etc.)?

Again, lack of knowledge from my side how to do that. :(

Have you tested using the propriety r8125 driver with the r8169 module blacklisted?

I did not even know there was a proprietary driver available...

BIOS update? It looks like your board might have a new update available: F37e dated Sep 18, 2025 with note "Enhance system stability and performance", could be worth testing.

That is a massive nono from my side. I have used their beta firmware in the past, and ran in to a bug where the fans ran at 0% when they should run at full speed and vice versa. I reverted back to stable firmware and immediately reported this to gigabyte. Took one week for them to even remove the broken firmware on their webpage, and another 6 weeks before they even responded, and the response came the day after they released a new stable firmware. And the response was "update your firmware"...
So no, I will NEVER run gigabyte alfa/beta firmware again!

Are you using memory with the XMP/EXPO profile enabled? Does it use an OC (overclock) mode exceeding 5200 MT/s (the supported chipset maximum)? It might be worthwhile to down-clock the RAM frequency for testing.

I do, and I have not tried to disable it, but will put that on the list of things to try.

Can you replicate the problem with a live boot environment of some type (with netfilter enabled)?

That has crossed my mind. But I do not know how to configure a live environment to have a netfilter firewall active so I dropped the idea of trying.

You've performed basic hardware stability testing like memtest86/mprime?

I have not, but if the opportunity comes up (me away not needing to use the computer for example) I will run memtest for a few hours.

We've similar configurations (including Archlinux + KDE + OpenSnitch) but I don't encounter any of these problems. Although, I'm on the B650 platform with RTL8125BG, not X670. My 192G memory kit cannot run stable at its SPD XMP profile frequency with my 9950X 🤷🏽‍♂️.

I might be able to give you an idea here. Try with only using 2 memory modules. I have seen using all four banks can cause issues with high speeds. But then again, that would only be for peace of mind since I assume you want more memory rather than a small amount of fast memory.

I do realize this can absolutely be hardware level issues and completely understand if interest in trying to find the reason is outside the scope of opensnitch.
But on a personal level, in my very biased opinion , I appreciate this communication. 😸

[ryan-steed-usa]

Unknown, test required. I do not use wifi very often, but id DOES work when lan drops. I always have wifi soft disabled and activate it on those rare occasions I need it. I will need to do some tests to see if only using wifi with lan disabled in the uefi could potentially reproduce this issue.

This could indicate that the problem is isolated to the wired adapter.

I have now, this boot. And this fixes the network without a reboot. Typing this +45mins after ifconfig down/up on a boot where network dropped. Edit. And today I had to bring it down/up 3 times for network to keep functioning. It worked immediately after down/up, but within a few seconds it stopped and I had to redo it again three times. End edit.

Does the down/up restore full capability, including firewall rules? Until the problem returns? Requiring that you bounce the interface again? Or is reboot required?

God damn it, I read this on my phone before starting the computer and still forgot to try it. I will try tomorrow. Edit. Yes, 127.0.0.1 and 192.168.99.10 is reachable even when nothing outside the computer is. End edit.

Interesting, maybe using a utility like gnu-netcat might help to determine if EBPF and OpenSnitch are still functioning internally. I'd suggest attempting to access a closed port just to confirm the expected result. Presuming that you don't use tftp and that your rules don't already permit the traffic, a command like this should result in the corresponding output:

Allow the connection prompt

$ nc -vz 192.168.99.10
internal.host.name [192.168.99.10] 69 (tftp): Connection refused

If denied, it should timeout which takes significantly longer

$ nc -vz 192.168.99.10
internal.host.name [192.168.99.10] 69 (tftp): Connection timed out

I only used ethtool once in the OP on arch forums. And that was to try to provide information about the hardware. I do not posses the knowledge to know what to try.

This is a perfect opportunity to learn! In summary, some of the network processing can be "offloaded" away from the main CPU and onto the dedicated interface hardware. The ethtool utility can selectively enable/disable offloading features. To view features, run sudo ethtool --show-features enp14s0 but the output includes options which cannot be modified (fixed), so you might filter them: sudo ethtool --show-features enp14s0 | grep -v '\[fixed\]'

The resulting list contains options that can be toggled with a command like: sudo ethtool --features enp14s0 tcp-segmentation-offload off. These options are reset on reboot. Make sure to read the man page. I'd suggest disabling them all, if that helps, re-enable until you find a culprit.

I did not even know there was a proprietary driver available...

Yes, Realtek provides linux drivers, but it requires a manual install process and for r8125 they support up to the 6.12 kernel only so you'd need to use the LTS kernel. I can't attest to it's safety, but there is also an AUR package. You'll need to blacklist the r8169 module that is bundled with the kernel if you decide to test either option.

That is a massive nono from my side. I have used their beta firmware in the past, and ran in to a bug where the fans ran at 0% when they should run at full speed and vice versa.**

Perhaps it was the right decision! It looks like they've removed F37e from the website...

That has crossed my mind. But I do not know how to configure a live environment to have a netfilter firewall active so I dropped the idea of trying.

The CachyOS project might be a realistic option, they offer a full live boot GUI installer and is based on Archlinux. You might be able to install OpenSnitch directly into the live environment.

---

New question: do you have the linux-firmware package (or at least linux-firmware-realtek) installed? If not, you might want to install it. You may also want the amd-ucode package as well.

---

@gustavo-iniguez-goya would you prefer that this discussion proceed elsewhere?

[UnconnectedBedna]

@gustavo-iniguez-goya would you prefer that this discussion proceed elsewhere?

+1 to this question (before I continue to bombard this issue with further information)

[gustavo-iniguez-goya]

Yes, let's move the discussion to the https://github.com/evilsocket/opensnitch/discussions/categories/general Discussion forum for now.