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

[zebulon 0]

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 0]

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 0]

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 0]

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 0]

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 10398]

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