All Activity
This stream auto-updates
- Past hour
-
-
-
-
-
-
-
-
- Today
-
-
-
Hello! Thank you for the screenshots, they help a lot. Windows still lists the Eddie window ("Eddie - Ready" in the taskbar preview and in Task View), so Eddie is running and its main window exists: most likely it is placed outside the visible area of your screen. Eddie restores the last saved window position at startup and checks it only roughly against the screen size, so a position saved with a different display setup (another monitor, a TV, a dock, a change of resolution or scaling) can put it where you cannot see it. Please try these steps in order: 1. Right-click the Eddie tray icon and look at the item above "Exit". If it says "Show Main Window", click it. If it says "Hide Main Window", Eddie believes the window is already shown, so go to step 2. 2. Click the Eddie button on the taskbar so that the window gets the focus, then press Win+Up, or Win+Shift+Left / Win+Shift+Right. Alternatively, with the window focused, press Alt+Space, then M, then one arrow key, and move the mouse: the window follows the mouse until you click. When it is back, exit Eddie normally from the tray icon, so that the good position is saved. 3. If that does not work, reset the saved position from the command line. Exit Eddie from the tray icon, check in Task Manager that no Eddie-UI.exe is left, then press Win+R and run: "C:\Program Files\AirVPN\Eddie-UI.exe" -path=home --gui.window.main= The window should open centred on your main monitor. Exit once from the tray icon to save that position. If you installed Eddie in another folder, adjust the path. About the config files: Eddie keeps its settings in %LOCALAPPDATA%\Eddie (C:\Users\<your name>\AppData\Local\Eddie), not in the installation folder, and uninstalling Eddie does not remove them. If default.profile is deleted while Eddie is still running in the tray, Eddie writes it back when it exits, with the same window position. So if you want to try a clean profile, exit Eddie from the tray first (you will have to log in again and set your preferences again). If none of this helps, please tell us the Eddie version (tray icon > About), whether your display setup or Windows display scaling changed about two weeks ago (new monitor, TV, dock, remote desktop or game streaming software), and send us a system report (tray icon > About > System Report), as explained here: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do Kind regards
-
DeepAnger reacted to a post in a topic:
Wave VPN: open-source WireGuard client for Android and Linux (unofficial, v0.1.1) ...
-
DeepAnger reacted to a post in a topic:
Wave VPN: open-source WireGuard client for Android and Linux (unofficial, v0.1.1) ...
-
I have been fighting this for a couple of weeks now and at this point I am at a loss. Nobody else seems to have this issue that I can see so I am left no other option. No, the application is not starting minimized. Yes, the icon is visible in my tray. I am able to open the preferences window and adjust as needed from the tray icon, but the main window continues to illude me. As such, I am unable to choose what server to connect to or really get most of the functionality out of the application. I tried updating the app, nothing. Uninstall and reinstall, nothing. Checked the forums, nothing. Deleted the config files associated with the app, nothing. I have attached images to show that the screen ought to be visible, but alas, nothing. It is not hiding on another monitor as best I can tell, nor is it hiding on another desktop. I simply is not appearing and I have no idea why. Please help.
- Yesterday
-
@VesselWave Hello! Thank you for the quick update. We checked 0.1.3 and the three points are addressed on both platforms. While checking the Android version we noticed a few bugs, which you might like to cross-check. References are to wave-vpn-mobile v0.1.3 (commit 2a406b6). 1. Connecting can stay blocked after a failed handshake After a connection attempt without a handshake, the next Connect first refreshes the account, with a 3 second timeout (Connection.kt:162). When the timeout expires, the TimeoutCancellationException is rethrown as a cancellation (Connection.kt:247-250), so the status stays "Connecting..." with no attempt running until the user cancels. recoveryNeeded stays true (SessionWork.kt:52), so every later Connect needs that refresh to succeed within 3 seconds first, and a retry within the 60 second budget fails at once with "Wait N seconds". Also, a request cut by the timeout does not count as a failure for its URL, because the cancellation check comes first (Protocol.kt:174), so the next attempt does not move away from a URL that silently drops packets. Where our bootstrap servers are slow or blocked, users may be unable to reconnect at all. If this problem is confirmed, you might like to consider not making Connect depend on that refresh, and counting a timed-out request as a failure of its URL. 2. The whole manifest is rejected if its bootstrap part does not validate When the manifest arrives, Documents.kt:75-86 checks the bootstrap URLs and the RSA key. If any of them is missing or invalid, the whole manifest is discarded, including the server list, which may be perfectly fine. As a result, sign-in and server list refresh fail. In the same case the desktop version ignores only the bootstrap part: it keeps using the previous bootstrap URLs and key, and still accepts the new server list. Doing the same on Android would make it more robust. 3. No connectivity after a failed connect, while the app says "Disconnected" When bringing the tunnel up fails, the blocking interface is put back and the service keeps running (Connection.kt:257-264). The app shows "Disconnected" with "Couldn't connect" and the only action offered is Connect, so the device has no connectivity and the app gives no way to release the block other than a successful connection. If the block is intentional and this behavior is confirmed, it would help to say so clearly on that screen and offer an action that removes it. 4. "Only selected" with no app checked With split tunnelling set to "Only selected" and no app checked, no IncludedApplications line is written (Wireguard.kt:38-39), so all traffic goes through the VPN, while the screen says "Only checked apps use the VPN. Everything else connects directly." (AppsScreen.kt:88). This fails in the safe direction, but the text is misleading. If we find the time, we will also have a closer look at the desktop version and let you know. Thank you again for your work. Kind regards
-
-
-
-
- Last week
-
-
-
Hello! We inform you that the three AirVPN servers located in Manchester, UK, are being migrated to new machines: Bubup Ceibo Chaophraya The servers keep the same names, configuration, hardware and 10 Gbit/s port. Their IP addresses change, both entry and exit, IPv4 and IPv6. Planned date: 2026-11-09, between 8 AM and 7 PM UTC. Each server might be unavailable for a short time during the switch. What you need to do after the switch: Eddie, the AirVPN Suite and the other software that downloads the server list from us: nothing. The new addresses are picked up automatically. Configuration files generated with the Configuration Generator that use host names: nothing, the names will resolve to the new addresses. Configuration files that contain IP addresses (for example with the "Resolved hosts" option, or WireGuard files with an IP address in Endpoint): please generate them again after the migration. Firewall rules, routers or scripts that allow or refer to the old IP addresses of these servers: please update them. Remote port forwarding is not affected: your forwarded ports stay the same. Kind regards & datalove AirVPN Staff
-
-
VesselWave reacted to a post in a topic:
Wave VPN: open-source WireGuard client for Android and Linux (unofficial, v0.1.1) ...
-
Thank you for the review! Android 0.1.3 and Linux 0.1.3 address all three points: verification at connection time, bounded and cached latency sampling with no probes while connected, and saved bootstrap URLs/RSA keys with failover and backoff. Please let me know if you spot anything else. I hope Wave attracts enough users and contributors to warrant its own subforum eventually. Best regards
-
go558a83nk reacted to a post in a topic:
Wave VPN: open-source WireGuard client for Android and Linux (unofficial, v0.1.1) ...
-
-
Hello! First of all, thank you for writing free and open source software dedicated to AirVPN. We had a quick look at both repositories. The code is careful and we did not find any telemetry and/or third-party endpoints. The client identifies itself honestly and the documentation describes our protocol accurately. We appreciate it. There are three points that affect our infrastructure, which you might like to take into account for the next releases. References are to wave-vpn-desktop at commit ce9a15fd and wave-vpn-mobile at commit 64a2be1b. 1. Periodic tunnel verification (desktop) verify_tunnel() in src/platform/linux.rs runs every 60 seconds for the whole session: the tun check for each IP family and the dns check on https://<server>_exit.airservers.org:89/check/, plus a checkdns.airvpn.org query. Any failure tears the tunnel down. Eddie runs these checks only once, right after connecting. With a 60 second loop, a short outage of the check service would disconnect every Wave VPN user at the same time, and they would all reconnect together. You might like to consider running the checks only at connection time, or much less often with some random jitter, and not disconnecting on a single failed check. 2. Latency measurement (desktop and Android) The "ping" is a TCP connection to port 443 on the first entry IPv4 of every server (src/gui.rs on desktop, vpn/Connection.kt on Android), so about 250 connections are opened and closed at every login, launch and refresh. The desktop refresh can go down to 15 seconds from the command line, and the Android manual refresh has no rate limit. A lighter probe such as ICMP echo, fewer probes in parallel, cached results with a minimum interval between refreshes, and no probes while connected (they go through the tunnel and skew the ranking anyway) would help a lot. Also, on desktop an unreachable server currently counts as 0 ms (src/documents.rs), so "Best server" ends up preferring servers that do not answer. 3. Bootstrap servers (desktop and Android) The desktop client always uses the bootstrap URLs and the RSA key from the AirVPN.json compiled into the binary and ignores the ones in the manifest (src/lib.rs, src/documents.rs). If we change bootstrap addresses or rotate the key, older builds would stop working. It might be worth storing and using the bootstrap URLs and key from the latest manifest, and keeping the embedded ones only as a first-run fallback. On Android, Protocol.kt and Session.kt send user and manifest at every refresh, always to the first URL, with no backoff while the bootstrap servers are unreachable. Trying the other URLs when one fails, with an increasing delay between retries, would make the client more robust and lighter on our side. Thank you again for your work. Feel free to ask here if anything about the protocol is unclear. Kind regards
-
Hello! At startup Eddie downloads the server list from our bootstrap servers. "Fetch url error: timeout was reached" means that none of them answered in time. It fails on two different ISPs and our website is slow and sometimes loads without CSS. So the problem is most likely between your Mac and our infrastructure. It could be filtering or throttling in your country, or something on the Mac that affects every network it uses. The "HTTP IPv4: Timeout" line alone is not conclusive: it can fail even where Eddie works normally. To narrow it down, could you please tell us: 1. Which country are you connecting from? 2. Does our website load normally on another device in the same place, for example a phone on mobile data with Wi-Fi off? 3. Is any security, firewall or filtering software installed on the Mac (Little Snitch, LuLu, an antivirus, parental controls, another VPN)? Please also check System Settings > Network > VPN & Filters, and make sure that iCloud Private Relay is off and that no proxy is set in System Settings > Network > your connection > Details > Proxies. In the meantime you can connect without Eddie. Generate a WireGuard configuration file with the Config Generator (https://airvpn.org/generator/), import it into the official WireGuard app from the Mac App Store and connect. While that tunnel is up, start Eddie so it can download the server list, then disconnect WireGuard before connecting with Eddie. If the problem persists, please send us an Eddie system report. The instructions are here: https://airvpn.org/forums/topic/50663-youve-been-asked-for-a-support-filesystem-report-–-heres-what-to-do If you prefer not to post it publicly, you can open a ticket and attach it there. Kind regards
-
Title: Eddie cannot retrieve AirVPN information — Fetch URL timeout (MacBook Air M1, macOS Ventura) Hello AirVPN team! I have been using Eddie for about 5 years without any problems. Today, it suddenly stopped displaying available AirVPN servers. The error message is: Cannot retrieve information about AirVPN: Fetch url error: timeout was reached My system: MacBook Air M1 (2020) macOS Ventura 13.5 Eddie 2.26.2 (previously 2.24.6) What I have tried: Restarting Eddie. Updating Eddie from 2.24.6 to 2.26.2. Moving the application to the Applications folder. Testing Eddie on two different internet connections with different ISPs. The problem persists on both networks. Additional diagnostic information: DNS IPv4: OK DNS IPv6: OK HTTP IPv4: Timeout HTTP IPv6: Failed HTTPS: OK Network Lock: Disabled Regular websites work normally, but AirVPN's website loads very slowly and sometimes without CSS styling. Could this be related to bootstrap server connectivity or HTTP filtering? Could you please help me diagnose this issue? Thank you!
-
-
ANSWERED Eddie stuck on trying to connect
Nitrox replied to Nitrox's topic in Troubleshooting and Problems
Well. I have the same issue, I just do the steps again. And wait for the new version. -
I forgot to mention that I am using windows 11.
-
I too have had problems with wifi having dns leaks. Ethernet is fine. This is with 2.26.2. I have not yet tried 2.27.2 as others mentioned original dns settings not being restored with vpn session ended.
-
apple cider reacted to a post in a topic:
Wave VPN: open-source WireGuard client for Android and Linux (unofficial, v0.1.1) ...
-
-
Hi all, I built Wave VPN, an open-source (GPL-3.0) WireGuard client for AirVPN on Android and Linux. Sign in with your AirVPN account, pick a server, and connect. AirVPN does not endorse this independent project. Download: vpn.vwave.me. On Android, add my F-Droid repository to get automatic updates. Version 0.1.1 is an early release. Anyone can use it, but I have not tested it on every device and setup yet. Disclosure: AI coding agents (Claude Opus 5.5 and GPT 6.1 Sol) wrote most of the code, tests, and documentation under my direction. The source code and every test report, including failures, are public. Features Pick the lowest-latency server or search the full list, with ping, load, and saved favorites. Android supports split tunneling and Always-on VPN. On Linux, AirVPN verifies that your IPv4, IPv6, and DNS traffic go through the tunnel. Linux includes a Network Lock firewall that stays active until you turn it off, a recovery button, and an Eddie account importer. The app contains no analytics or telemetry. It talks only to AirVPN. The client supports WireGuard only. Sign-in details. Sign in with your AirVPN username and password. The app uses the same encrypted protocol as Eddie, so you do not need to generate an API key. Your device encrypts your credentials using Android Keystore or your Linux desktop keyring, and sends them only to AirVPN. Comparison with Eddie Eddie handles many tasks, and Wave relies on Eddie's published protocol implementation. Wave takes a different approach: The interface uses Jetpack Compose on Android and Rust on Linux, centered on a single Connect control. The settings include only basic WireGuard options and sensible defaults. On Linux, the app runs as an unprivileged user while a dedicated helper executes a fixed list of network commands. The firewall rules stay active if the main process exits unexpectedly. Every test report is public, including runs that failed. The Linux version can import your saved Eddie account. Eddie supports OpenVPN, Windows, macOS, and advanced routing options. If you need those options, use Eddie. Known issue Android reminder: Android can leak DNS during VPN reconnects or app crashes, even with Always-on VPN and blocking enabled, as documented by Mullvad. I also observed this in my Samsung tests. Links Android source Linux source Release key: 4140 18C0 BBB8 C0A7 0A80 BF57 0AA3 2CCB 2C0B 3951 (verified on keys.openpgp.org) Bugs and feedback Bug reports: open a GitHub issue on the Android or Linux repository. Include the app version, operating system version, and reproduction steps. General questions: post in this thread. Security disclosures: email vesselwave@protonmail.com. Do not post passwords, private keys, or WireGuard configuration files. I maintain this project in my spare time and respond as schedule permits. Thanks for trying it! ♡
-
-
-
Oooh almost forgot it. Thanks, just got my 3 year renewal. 👻 I'm regularly checking prices for a year now, as far as I can tell Halloween sale is the best, you should get it now, otherwise you have to wait a year. Easter or birthday sale did not have such a big discount iirc.
-
-
Hi everyone, Quick heads-up: Disney Channels and Disney+ are blocked from the Mirfak server and cannot be accessed there at the moment. Switching to the AirVPN DNS does not help yet. thanks for re Routing!
-
Hi AirVPN Staff, You have various promotions throughout the year. When is your best promotion? I am asking so I can plan my three-year renewal accordingly. Thanks,
-
-
ANSWERED Eddie stuck on trying to connect
Den7is replied to Nitrox's topic in Troubleshooting and Problems
-
how to set a fixed local port for OpenVPN and WireGuard?
Staff replied to schwede's topic in Eddie - AirVPN Client
@schwede Hello! The "nobind" line does not seem to come from the base directives, which would explain why removing it there or switching between "Append" and "Use only Custom directives" changes nothing. Eddie adds it by itself while it builds the configuration. If no network interface is selected for the connection, it would append "nobind". If one is selected, it would write "local" followed by the IP address of that interface instead. That would also explain why the line has no level comment in the preview. A solution should already exist, worth a try. In the custom directives, a directive name preceded by a minus sign will remove that directive from the final configuration and the custom directives appear to be applied after the "nobind" above. So you could try putting these two lines in Settings > OpenVPN directives, custom directives, in either mode: -nobind lport 1194 "lport" implies "bind", so "bind" should not be needed. Before connecting, you could check the result with right click on a server > More: "nobind" should be gone and "lport 1194" should be there. An alternative might be to select your LAN interface or IP in Settings > Networking (interface used for the connection): Eddie should then write "local" followed by your IP address instead of "nobind", and "lport 1194" in the custom directives should bind to that address and port. In this case, however, the preview under More would probably still show "nobind", because the interface seems to be resolved only at connection time, so the first method would be easier to verify. WireGuard: as far as we can see, Eddie currently has no option for the local port (ListenPort), so the port would be chosen randomly at each connection. By the way, a firewall that can make an exception only for a fixed local source port, and not for the remote address or port of the traffic, is highly unusual. Firewalls and traffic filters normally match outgoing UDP flows on the destination, which here would be the AirVPN entry IP addresses and ports, and that would cover both OpenVPN and WireGuard without touching the local port at all. Could you tell us which firewall or filter this is (product, model and version, or software and version) and, if possible, how the rule is configured? There might be a simpler way to solve the problem on that side. Please let us know whether the OpenVPN solution works for you. Kind regards -
how to set a fixed local port for OpenVPN and WireGuard?
Tech Jedi Alex replied to schwede's topic in Eddie - AirVPN Client
Cannot reproduce. Set mode to Only use custom directives, remove nobind on the right and add bind to the left, save, and nobild becomes bind. This on Linux, using v2.27.2. Can any other Windows user reproduce schwede's finding? Don't run in circles now. Setting Custom mode removes it if it's removed from the built-in directives. That, on the other hand, is not possible. Custom directives are only supported for OpenVPN for now, unfortunately. So #3 may be forwarded to the dev. -
ANSWERED Immediate Crash: X Connection to :0 broken
Staff replied to voidfactory's topic in Eddie - AirVPN Client
@voidfactory Thank you, the log you attached is exactly what was needed, and it shows the cause precisely. First, a quick picture of the pieces involved. niri is your Wayland compositor which draws and manages every window on your desktop. Eddie UI (like Discord) is an X11 application, and niri does not talk X11 itself: X11 applications run through xwayland-satellite, a bridge that starts Xwayland, acts as the X11 window manager towards those applications and presents each X11 window to niri as a normal Wayland window. All your X11 applications share that single bridge and its single connection to niri. When you activate Network Lock, Eddie opens a small dialog window. That window declares a minimum height of -5 pixels in its X11 size hints (WM_NORMAL_HINTS: min_size 102x-5). xwayland-satellite passes this value unchanged to the compositor as the Wayland minimum size, and the Wayland protocol (xdg_toplevel.set_min_size) forbids negative values: niri answers with a protocol error, the connection is closed and xwayland-satellite panics in the same second: Since every X11 application goes through that same bridge, all of them lose their display at that moment, which is why Discord goes down too, and eddie-tray then segfaults (the core dump you found) as a consequence. niri itself keeps running and quietly restarts xwayland-satellite, without telling anyone that it has just crashed: no notification, no warning, just a fresh bridge where the old one used to be, in the best tradition of a strict code of silence. The only visible symptom is your X11 applications vanishing all at once, and nobody saw anything. In other words, a single window asking to be at least minus five pixels tall is enough to take down every X11 application on your desktop: quite a lot of power for a negative number. So this is neither a permissions problem nor the Mesa issue we mentioned earlier, which is why updating xwayland-satellite did not help. Two things are wrong here: the negative value in that Eddie dialog, which we will report to the Eddie developers, and xwayland-satellite crashing on it instead of ignoring or clamping it. A regular Xwayland or X11 session tolerates such a hint, which is why the problem appears only under xwayland-satellite. If you like, you can report it to the xwayland-satellite project with the lines above: https://github.com/Supreeeme/xwayland-satellite/issues Until one of the two is fixed, on niri please use one of the options that do not need X at all, both with Network Lock: - Eddie CLI edition (eddie-cli) - AirVPN Suite (Bluetit daemon and Goldcrest client): https://airvpn.org/linux/suite/ About video playback on Viki and WeTV: it is not related to this crash. If it happens only while connected to the VPN, please try a few different servers and let us know. Kind regards -
DNSSEC tests fail when connected to sites thru Eddie
Staff replied to Baryshnikov's topic in DNS Lists
Hello, yes, this is expected. When you are connected through Eddie, your DNS queries go to the DNS resolver of the VPN server you are connected to, and this resolver does not perform DNSSEC validation. dnscheck.tools checks whether your resolver rejects records with invalid or missing signatures; ours does not, while Quad9 and Cloudflare do, hence the different results. This is intentional. Our resolvers modify some answers on purpose: the block lists and custom answers you can configure on the DNS page of the Client Area, the OpenNIC TLDs and some names used by our own services. Altering answers is exactly what DNSSEC is designed to detect and reject, so DNSSEC validation would break these features. DNSSEC validation is not strictly necessary while you are connected to the VPN. Between your device and our resolver, queries and answers travel inside the encrypted tunnel, so they cannot be forged by your local network or by your ISP. Moreover, for connections protected by TLS, such as HTTPS, a forged answer leads to a certificate error, not to a silent redirection. If you want DNSSEC validation anyway, you can run your own validating recursive resolver (for example Unbound) and let its queries go through the VPN tunnel. Please note that it must resolve recursively by itself: if it forwards queries to our resolver, validation will fail, because our resolver does not return DNSSEC signatures. You would also lose our block lists, custom answers and OpenNIC resolution. Kind regards -
-
-
-
-
-
For some weird reasons the airvpn ip torrent leak test works only when I use TCP. I have the same issue with all torrents too. I can't really use "all interface" on windows qbittorrent because I do need and use split routes for my tailscale and it has its own interface. Any possible explanations? I have never seen this specific problem with other providers. Just curious.
-
-
-
Hey foiks, I work at a security company and the other week I found a ClickFix phishing page on a parked page ad network. While digging into it I realised the parked page had pretty aggressive network based fingerprinting. Very few of the servers in the route check seem to reach. https://airvpn.org/routes/?q=https://whoi.is Is there an official programatic way of checking these? We'd like to automate choosing the most reliable exits, and it would be nice to filter the exit nodes easier than blind retrying and hoping for the best
-
-
ANSWERED Immediate Crash: X Connection to :0 broken
voidfactory replied to voidfactory's topic in Eddie - AirVPN Client
Fascinating! I've put the results of the command into a text file, as it is very long. The relevant part should be at the bottom since I queried right after clicking on the Network Lock option. Before doing all that, I did install and replace the xwayland-satellite version on the system with the -git version via yay. It is xwayland-satellite-git 0.8.3.r14.g7bf5e0d-1 I've also reinstalled the latest Mesa drivers, but they were already installed. Querying pacman -Qs gives me this list: local/glu 9.0.3-3.1 Mesa OpenGL utility library local/lib32-mesa 3:26.2.4-1 Open-source OpenGL drivers - 32-bit local/lib32-opencl-mesa 3:26.2.4-1 Open-source OpenCL drivers - 32-bit local/lib32-vulkan-mesa-implicit-layers 3:26.2.4-1 Mesa's implicit Vulkan layers - 32-bit local/mesa 3:26.2.4-1 Open-source OpenGL drivers local/mesa-utils 9.0.0-7.1 Essential Mesa utilities local/opencl-mesa 3:26.2.4-1 Open-source OpenCL drivers local/vulkan-mesa-implicit-layers 3:26.2.4-1 Mesa's implicit Vulkan layers glxinfo | grep Mesa gives me the following client glx vendor string: Mesa Project and SGI OpenGL core profile version string: 4.6 (Core Profile) Mesa 26.2.4-arch3.1 OpenGL version string: 4.6 (Compatibility Profile) Mesa 26.2.4-arch3.1 OpenGL ES profile version string: OpenGL ES 3.2 Mesa 26.2.4-arch3.1 There is only one version of eddie-ui installed, which is the -git version. Since these seem to also affect OpenGL, I've also experiencing video playback issues for these last three weeks on certain streaming sites (Viki, WeTV). Could these issues actually be related? Or am I way off base there? It affects every browser, and even happens on my EndeavorOS Laptop, also using Niri and DUX Shell. Disregard if unrelated. Best erroroutput.txt -
DNSSEC tests fail when connected to sites thru Eddie
Treading6603 replied to Baryshnikov's topic in DNS Lists
I have the same question too. -
ANSWERED Immediate Crash: X Connection to :0 broken
Staff replied to voidfactory's topic in Eddie - AirVPN Client
Hello! Discord crashing at the same moment is the key detail: the X server itself is going away, not only Eddie. Eddie's UI is an X11 (Mono WinForms) application, so on Niri it runs through xwayland-satellite, like Discord. "X connection to :0 broken (explicit kill or server shutdown)" is what every X11 client prints when that server disappears, and the Mono SIGSEGV in your second message is most likely Eddie dying after it lost its display. It is not a permissions issue: elevation through pkexec worked and the privileged part started correctly. The trigger is consistent: activating Network Lock. Eddie keeps the Network Lock state in its profile folder and applies it again at the next start, so the same step runs at every launch until you delete ~/.config/eddie. You don't need to delete it: just make sure Network Lock is off before closing Eddie, and the next start will be clean. Important: if Eddie crashes while Network Lock is active, the firewall rules stay in place by design (that's what prevents leaks), so you may have no connectivity afterwards. Start Eddie again and deactivate Network Lock, or check the rules with: sudo nft list ruleset To see which process actually crashes, please run this right after a crash and post the output: coredumpctl list --since "10 min ago" journalctl --user -b --since "10 min ago" | grep -i -E "xwayland|satellite" If xwayland-satellite shows up there, the problem is on the compositor side. Niri users have reported random crashes with exactly this message, fixed by updating xwayland-satellite (the -git version) or, in some cases, by going back to an older Mesa release: https://github.com/niri-wm/niri/issues/3199 Please also tell us your xwayland-satellite and Mesa versions. If you can, a quick test in a session with standard Xwayland (Plasma or GNOME) would confirm it: if Network Lock works there, Eddie's firewall part is fine. About leftovers: the different Eddie builds share only the profile folder ~/.config/eddie, and the AppImage is self-contained. Just check that a single Eddie package is installed: pacman -Qs eddie In the meantime, two options that do not need X at all, both with Network Lock: - Eddie CLI edition (eddie-cli) - AirVPN Suite (Bluetit daemon and Goldcrest client): https://airvpn.org/linux/suite/ Kind regards
