I often make fun of @ljs for using wifi on his desktop, but the truth is something sucks with my ethernet connection from desktop to Turris, despite this being done with just a 1m factory-made patch cable. So far I've found 2 things that cause short link-downs:
- electrical blinds being moved in the nearby windows
- a close enough lightning strike

But there are other yet unkown factors too. Helpfully, @NetworkManager will always use these events to drop the vpn without restarting it automatically :( (or just waiting for the few seconds until the link recovers).

@vbabka SFTP (not the protocol) for the win.

@vbabka @ljs there's a way to tie the vpn to another connection so that it's always brought back up, but i think also some way to recover on reconnect. i don't remember, perhaps somebody familiar with NetworkManager might know

@vbabka @NetworkManager @ljs you can surely use systemd-networkd, sir

@NetworkManager

`nmcli c modify ${CON?} vpn.persistent yes` is what @vbabka wants.

@ljs

@djasa @vbabka @ljs thank you, you're the best!

@djasa @NetworkManager @vbabka @ljs did you mean `vpn.do-not-nap`?

@djasa @NetworkManager @ljs where do I find this equivalent in the KDE frontend, kind sir?

@liskin @djasa @NetworkManager @ljs @vbabka the man is a walking napster so much so that metallica try to sue him in 2024

@djasa @NetworkManager @ljs so, setting this caused the vpn secrets (password, via KDE wallet) to be forgotten. Filling them again from the KDE GUI caused the vpn.persistent flag to be reset to "no". Luckily another nmcli command to set the persistent flag didn't reset the secrets the second time. So hopefully it's fine now but I wonder if the software was written by intoxicated great apes from Brno, or what.

@vbabka @NetworkManager @ljs Happened to me, found it was caused by power management. Power saving mode causes some network cards to decrease its speed from 1G to 100M and back, the change involves a short link outage.

@vbabka @djasa @ljs i don't think you're a real software engineer

@vbabka @djasa @NetworkManager @ljs yes.

@hny @vbabka @NetworkManager @ljs who needs all this crap if you can simply run a series of ip (8) commands from a boot script?

@NetworkManager @djasa @ljs for using KDE? yes it's my dirty secret

@vbabka , regardless of who writes NM code, your writing seems better destined at either of these places: 😉
* https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/
* https://gitlab.gnome.org/search?search=NetworkManager&nav_source=navbar&group_id=8

@NetworkManager @ljs

@djasa mind helping out maintaining out fedi presence? i'm just about to insult @ptesarik but i think you'd be a little bit less of an embarrassment
(check your work e-mail)

I won't mind.

-- @djasa 🙂

@ptesarik network management daemons are for all those who need more than a series of ip(8) commands running just after boot. Turns out, it's quite widespread these days.

@hny @vbabka @ljs

@djasa @NetworkManager @ljs dunno man, unlike fediverse these places look too serious for shitposts to me

@NetworkManager @ptesarik @hny @ljs come on @djasa at least make fun of his bare feet

@vbabka @djasa @ptesarik @hny @ljs or make him drown in the sad realization that netlink messages are never really guarranteed to go through and iproute might just not try hard enough
then make him look how hard do we try, and be even more sad
(truly yours, lr)

@NetworkManager @vbabka @djasa @hny @ljs I admit I didn't know that. But no problem, just use this:

while ! ip a add dev eth0 192.168.1.1/24 ; do : ; done

This must be better than all those network daemons. 😉 Plus you can have some fun if it turns out to be an infinite loop.

@ptesarik @vbabka @djasa @hny @ljs bro that is basically what we do (lr)

@vbabka , you suppose that #barefoot style is somehow linked with avoidance of network management daemons?

@NetworkManager @ptesarik @hny @ljs

@NetworkManager @vbabka @ljs On the Ethernet connection, connection.secondaries to the VPN connection. But probably it will ask again for the password? Or not, I'm not sure

@NetworkManager @vbabka @ljs BTW, NetworkManager is not familiar with NetworkManager? I'm confused, sir

@ihuguet @NetworkManager @ljs does that cause vpn autostart once ethernet is up? I don't want that, just the "not autostop" on short link flaps.

@NetworkManager @vbabka @djasa @hny @ljs In my youth, admins would not let a random daemon mess up their networks. Bro, Linux admins were real men back then; they messed up their networks all by themselves…

@ptesarik @NetworkManager @djasa @hny @ljs hm yes and connecting to a wifi network required the root password, which apparently made somebody very angry, but luckily it wasn't anybody important.

@NetworkManager @vbabka yes, exactly.

What you want doesn't exist. Actually I proposed the same, something like autoreconnect, but nobody has worked on it.

Anyway, look if carrier-wait-timeout and/or ignore-carrier in NetworkManager.conf can help with your use case: https://networkmanager.dev/docs/api/latest/NetworkManager.conf.html

@vbabka @djasa @NetworkManager @hny @ljs Bah. When real men took care of messing up the Internet, wifi was not even a thing. Token Ring competed with 10BASE2, the Internet ran on DECnet, and it made no headlines when IPX was spotted in the wild.

I would ban all those wifis. They merely annoy people.

@ihuguet @NetworkManager uh so what exactly does the vpn.persistent setting do? See up the thread https://cztwitter.cz/@djasa/112633189742692281

@vbabka @NetworkManager @ljs for some reason I didn't get pinged on this thread! Weird

Maybe my wifi?

@ptesarik @vbabka @NetworkManager @hny @ljs

@vbabka @NetworkManager according to the docs, in theory exactly what you need, as @djasa said.

man nm-settings: https://networkmanager.dev/docs/api/latest/nm-settings-nmcli.html

Is it not working?

The issue of the forgotten passwords and such surely is a different thing, some misunderstanding between NM and the nm-plasma client. If you are able to find a reproducer, bug report is welcome. Hint: if you try, execute nmcli without the GUI open (I suspect that you overwrote the nmcli changes with the old value still shown in the GUI).

@ptesarik @vbabka @djasa @NetworkManager @ljs all those modern technologies like wifi, ethernet or shoes...

@vbabka `vpn.persistent yes` means:

1. link status of the underlying connection going down ceases to be reason do down the VPN connection as well

2. for VPNs that support it (at least OpenVPN, I don't know about other ones), VPN connection transparently switches between any available links

Thus, with `vpn.persistent yes` on an OpenVPN connection survives:
✅ short suspend-resume cycles
✅ switch from your home wired/wifi to a mobile hotspot

1/2
(dj)

@ihuguet

@vbabka however these perks come with an obvious cost of apps that use #NetworkManager losing awareness of connection being actually down between the loss of all links and VPN timeout, thus timing out themselves.

2/2
(dj)

@ihuguet

@NetworkManager @ihuguet I think that's how OpenVPN worked for me when I was running it via systemd service. The downsides didn't bother me. I might try looking at the forgotten secrets again, but since it didn't happen the second time, might have been some fluke. The "save config in the GUI and unknown settings (to the GUI) previously set by nmcli are lost" might be still happening so I'll find the report that must already exist and cc myself ;)

@ihuguet @NetworkManager @djasa yeah after seeing some link downs in dmesg and vpn still up, I can confirm it's working \o/

@ptesarik @vbabka @djasa @NetworkManager @hny @ljs real men are just bald monkeys with atrophied musculature

be a great ape