[SOLVED] Network lock protection lost when eddie-ui crashes

[zebulon 1]

Hi,

I use Eddie on Archlinux, with KDE Plasma on Wayland.
I just noticed that network lock works fine in case there is a disconnection to the VPN mirror. However, if eddie-ui crashes for some reason (e.g. plasmashell on Wayland crashes, bringing down some other graphical apps with it), then I lose the network lock protection and the Internet is accessible, unencrypted. Am I doing something wrong? Because this is extremely dangerous. Maybe I do not properly use it and would like some advice. Thanks a lot in advance.

[Tech Jedi Alex 1518]

 I'd need to cause a crash first. How do you do it?  

[zebulon 1]

Wayland with Plasma+nvidia is a known combination to make plasmashell crash when simulaneously using some plasmoids (notably the System Monitor).
But if you want to force it, use 

$ pkill eddie

in console and it will crash it for you.

EDIT: instead of pkill use :

$ sudo kill -9 <eddie-ui pids>

 

[Tech Jedi Alex 1518]

Looks like you're one of those nvidia users, then. Nothing I can do with that, I've got Intel and AMD graphics only.

Btw, pkill's default signal is SIGTERM, causing Eddie to terminate normally, i.e., disconnect, disengage NetLock, etc., so it's certainly not forcing anything, and you will end up with an exposed network. It doesn't reproduce a crashing plasmashell.

[zebulon 1]

57 minutes ago, Tech Jedi Alex said:

Looks like you're one of those nvidia users, then. Nothing I can do with that, I've got Intel and AMD graphics only.

Btw, pkill's default signal is SIGTERM, causing Eddie to terminate normally, i.e., disconnect, disengage NetLock, etc., so it's certainly not forcing anything, and you will end up with an exposed network. It doesn't reproduce a crashing plasmashell.

OK then I use this:

$ sudo kill -9 <eddie-ui pids>

This kills the process. And the Internet is accessible, unencrypted. Note that using nvidia is irrelevant, any crash scenario may be applicable here (by the way it is more a Wayland issue than nvidia, it has been reported for non-nvidia users).
Anyway, the network lock should persist in case the UI crashes, no?

EDIT: it seems that after killing eddie processes, I am still connected to the VPN. I see the  kworker/14:0-wg-crypt-Eddie processes still running.
That's good.

[zebulon 1]

OK so I close it as solved. The eddie crash is only cosmetic, the VPN is still connected.

[Tech Jedi Alex 1518]

On 12/21/2025 at 3:25 PM, zebulon said:

EDIT: it seems that after killing eddie processes, I am still connected to the VPN. I see the  kworker/14:0-wg-crypt-Eddie processes still running.

Anything else would make no sense. Eddie doesn't get time to do things upon disconnection, so NetLock's firewall rules remain active.

Anyway, that is not what you observed, though, is it? You observed NetLock being disabled after a plasmashell crash. So we need to crash plasmashell to reproduce the situation – hence my question of how exactly you caused one, to reproduce it as natually as possible. Could very well be that some KDE component actually sends termination signals to GUI apps – that would actually cause Eddie to disconnect normally and therefore disengage NetLock. (Maybe SDDM? As in, "oh hey, plasmashell ceased existing, will SIGTERM all apps, restart plasmashell, go through the autostart config again".)
Though, looking at some documentation, maybe we don't need any specific way for this – we could send a SIGSEGV to plasmashell and see what happens.  If I find some time, I'll see what Eddie does when plasmashell is sent that.

[zebulon 1]

29 minutes ago, Tech Jedi Alex said:

Anything else would make no sense. Eddie doesn't get time to do things upon disconnection, so NetLock's firewall rules remain active.

Anyway, that is not what you observed, though, is it? You observed NetLock being disabled after a plasmashell crash. So we need to crash plasmashell to reproduce the situation – hence my question of how exactly you caused one, to reproduce it as natually as possible. Could very well be that some KDE component actually sends termination signals to GUI apps – that would actually cause Eddie to disconnect normally and therefore disengage NetLock. (Maybe SDDM? As in, "oh hey, plasmashell ceased existing, will SIGTERM all apps, restart plasmashell, go through the autostart config again".)
Though, looking at some documentation, maybe we don't need any specific way for this – we could send a SIGSEGV to plasmashell and see what happens.  If I find some time, I'll see what Eddie does when plasmashell is sent that.

Thanks for your comment. Actually I think I might have been confused and did not realize I was still connected to server. I cannot ascertain it was not the case, and I cannot reproduce the steps to crash eddie-ui and disconnect at the same time.That said I cannot ascertain the contrary either, and it would be reassuring to be sure we have a real failsafe network lock.

[Staff 10406]

14 hours ago, zebulon said:

it would be reassuring to be sure we have a real failsafe network lock

Hello!

Thank you first and foremost for this valuable information related to the possibility that a plasmashell crash can cause sending a graceful SIGTERM to children apps etc. This should be confirmed or denied as it is relevant.

From the correct and precise info that @Tech Jedi Alex provided, you now know that:

1. Network Lock is a set of firewall rules
2. if Eddie is properly shut down, it restores the previous firewall rules
3. if Eddie is killed ungracefully / crashes the rules remain in place, i.e. Network Lock stays "active"

Now, you have an unstable environment which might cause a proper Eddie shut down with a tranquil kill signal, so you need to either revert to a stable environment, or keep even the firewall rules that are restored as blocking rules preventing leaks, so you have a "permanent" lock.

Of course, should the environment cause modifications even to the filtering table, then a "permanent" network lock becomes impossible and the only real solution is using a stable environment, which would be the healthiest and safest solution. Seeking these types of protection when the operating environment itself is seriously unstable is not logic unless it's an exercise / proof when the assessed risk in controlled condition is zero (therefore do not use this environment for sensitive activity / sensitive data flow).

Kind regards
 

[zebulon 1]

On 12/23/2025 at 12:53 PM, Staff said:

Hello!

Thank you first and foremost for this valuable information related to the possibility that a plasmashell crash can cause sending a graceful SIGTERM to children apps etc. This should be confirmed or denied as it is relevant.

From the correct and precise info that @Tech Jedi Alex provided, you now know that:

1. Network Lock is a set of firewall rules
2. if Eddie is properly shut down, it restores the previous firewall rules
3. if Eddie is killed ungracefully / crashes the rules remain in place, i.e. Network Lock stays "active"

Now, you have an unstable environment which might cause a proper Eddie shut down with a tranquil kill signal, so you need to either revert to a stable environment, or keep even the firewall rules that are restored as blocking rules preventing leaks, so you have a "permanent" lock.

Of course, should the environment cause modifications even to the filtering table, then a "permanent" network lock becomes impossible and the only real solution is using a stable environment, which would be the healthiest and safest solution. Seeking these types of protection when the operating environment itself is seriously unstable is not logic unless it's an exercise / proof when the assessed risk in controlled condition is zero (therefore do not use this environment for sensitive activity / sensitive data flow).

Kind regards
 

Hello!

Many thanks for all these information and insight. Indeed I completely agree with what you state.

Meanwhile, I identified the culprit of plasmashell crashing: a system resource plasmoid I use on the Plasma desktop background. If I remove it, no crashes happen anymore. So the safe solution is to report it to its owner/author. Despite this I was unable to crash and end Eddie GUI gracefully, so I might have misidentified this happening. That said I will keep an eye and report again if I find a reproducible way. And I understand this is beyond your control and thank you very much for the feedback.

Kind regards!

[Tech Jedi Alex 1518]

While playing a game via Steam the GPU was reset. Haven't had that in a good while, but now that I had it I've got some semblance of what might happen with Eddie. And it must be verified further because the TL;DR is: No routes after a SIGABRT.
---
Steam is always started in a XWayland session, and the default for all games is to start a game in such a session, too. While switching into a game menu, the rendering froze and triggered a GPU reset. The system reacted as such:

Dez 28 21:09:03 x systemd-coredump[7555]: Process 4373 (steam) of user 1000 terminated abnormally with signal 6/ABRT, processing...

The Wayland session continued more or less unabated, it just noticed a grahics reset and that Xwayland-related things disappeared, too.

Dez 28 21:09:03 x kwin_wayland[1167]: A graphics reset not attributable to the current GL context occurred.
Dez 28 21:09:03 x kwin_wayland[1167]: 0x2: GL_CONTEXT_LOST in context lost

Systemd-coredump and a whole bunch of other services then noted that the X11 server and some processes were killed.

Dez 28 21:09:03 x systemd-coredump[7555]: Process 4373 (steam) of user 1000 terminated abnormally with signal 6/ABRT, processing...
Dez 28 21:09:03 x systemd-coredump[7653]: Process 1296 (Xwayland) of user 1000 terminated abnormally with signal 6/ABRT, processing...
Dez 28 21:09:03 x systemd-coredump[7688]: Process 2043 (Discord) of user 1000 terminated abnormally with signal 5/TRAP, processing...
Dez 28 21:09:03 x systemd-coredump[7717]: Process 3440 (Discord) of user 1000 terminated abnormally with signal 6/ABRT, processing...

So the magic signal sent in a crash scenario is SIGABRT. It can be caught, but not blocked.

Here comes the juice: Eddie seems to be started in a Xwayland session, too – xwininfo prints some info on the window which indicates it's not a Wayland window. Maybe it's Mono deciding where to run.

$ xwininfo | grep "Window id"
xwininfo: Window id: 0x1207c44 "Eddie - Ready"

So in essence this means: Were Eddie open and running in a GUI, it would've most likely been sent a SIGABRT. Can be caught to initiate emergency measures, but not blocked. So what happens if Eddie is connected and SIGABRT is sent? SIGABRT is caught by Mono, triggering a crash report.

Dez 28 21:47:13 x eddie-ui[10070]: ! 2025.12.28 21:47:13 - Connecting to Adhil (Germany, Frankfurt)
[…]
Dez 28 21:47:17 x eddie-ui[10070]: . 2025.12.28 21:47:17 - OpenVPN > Initialization Sequence Completed
Dez 28 21:47:17 x eddie-ui[10070]: . 2025.12.28 21:47:17 - OpenVPN > Data Channel: cipher 'AES-256-GCM', peer-id: 2, compression: 'stub'
Dez 28 21:47:17 x systemd[1]: Started Network Manager Script Dispatcher Service.
Dez 28 21:47:17 x NetworkManager[883]: <info>  [1766954837.4306] device (tun0): state change: ip-check -> secondaries (reason 'none', managed-type: 'external')
Dez 28 21:47:17 x NetworkManager[883]: <info>  [1766954837.4307] device (tun0): state change: secondaries -> activated (reason 'none', managed-type: 'external')
Dez 28 21:47:17 x NetworkManager[883]: <info>  [1766954837.4310] device (tun0): Activation: successful, device activated.
[…]

Dez 28 21:49:08 x sudo[18564]: gigan3rd : TTY=pts/1 ; PWD=/home/gigan3rd ; USER=root ; COMMAND=/usr/bin/kill -SIGABRT 10070
Dez 28 21:49:08 x sudo[18564]: pam_unix(sudo:session): session opened for user root(uid=0) by gigan3rd(uid=1000)
Dez 28 21:49:08 x eddie-ui[10070]: =================================================================
Dez 28 21:49:08 x eddie-ui[10070]:         Native Crash Reporting
Dez 28 21:49:08 x eddie-ui[10070]: =================================================================
Dez 28 21:49:08 x eddie-ui[10070]: Got a SIGABRT while executing native code. This usually indicates
Dez 28 21:49:08 x eddie-ui[10070]: a fatal error in the mono runtime or one of the native libraries
Dez 28 21:49:08 x eddie-ui[10070]: used by your application.
Dez 28 21:49:08 x eddie-ui[10070]: =================================================================
Dez 28 21:49:08 x eddie-ui[10070]: =================================================================
Dez 28 21:49:08 x eddie-ui[10070]:         Native stacktrace:
Dez 28 21:49:08 x eddie-ui[10070]: =================================================================
Dez 28 21:49:08 x eddie-ui[10070]:         0x55706ce767d5 - ./eddie-ui : (null)
Dez 28 21:49:08 x eddie-ui[10070]:         0x55706ce76b6c - ./eddie-ui : (null)
Dez 28 21:49:08 x eddie-ui[10070]:         0x55706ce22d02 - ./eddie-ui : (null)
Dez 28 21:49:08 x eddie-ui[10070]:         0x55706ce75dbf - ./eddie-ui : (null)
Dez 28 21:49:08 x eddie-ui[10070]:         0x7f1724e3e4d0 - /usr/lib/libc.so.6 : (null)
Dez 28 21:49:08 x eddie-ui[10070]:         0x7f1724e9f002 - /usr/lib/libc.so.6 : (null)
Dez 28 21:49:08 x eddie-ui[10070]:         0x7f1724e9316c - /usr/lib/libc.so.6 : (null)
Dez 28 21:49:08 x eddie-ui[10070]:         0x7f1724e931b4 - /usr/lib/libc.so.6 : (null)
Dez 28 21:49:08 x eddie-ui[10070]:         0x7f1724f0d4ae - /usr/lib/libc.so.6 : poll
Dez 28 21:49:08 x eddie-ui[10070]:         0x41bc1703 - Unknown
Dez 28 21:49:08 x eddie-ui[10070]: =================================================================
Dez 28 21:49:08 x eddie-ui[10070]:         Telemetry Dumper:
Dez 28 21:49:08 x eddie-ui[10070]: =================================================================
Dez 28 21:49:08 x sudo[18564]: pam_unix(sudo:session): session closed for user root
Dez 28 21:49:08 x eddie-ui[10070]: Pkilling 0x7f171dbfa6c0 from 0x7f1725519400
Dez 28 21:49:08 x eddie-ui[10070]: Pkilling 0x7f171f1ff6c0 from 0x7f1725519400
Dez 28 21:49:08 x eddie-ui[10070]: Pkilling 0x7f171d5ff6c0 from 0x7f1725519400
Dez 28 21:49:08 x eddie-ui[10070]: Pkilling 0x7f1722cff6c0 from 0x7f1725519400
Dez 28 21:49:08 x eddie-ui[10070]: Pkilling 0x7f171ed636c0 from 0x7f1725519400
Dez 28 21:49:08 x eddie-ui[10070]: Entering thread summarizer pause from 0x7f1725519400
Dez 28 21:49:08 x eddie-ui[10070]: Finished thread summarizer pause from 0x7f1725519400.
Dez 28 21:49:08 x eddie-ui[10070]: Waiting for dumping threads to resume
Dez 28 21:49:09 x eddie-ui[18595]: =================================================================
Dez 28 21:49:09 x eddie-ui[18595]:         External Debugger Dump:
Dez 28 21:49:09 x eddie-ui[18595]: =================================================================
Dez 28 21:49:09 x eddie-ui[18595]: [New LWP 17827]
Dez 28 21:49:09 x eddie-ui[18595]: [New LWP 10195]
Dez 28 21:49:09 x eddie-ui[18595]: [New LWP 10134]
Dez 28 21:49:09 x eddie-ui[18595]: [New LWP 10083]
Dez 28 21:49:09 x eddie-ui[18595]: [New LWP 10072]
Dez 28 21:49:09 x eddie-ui[18595]: [New LWP 10071]
Dez 28 21:49:09 x eddie-ui[18595]: This GDB supports auto-downloading debuginfo from the following URLs:
Dez 28 21:49:09 x eddie-ui[18595]:   <https://debuginfod.archlinux.org>
Dez 28 21:49:09 x eddie-ui[18595]: Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal]
Dez 28 21:49:09 x eddie-ui[18595]: Debuginfod has been disabled.
Dez 28 21:49:09 x eddie-ui[18595]: To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
Dez 28 21:49:09 x eddie-ui[18595]: [Thread debugging using libthread_db enabled]
Dez 28 21:49:09 x eddie-ui[18595]: Using host libthread_db library "/usr/lib/libthread_db.so.1".
Dez 28 21:49:09 x eddie-ui[18595]: 0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]:   Id   Target Id                                           Frame
Dez 28 21:49:09 x eddie-ui[18595]: * 1    Thread 0x7f1725519400 (LWP 10070) "eddie-ui"        0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]:   2    Thread 0x7f171d5ff6c0 (LWP 17827) "eddie-ui"        0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]:   3    Thread 0x7f171dbfa6c0 (LWP 10195) "eddie-ui"        0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]:   4    Thread 0x7f171ed636c0 (LWP 10134) "Thread Pool I/O" 0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]:   5    Thread 0x7f171f1ff6c0 (LWP 10083) "eddie-ui"        0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]:   6    Thread 0x7f1722cff6c0 (LWP 10072) "Finalizer"       0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]:   7    Thread 0x7f17217ff6c0 (LWP 10071) "SGen worker"     0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: Thread 7 (Thread 0x7f17217ff6c0 (LWP 10071) "SGen worker"):
Dez 28 21:49:09 x eddie-ui[18595]: #0  0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #1  0x00007f1724e9316c in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #2  0x00007f1724e937dc in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #3  0x00007f1724e95e9e in pthread_cond_wait () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #4  0x000055706d0c7656 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #5  0x00007f1724e9698b in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #6  0x00007f1724f1a9cc in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: Thread 6 (Thread 0x7f1722cff6c0 (LWP 10072) "Finalizer"):
Dez 28 21:49:09 x eddie-ui[18595]: #0  0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #1  0x00007f1724e9316c in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #2  0x00007f1724e937dc in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #3  0x00007f1724e9ef08 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #4  0x000055706d06e1a8 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #5  0x000055706d01ba87 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #6  0x00007f1724e9698b in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #7  0x00007f1724f1a9cc in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: Thread 5 (Thread 0x7f171f1ff6c0 (LWP 10083) "eddie-ui"):
Dez 28 21:49:09 x eddie-ui[18595]: #0  0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #1  0x00007f1724e9316c in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #2  0x00007f1724e937dc in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #3  0x00007f1724e960a8 in pthread_cond_timedwait () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #4  0x000055706d0d499b in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #5  0x000055706d0dfbe1 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #6  0x000055706d018ea0 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #7  0x000055706cfac661 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #8  0x0000000041be20be in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #9  0x00007f1721826b30 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #10 0x00007f171f1fe8b0 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #11 0x00007f171eeb79e8 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #12 0x0000000000000000 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: Thread 4 (Thread 0x7f171ed636c0 (LWP 10134) "Thread Pool I/O"):
Dez 28 21:49:09 x eddie-ui[18595]: #0  0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #1  0x00007f1724e9316c in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #2  0x00007f1724e931b4 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #3  0x00007f1724f0d4ae in poll () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #4  0x000055706d01f365 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #5  0x000055706d0207c2 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #6  0x000055706d01ba87 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #7  0x00007f1724e9698b in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #8  0x00007f1724f1a9cc in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: Thread 3 (Thread 0x7f171dbfa6c0 (LWP 10195) "eddie-ui"):
Dez 28 21:49:09 x eddie-ui[18595]: #0  0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #1  0x00007f1724e9316c in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #2  0x00007f1724e931b4 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #3  0x00007f1724f0da2e in read () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #4  0x000055706cf42ceb in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #5  0x000055706cf41015 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #6  0x000055706d0822ad in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #7  0x000055706cf9c8b4 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #8  0x0000000041a7131e in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #9  0x00007f1721a568e8 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #10 0x00007f1721a568e8 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #11 0x00007f1721a7d688 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #12 0x0000000000000000 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: Thread 2 (Thread 0x7f171d5ff6c0 (LWP 17827) "eddie-ui"):
Dez 28 21:49:09 x eddie-ui[18595]: #0  0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #1  0x00007f1724e9316c in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #2  0x00007f1724e937dc in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #3  0x00007f1724e960a8 in pthread_cond_timedwait () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #4  0x000055706d0d499b in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #5  0x000055706d0dfbe1 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #6  0x000055706d018ea0 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #7  0x000055706cfac661 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #8  0x0000000041be20be in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #9  0x00007f1721afb2e0 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #10 0x00007f1721afb260 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #11 0x00007f1721afb260 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #12 0x00007f1721afb260 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #13 0x0000000000000064 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #14 0x00007f1708002fa0 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #15 0x00007f171d5fe910 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #16 0x00007f171d5fe1a0 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #17 0x0000000000000000 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: Thread 1 (Thread 0x7f1725519400 (LWP 10070) "eddie-ui"):
Dez 28 21:49:09 x eddie-ui[18595]: #0  0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #1  0x00007f1724e9316c in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #2  0x00007f1724e931b4 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #3  0x00007f1724f03d8f in wait4 () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #4  0x000055706ce769e1 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #5  0x000055706ce76b6c in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #6  0x000055706ce22d02 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #7  0x000055706ce75dbf in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #8  <signal handler called>
Dez 28 21:49:09 x eddie-ui[18595]: #9  0x00007f1724e9f002 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #10 0x00007f1724e9316c in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #11 0x00007f1724e931b4 in ?? () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #12 0x00007f1724f0d4ae in poll () from /usr/lib/libc.so.6
Dez 28 21:49:09 x eddie-ui[18595]: #13 0x0000000041bc1703 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #14 0x0000557081321df8 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #15 0x0000000000000002 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #16 0x00007f1721a7e7e0 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #17 0x00007f171ef60190 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #18 0x0000000000000002 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #19 0x00007f171ef70550 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #20 0x000055708136a0d0 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #21 0x0000000000000002 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #22 0x00007ffe3f0726d0 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: #23 0x0000000000000000 in ?? ()
Dez 28 21:49:09 x eddie-ui[18595]: [Inferior 1 (process 10070) detached]
Dez 28 21:49:10 x eddie-ui[10070]: =================================================================
Dez 28 21:49:10 x eddie-ui[10070]:         Basic Fault Address Reporting
Dez 28 21:49:10 x eddie-ui[10070]: =================================================================
Dez 28 21:49:10 x eddie-ui[10070]: Memory around native instruction pointer (0x7f1724e9f002):0x7f1724e9eff2  8b 44 24 08 4c 8b 4c 24 10 4c 89 5c 24 08 0f 05  .D$.L.L$.L.\$...
Dez 28 21:49:10 x eddie-ui[10070]: 0x7f1724e9f002  c3 66 2e 0f 1f 84 00 00 00 00 00 66 2e 0f 1f 84  .f.........f....
Dez 28 21:49:10 x eddie-ui[10070]: 0x7f1724e9f012  00 00 00 00 00 66 0f 1f 84 00 00 00 00 00 f3 0f  .....f..........
Dez 28 21:49:10 x eddie-ui[10070]: 0x7f1724e9f022  1e fa 55 bf 01 00 00 00 48 89 e5 e8 8e 2c 06 00  ..U.....H....,..
Dez 28 21:49:10 x eddie-ui[10070]: =================================================================
Dez 28 21:49:10 x eddie-ui[10070]:         Managed Stacktrace:
Dez 28 21:49:10 x eddie-ui[10070]: =================================================================
Dez 28 21:49:10 x eddie-ui[10070]:           at <unknown> <0xffffffff>
Dez 28 21:49:10 x eddie-ui[10070]:           at Mono.Unix.Native.Syscall:sys_poll <0x000d2>
Dez 28 21:49:10 x eddie-ui[10070]:           at Mono.Unix.Native.Syscall:poll <0x0011b>
Dez 28 21:49:10 x eddie-ui[10070]:           at System.Windows.Forms.XplatUIX11:UpdateMessageQueue <0x00513>
Dez 28 21:49:10 x eddie-ui[10070]:           at System.Windows.Forms.XplatUIX11:UpdateMessageQueue <0x00037>
Dez 28 21:49:10 x eddie-ui[10070]:           at System.Windows.Forms.XplatUIX11:GetMessage <0x002db>
Dez 28 21:49:10 x eddie-ui[10070]:           at System.Windows.Forms.XplatUI:GetMessage <0x00064>
Dez 28 21:49:10 x eddie-ui[10070]:           at System.Windows.Forms.Application:RunLoop <0x00a77>
Dez 28 21:49:10 x eddie-ui[10070]:           at System.Windows.Forms.Application:Run <0x00063>
Dez 28 21:49:10 x eddie-ui[10070]:           at Eddie.Forms.Linux.Program:Main <0x0046b>
Dez 28 21:49:10 x eddie-ui[10070]:           at System.Object:runtime_invoke_void <0x00086>
Dez 28 21:49:10 x eddie-ui[10070]: =================================================================
Dez 28 21:49:10 x systemd-coredump[18623]: Process 10070 (eddie-ui) of user 1000 terminated abnormally with signal 6/ABRT, processing...

No further output from Eddie. The routes, though, are gone. Note the single lonely 37.46.99.68 route which is Adhil. Weird that this one remains while everything else is gone.
The window needed a few seconds to disappear, and I believe this is caused by Eddie/OpenVPN actually dismantling the connection more or less normally (the --explicit-exit-notify seems to be honored).

at 21:49:30 ❯ ip -6 r
::1 dev lo proto kernel metric 30 pref medium
2003:x:x:x::/64 dev enp39s0 proto ra metric 100 pref medium
2003:x:x:x::/56 via fe80::d624:ddff:fe57:6a09 dev enp39s0 proto ra metric 100 pref high
fddf:cd71:e2de::/64 dev enp39s0 proto ra metric 100 pref medium
fddf:cd71:e2de::/64 via fe80::d624:ddff:fe57:6a09 dev enp39s0 proto ra metric 105 pref high
fe80::/64 dev enp39s0 proto kernel metric 1024 pref medium
default via fe80::d624:ddff:fe57:6a09 dev enp39s0 proto ra metric 100 pref high

~  
at 21:49:33 ❯ ip -4 r
default via 192.168.110.1 dev enp39s0 proto dhcp src 192.168.110.12 metric 100  
37.46.199.68 via 192.168.110.1 dev enp39s0  
127.0.0.0/8 dev lo proto kernel scope link src 127.0.0.1 metric 30  
192.168.110.0/24 dev enp39s0 proto kernel scope link src 192.168.110.12 metric 100
 

---
It must be noted that I killed the Mono process, not the shell session that is running Mono. 10069 was the Bash script, 10070 the eddie-ui process after it.

at 21:48:04 ❯ pstree 10069
eddie-ui───eddie-ui─┬─eddie-cli-eleva─┬─openvpn
             (^)    │                 └─2*[{eddie-cli-eleva}]
     (here SIGABRT) ├─eddie-tray───7*[{eddie-tray}]
                    └─6*[{eddie-ui}]

.

[zebulon 1]

Thank you for the detailed report. Do you mean the Lock was lost and then it was routing in clear over the internet?

[Tech Jedi Alex 1518]

3 hours ago, zebulon said:

Thank you for the detailed report. Do you mean the Lock was lost and then it was routing in clear over the internet?

Ah, I forgot to check that. Apologies. Retested.
Confirmed that Network Lock is not disengaged when Eddie is SIGABRTed. All nf_tables rules were still present.
While the VPN connection is terminated more or less normally, Eddie does not disengage NetLock, so people are probably safe when it comes to crashes.

[zebulon 1]

23 hours ago, Tech Jedi Alex said:

Ah, I forgot to check that. Apologies. Retested.
Confirmed that Network Lock is not disengaged when Eddie is SIGABRTed. All nf_tables rules were still present.
While the VPN connection is terminated more or less normally, Eddie does not disengage NetLock, so people are probably safe when it comes to crashes.

OK this is great. I think the key process is kworker/14:0-wg-crypt-Eddie whichis separate from the UI. So even if the UI crashes those process stay unaffected and do not disengage the lock. Only a clean end signal for Edie UI also disengage the lock, as it does when exiting Eddie UI cleanly. Am I correct here?

[Tech Jedi Alex 1518]

16 minutes ago, zebulon said:

Only a clean end signal for Edie UI also disengage the lock, as it does when exiting Eddie UI cleanly. Am I correct here?

That is yet to be determined. SIGTERM will do that, but it will also trigger the confirmation dialog about closing Eddie (set in Preferences > UI > Exit confirmation prompt). I wonder which of the other termination signals will trigger a normal termination, too. Maybe none of them. Not really clear from man signal.h, there's an interesting table there. T is a termination signal, A is termination with additional actions. SIGTERM and SIGKILL are both T, but one is a butler politely asking you to leave, the other is a guillotine. Our SIGABRT is A, and Mono is given time to create a crash report, so I carefully deduce that all A signals will cause a crash report to be generated, and Eddie will disconnect but leave NetLock on.

The following signals shall be supported on all implementations (default actions are explained below the table):
                                                                                                      ┌───────────┬────────────────┬────────────────────────────────────────────────────┐
                                                                                                      │  Signal   │ Default Action │                    Description                     │
                                                                                                      ├───────────┼────────────────┼────────────────────────────────────────────────────┤
                                                                                                      │ SIGABRT   │       A        │ Process abort signal.                              │
                                                                                                      │ SIGALRM   │       T        │ Alarm clock.                                       │
                                                                                                      │ SIGBUS    │       A        │ Access to an undefined portion of a memory object. │
                                                                                                      │ SIGCHLD   │       I        │ Child process terminated, stopped,                 │
                                                                                                      │           │                │ or continued.                                      │
                                                                                                      │ SIGCONT   │       C        │ Continue executing, if stopped.                    │
                                                                                                      │ SIGFPE    │       A        │ Erroneous arithmetic operation.                    │
                                                                                                      │ SIGHUP    │       T        │ Hangup.                                            │
                                                                                                      │ SIGILL    │       A        │ Illegal instruction.                               │
                                                                                                      │ SIGINT    │       T        │ Terminal interrupt signal.                         │
                                                                                                      │ SIGKILL   │       T        │ Kill (cannot be caught or ignored).                │
                                                                                                      │ SIGPIPE   │       T        │ Write on a pipe with no one to read it.            │
                                                                                                      │ SIGQUIT   │       A        │ Terminal quit signal.                              │
                                                                                                      │ SIGSEGV   │       A        │ Invalid memory reference.                          │
                                                                                                      │ SIGSTOP   │       S        │ Stop executing (cannot be caught or ignored).      │
                                                                                                      │ SIGTERM   │       T        │ Termination signal.                                │
                                                                                                      │ SIGTSTP   │       S        │ Terminal stop signal.                              │
                                                                                                      │ SIGTTIN   │       S        │ Background process attempting read.                │
                                                                                                      │ SIGTTOU   │       S        │ Background process attempting write.               │
                                                                                                      │ SIGUSR1   │       T        │ User-defined signal 1.                             │
                                                                                                      │ SIGUSR2   │       T        │ User-defined signal 2.                             │
                                                                                                      │ SIGPOLL   │       T        │ Pollable event.                                    │
                                                                                                      │ SIGPROF   │       T        │ Profiling timer expired.                           │
                                                                                                      │ SIGSYS    │       A        │ Bad system call.                                   │
                                                                                                      │ SIGTRAP   │       A        │ Trace/breakpoint trap.                             │
                                                                                                      │ SIGURG    │       I        │ High bandwidth data is available at a socket.      │
                                                                                                      │ SIGVTALRM │       T        │ Virtual timer expired.                             │
                                                                                                      │ SIGXCPU   │       A        │ CPU time limit exceeded.                           │
                                                                                                      │ SIGXFSZ   │       A        │ File size limit exceeded.                          │
                                                                                                      │           │                │                                                    │
                                                                                                      └───────────┴────────────────┴────────────────────────────────────────────────────┘

.