amnezia-vpn/amnezia-client

Fork 0

mirror of https://github.com/amnezia-vpn/amnezia-client.git synced 2026-10-15 13:52:15 +00:00

[GH-ISSUE #3125] [Selfhosted][Linux Mint] No traffic after connection established LIKELY AFTER kernel and package updates #1448

New issue

Open

opened 2026-10-13 20:42:39 +00:00 by bsakaguchi · 9 comments

bsakaguchi commented

2026-10-13 20:42:39 +00:00

Owner

Originally created by @jhaoda on GitHub (Sep 4, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3125

Describe the bug
AmneziaVPN 5.0.0.5 and 5.0.2.0 stopped working on Linux Mint 22.3 with XRay and AmneziaWG 3.1 protocols, LIKELY AFTER kernel and package updates.

The application successfully establishes a VPN connection (creates a tun2 interface and shows "Connected" status), but traffic does not pass through the tunnel. At the same time, on Linux Mint 22.2, Windows 11, and Android 15, the same version of the application works correctly with the same XRay protocol settings.

To Reproduce
Steps to reproduce the behavior:

Install Linux Mint 22.3 (x86_64) with updates described below
Install AmneziaVPN version 5.0.0.5 or 5.0.2.0
Configure connection using XRay protocol
Click "Connect" button
Wait for "Connected" status
Try to open any website or run ping 1.1.1.1
Observe no network traffic through VPN

Expected behavior
Websites and ping should work through the VPN connection

Log files

[2026-09-04 14:23:34.148Z] [WARNING] Amnezia  : Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: Connection already associated with an application ID")
[2026-09-04 14:23:34.148Z] [DEBUG] Amnezia  : Logger::setServiceLogsEnabled(): Logs transitioned to be  enabled
[2026-09-04 14:23:34.148Z] [DEBUG] Amnezia  : Updated website URL: "https://amnezia.org"
[2026-09-04 14:23:34.267Z] [INFO] Amnezia  : Started AmneziaVPN version 5.0.0.5 4d28f81
[2026-09-04 14:23:34.267Z] [INFO] Amnezia  : Linux Mint 22.3 (x86_64)
[2026-09-04 14:23:35.211Z] [ERROR] Amnezia  : CryptoUtils::decryptAes256Cbc EVP_DecryptFinal_ex failed: "error:1C80006B:Provider routines::wrong final block length"
[2026-09-04 14:23:35.211Z] [DEBUG] Amnezia  : failed to decrypt the data
[2026-09-04 14:23:37.707Z] [DEBUG] Amnezia  : "Trying to connect to VPN, server id is 04f8f469-4d22-4d81-8ee9-ab9262bba9e3, container is amnezia-xray, route mode is" amnezia::route_mode_ns::VpnOnlyForwardSites
[2026-09-04 14:23:37.707Z] [DEBUG] Amnezia  : "Site split tunneling is disabled, route mode is 0"
[2026-09-04 14:23:37.707Z] [DEBUG] Amnezia  : "App split tunneling is disabled, route mode is 0"
[2026-09-04 14:23:37.708Z] [DEBUG] Amnezia  : XrayProtocol::start()
[2026-09-04 14:23:37.733Z] [DEBUG] Amnezia  : [tun2socks]: "{\"level\":\"info\",\"ts\":1788531817.7326808,\"caller\":\"engine/engine.go:237\",\"msg\":\"[STACK] tun://tun2 <-> socks5://127.0.0.1:41873\"}\n"
[2026-09-04 14:23:37.770Z] [DEBUG] Amnezia  : VpnProtocol::setConnectionState "Connected"
[2026-09-04 14:23:37.771Z] [DEBUG] Amnezia  : Connection state: 'Connected'
[2026-09-04 14:23:37.885Z] [DEBUG] Amnezia  : VpnConnection::onConnectionStateChanged: Successfully flushed DNS
[2026-09-04 14:23:37.886Z] [DEBUG] Amnezia  : [tun2socks]: ""
... over three thousand such lines in a row

[2026-09-04 14:23:42.934Z] [WARNING] Amnezia  : QIODevice::read (QNetworkReplyHttpImpl): device not open
[2026-09-04 14:23:42.934Z] [ERROR] Amnezia  : CryptoUtils::decryptAes256Cbc EVP_DecryptFinal_ex failed: "error:1C80006B:Provider routines::wrong final block length"
[2026-09-04 14:23:42.934Z] [DEBUG] Amnezia  : QNetworkReply::TimeoutError
[2026-09-04 14:23:42.934Z] [ERROR] Amnezia UpdateController : Gateway request failed, error code: 1103
[2026-09-04 14:23:42.948Z] [DEBUG] Amnezia  : [tun2socks]: ""
... several hundred more such lines

... here I clicked "Disconnect".

[2026-09-04 14:24:26.413Z] [DEBUG] Amnezia  : XrayProtocol::stop()
[2026-09-04 14:24:27.747Z] [WARNING] Amnezia  : Failed to delete tun
[2026-09-04 14:24:28.063Z] [DEBUG] Amnezia  : VpnProtocol::setConnectionState "Disconnected"
[2026-09-04 14:24:28.063Z] [DEBUG] Amnezia  : Connection state: 'Disconnected'
[2026-09-04 14:24:28.204Z] [DEBUG] Amnezia  : VpnConnection::onConnectionStateChanged: Successfully flushed DNS
[2026-09-04 14:24:28.204Z] [WARNING] Amnezia  : "Reconnect triggered on Disconnecting during inappropriate state: %2; ignoring slot"
[2026-09-04 14:24:28.204Z] [WARNING] Amnezia  : VpnConnection::onConnectionStateChanged: Failed to clear saved routes
[2026-09-04 14:24:28.204Z] [DEBUG] Amnezia  : XrayProtocol::~XrayProtocol()
[2026-09-04 14:24:28.204Z] [DEBUG] Amnezia  : XrayProtocol::stop()
[2026-09-04 14:24:29.542Z] [WARNING] Amnezia  : Failed to delete tun
[2026-09-04 14:24:29.542Z] [WARNING] Amnezia  : Failed to stop xray
[2026-09-04 14:24:29.542Z] [DEBUG] Amnezia  : VpnProtocol::setConnectionState "Disconnected"
[2026-09-04 14:24:31.256Z] [DEBUG] Amnezia  : VpnConnection::onConnectionStateChanged: Successfully flushed DNS
[2026-09-04 14:24:31.256Z] [DEBUG] Amnezia  : VpnConnection::onConnectionStateChanged: Successfully cleared saved routes

On the machine with Linux Mint 22.2, the log looks similar, except for one line:

[2026-09-04 10:19:21.462Z] [DEBUG] Amnezia  : "Site split tunneling is disabled, route mode is 0"
[2026-09-04 10:19:21.462Z] [DEBUG] Amnezia  : "App split tunneling is disabled, route mode is 0"
[2026-09-04 10:19:21.462Z] [DEBUG] Amnezia  : Gateway  10.10.10.1  for interface  wlp0s20f3 <<<---------
[2026-09-04 10:19:21.462Z] [DEBUG] Amnezia  : XrayProtocol::start()

Desktop (please complete the following information):

Linux Mint 22.3

Additional context
The following packages were updated:
Вот список пакетов, отсортированный по алфавиту, в формате Markdown:

containerd.io (2.3.4-1~ubuntu.24.04~noble → 2.3.4-2~ubuntu.24.04~noble)
dirmngr (2.4.4-2ubuntu17.4 → 2.4.4-2ubuntu17.6)
docker-buildx-plugin (0.36.1-1~ubuntu.24.04~noble → 0.37.0-1~ubuntu.24.04~noble)
docker-ce (5:29.7.2-1~ubuntu.24.04~noble → 5:29.8.0-1~ubuntu.24.04~noble)
docker-ce-cli (5:29.7.2-1~ubuntu.24.04~noble → 5:29.8.0-1~ubuntu.24.04~noble)
docker-ce-rootless-extras (5:29.7.2-1~ubuntu.24.04~noble → 5:29.8.0-1~ubuntu.24.04~noble)
docker-compose-plugin (5.5.0-1~ubuntu.24.04~noble → 5.5.1-1~ubuntu.24.04~noble)
firefox (154.0.1+linuxmint1+zena → 155.0+linuxmint1+zena)
firefox-locale-en (154.0.1+linuxmint1+zena → 155.0+linuxmint1+zena)
firefox-locale-ru (154.0.1+linuxmint1+zena → 155.0+linuxmint1+zena)
gnupg (2.4.4-2ubuntu17.4 → 2.4.4-2ubuntu17.6)
gnupg-utils (2.4.4-2ubuntu17.4 → 2.4.4-2ubuntu17.6)
gnupg2 (2.4.4-2ubuntu17.4 → 2.4.4-2ubuntu17.6)
google-chrome-stable (152.0.7977.64-1 → 152.0.7977.82-1)
gpg (2.4.4-2ubuntu17.4 → 2.4.4-2ubuntu17.6)
gpg-agent (2.4.4-2ubuntu17.4 → 2.4.4-2ubuntu17.6)
gpgconf (2.4.4-2ubuntu17.4 → 2.4.4-2ubuntu17.6)
gpgsm (2.4.4-2ubuntu17.4 → 2.4.4-2ubuntu17.6)
gpgv (2.4.4-2ubuntu17.4 → 2.4.4-2ubuntu17.6)
keyboxd (2.4.4-2ubuntu17.4 → 2.4.4-2ubuntu17.6)
libgcrypt20 (1.10.3-2ubuntu0.1 → 1.10.3-2ubuntu0.2)
libssh2-1t64 (1.11.0-4.1ubuntu0.24.04.3 → 1.11.0-4.1ubuntu0.24.04.4)
linux-firmware (20240318.git3b128b60-0ubuntu2.29 → 20240318.git3b128b60.0ubuntu3.1)
linux-firmware-amd-graphics (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.2)
linux-firmware-amd-misc (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-broadcom-wireless (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-intel-graphics (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-intel-misc (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-intel-wireless (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-marvell-prestera (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-marvell-wireless (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-mediatek (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-mellanox-spectrum (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-misc (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-netronome (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-nvidia-graphics (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-qlogic (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-qualcomm-graphics (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-qualcomm-misc (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-qualcomm-wireless (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-firmware-realtek (20240318.git3b128b60-0ubuntu3.1 → 20240318.git3b128b60-0ubuntu3.1)
linux-generic-hwe-24.04 (7.0.0-30.30~24.04.1 → 7.0.0-31.31~24.04.1)
linux-headers-7.0.0-31-generic (7.0.0-31.31~24.04.1 → 7.0.0-31.31~24.04.1)
linux-headers-generic-hwe-24.04 (7.0.0-30.30~24.04.1 → 7.0.0-31.31~24.04.1)
linux-hwe-7.0-headers-7.0.0-31 (7.0.0-31.31~24.04.1 → 7.0.0-31.31~24.04.1)
linux-hwe-7.0-tools-7.0.0-31 (7.0.0-31.31~24.04.1 → 7.0.0-31.31~24.04.1)
linux-image-7.0.0-31-generic (7.0.0-31.31~24.04.1 → 7.0.0-31.31~24.04.1)
linux-image-generic-hwe-24.04 (7.0.0-30.30~24.04.1 → 7.0.0-31.31~24.04.1)
linux-modules-7.0.0-31-generic (7.0.0-31.31~24.04.1 → 7.0.0-31.31~24.04.1)
linux-tools-7.0.0-31-generic (7.0.0-31.31~24.04.1 → 7.0.0-31.31~24.04.1)
openssh-client (1:9.6p1-3ubuntu13.18 → 1:9.6p1-3ubuntu13.19)

How likely is it that the issue is caused by the updates? What other information should I provide to more knowledgeable specialists?

Originally created by @jhaoda on GitHub (Sep 4, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3125 **Describe the bug** AmneziaVPN 5.0.0.5 and 5.0.2.0 stopped working on Linux Mint 22.3 with XRay and AmneziaWG 3.1 protocols, LIKELY AFTER kernel and package updates. The application successfully establishes a VPN connection (creates a tun2 interface and shows "Connected" status), but traffic does not pass through the tunnel. At the same time, on Linux Mint 22.2, Windows 11, and Android 15, the same version of the application works correctly with the same XRay protocol settings. **To Reproduce** Steps to reproduce the behavior: 1. Install Linux Mint 22.3 (x86_64) with updates described below 2. Install AmneziaVPN version 5.0.0.5 or 5.0.2.0 3. Configure connection using XRay protocol 4. Click "Connect" button 5. Wait for "Connected" status 6. Try to open any website or run ping 1.1.1.1 7. Observe no network traffic through VPN **Expected behavior** Websites and ping should work through the VPN connection **Log files** ``` [2026-09-04 14:23:34.148Z] [WARNING] Amnezia : Failed to register with host portal QDBusError("org.freedesktop.portal.Error.Failed", "Could not register app ID: Connection already associated with an application ID") [2026-09-04 14:23:34.148Z] [DEBUG] Amnezia : Logger::setServiceLogsEnabled(): Logs transitioned to be enabled [2026-09-04 14:23:34.148Z] [DEBUG] Amnezia : Updated website URL: "https://amnezia.org" [2026-09-04 14:23:34.267Z] [INFO] Amnezia : Started AmneziaVPN version 5.0.0.5 4d28f81 [2026-09-04 14:23:34.267Z] [INFO] Amnezia : Linux Mint 22.3 (x86_64) [2026-09-04 14:23:35.211Z] [ERROR] Amnezia : CryptoUtils::decryptAes256Cbc EVP_DecryptFinal_ex failed: "error:1C80006B:Provider routines::wrong final block length" [2026-09-04 14:23:35.211Z] [DEBUG] Amnezia : failed to decrypt the data [2026-09-04 14:23:37.707Z] [DEBUG] Amnezia : "Trying to connect to VPN, server id is 04f8f469-4d22-4d81-8ee9-ab9262bba9e3, container is amnezia-xray, route mode is" amnezia::route_mode_ns::VpnOnlyForwardSites [2026-09-04 14:23:37.707Z] [DEBUG] Amnezia : "Site split tunneling is disabled, route mode is 0" [2026-09-04 14:23:37.707Z] [DEBUG] Amnezia : "App split tunneling is disabled, route mode is 0" [2026-09-04 14:23:37.708Z] [DEBUG] Amnezia : XrayProtocol::start() [2026-09-04 14:23:37.733Z] [DEBUG] Amnezia : [tun2socks]: "{\"level\":\"info\",\"ts\":1788531817.7326808,\"caller\":\"engine/engine.go:237\",\"msg\":\"[STACK] tun://tun2 <-> socks5://127.0.0.1:41873\"}\n" [2026-09-04 14:23:37.770Z] [DEBUG] Amnezia : VpnProtocol::setConnectionState "Connected" [2026-09-04 14:23:37.771Z] [DEBUG] Amnezia : Connection state: 'Connected' [2026-09-04 14:23:37.885Z] [DEBUG] Amnezia : VpnConnection::onConnectionStateChanged: Successfully flushed DNS [2026-09-04 14:23:37.886Z] [DEBUG] Amnezia : [tun2socks]: "" ... over three thousand such lines in a row [2026-09-04 14:23:42.934Z] [WARNING] Amnezia : QIODevice::read (QNetworkReplyHttpImpl): device not open [2026-09-04 14:23:42.934Z] [ERROR] Amnezia : CryptoUtils::decryptAes256Cbc EVP_DecryptFinal_ex failed: "error:1C80006B:Provider routines::wrong final block length" [2026-09-04 14:23:42.934Z] [DEBUG] Amnezia : QNetworkReply::TimeoutError [2026-09-04 14:23:42.934Z] [ERROR] Amnezia UpdateController : Gateway request failed, error code: 1103 [2026-09-04 14:23:42.948Z] [DEBUG] Amnezia : [tun2socks]: "" ... several hundred more such lines ... here I clicked "Disconnect". [2026-09-04 14:24:26.413Z] [DEBUG] Amnezia : XrayProtocol::stop() [2026-09-04 14:24:27.747Z] [WARNING] Amnezia : Failed to delete tun [2026-09-04 14:24:28.063Z] [DEBUG] Amnezia : VpnProtocol::setConnectionState "Disconnected" [2026-09-04 14:24:28.063Z] [DEBUG] Amnezia : Connection state: 'Disconnected' [2026-09-04 14:24:28.204Z] [DEBUG] Amnezia : VpnConnection::onConnectionStateChanged: Successfully flushed DNS [2026-09-04 14:24:28.204Z] [WARNING] Amnezia : "Reconnect triggered on Disconnecting during inappropriate state: %2; ignoring slot" [2026-09-04 14:24:28.204Z] [WARNING] Amnezia : VpnConnection::onConnectionStateChanged: Failed to clear saved routes [2026-09-04 14:24:28.204Z] [DEBUG] Amnezia : XrayProtocol::~XrayProtocol() [2026-09-04 14:24:28.204Z] [DEBUG] Amnezia : XrayProtocol::stop() [2026-09-04 14:24:29.542Z] [WARNING] Amnezia : Failed to delete tun [2026-09-04 14:24:29.542Z] [WARNING] Amnezia : Failed to stop xray [2026-09-04 14:24:29.542Z] [DEBUG] Amnezia : VpnProtocol::setConnectionState "Disconnected" [2026-09-04 14:24:31.256Z] [DEBUG] Amnezia : VpnConnection::onConnectionStateChanged: Successfully flushed DNS [2026-09-04 14:24:31.256Z] [DEBUG] Amnezia : VpnConnection::onConnectionStateChanged: Successfully cleared saved routes ``` On the machine with Linux Mint 22.2, the log looks similar, except for one line: ``` [2026-09-04 10:19:21.462Z] [DEBUG] Amnezia : "Site split tunneling is disabled, route mode is 0" [2026-09-04 10:19:21.462Z] [DEBUG] Amnezia : "App split tunneling is disabled, route mode is 0" [2026-09-04 10:19:21.462Z] [DEBUG] Amnezia : Gateway 10.10.10.1 for interface wlp0s20f3 <<<--------- [2026-09-04 10:19:21.462Z] [DEBUG] Amnezia : XrayProtocol::start() ``` **Desktop (please complete the following information):** - Linux Mint 22.3 **Additional context** The following packages were updated: Вот список пакетов, отсортированный по алфавиту, в формате Markdown: - `containerd.io` (`2.3.4-1~ubuntu.24.04~noble` → `2.3.4-2~ubuntu.24.04~noble`) - `dirmngr` (`2.4.4-2ubuntu17.4` → `2.4.4-2ubuntu17.6`) - `docker-buildx-plugin` (`0.36.1-1~ubuntu.24.04~noble` → `0.37.0-1~ubuntu.24.04~noble`) - `docker-ce` (`5:29.7.2-1~ubuntu.24.04~noble` → `5:29.8.0-1~ubuntu.24.04~noble`) - `docker-ce-cli` (`5:29.7.2-1~ubuntu.24.04~noble` → `5:29.8.0-1~ubuntu.24.04~noble`) - `docker-ce-rootless-extras` (`5:29.7.2-1~ubuntu.24.04~noble` → `5:29.8.0-1~ubuntu.24.04~noble`) - `docker-compose-plugin` (`5.5.0-1~ubuntu.24.04~noble` → `5.5.1-1~ubuntu.24.04~noble`) - `firefox` (`154.0.1+linuxmint1+zena` → `155.0+linuxmint1+zena`) - `firefox-locale-en` (`154.0.1+linuxmint1+zena` → `155.0+linuxmint1+zena`) - `firefox-locale-ru` (`154.0.1+linuxmint1+zena` → `155.0+linuxmint1+zena`) - `gnupg` (`2.4.4-2ubuntu17.4` → `2.4.4-2ubuntu17.6`) - `gnupg-utils` (`2.4.4-2ubuntu17.4` → `2.4.4-2ubuntu17.6`) - `gnupg2` (`2.4.4-2ubuntu17.4` → `2.4.4-2ubuntu17.6`) - `google-chrome-stable` (`152.0.7977.64-1` → `152.0.7977.82-1`) - `gpg` (`2.4.4-2ubuntu17.4` → `2.4.4-2ubuntu17.6`) - `gpg-agent` (`2.4.4-2ubuntu17.4` → `2.4.4-2ubuntu17.6`) - `gpgconf` (`2.4.4-2ubuntu17.4` → `2.4.4-2ubuntu17.6`) - `gpgsm` (`2.4.4-2ubuntu17.4` → `2.4.4-2ubuntu17.6`) - `gpgv` (`2.4.4-2ubuntu17.4` → `2.4.4-2ubuntu17.6`) - `keyboxd` (`2.4.4-2ubuntu17.4` → `2.4.4-2ubuntu17.6`) - `libgcrypt20` (`1.10.3-2ubuntu0.1` → `1.10.3-2ubuntu0.2`) - `libssh2-1t64` (`1.11.0-4.1ubuntu0.24.04.3` → `1.11.0-4.1ubuntu0.24.04.4`) - `linux-firmware` (`20240318.git3b128b60-0ubuntu2.29` → `20240318.git3b128b60.0ubuntu3.1`) - `linux-firmware-amd-graphics` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.2`) - `linux-firmware-amd-misc` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-broadcom-wireless` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-intel-graphics` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-intel-misc` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-intel-wireless` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-marvell-prestera` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-marvell-wireless` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-mediatek` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-mellanox-spectrum` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-misc` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-netronome` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-nvidia-graphics` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-qlogic` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-qualcomm-graphics` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-qualcomm-misc` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-qualcomm-wireless` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-firmware-realtek` (`20240318.git3b128b60-0ubuntu3.1` → `20240318.git3b128b60-0ubuntu3.1`) - `linux-generic-hwe-24.04` (`7.0.0-30.30~24.04.1` → `7.0.0-31.31~24.04.1`) - `linux-headers-7.0.0-31-generic` (`7.0.0-31.31~24.04.1` → `7.0.0-31.31~24.04.1`) - `linux-headers-generic-hwe-24.04` (`7.0.0-30.30~24.04.1` → `7.0.0-31.31~24.04.1`) - `linux-hwe-7.0-headers-7.0.0-31` (`7.0.0-31.31~24.04.1` → `7.0.0-31.31~24.04.1`) - `linux-hwe-7.0-tools-7.0.0-31` (`7.0.0-31.31~24.04.1` → `7.0.0-31.31~24.04.1`) - `linux-image-7.0.0-31-generic` (`7.0.0-31.31~24.04.1` → `7.0.0-31.31~24.04.1`) - `linux-image-generic-hwe-24.04` (`7.0.0-30.30~24.04.1` → `7.0.0-31.31~24.04.1`) - `linux-modules-7.0.0-31-generic` (`7.0.0-31.31~24.04.1` → `7.0.0-31.31~24.04.1`) - `linux-tools-7.0.0-31-generic` (`7.0.0-31.31~24.04.1` → `7.0.0-31.31~24.04.1`) - `openssh-client` (`1:9.6p1-3ubuntu13.18` → `1:9.6p1-3ubuntu13.19`) How likely is it that the issue is caused by the updates? What other information should I provide to more knowledgeable specialists?

bsakaguchi commented

2026-10-13 20:42:40 +00:00

Author

Owner

@Roman-Romanov97 commented on GitHub (Sep 4, 2026):

i have a same problem

@Roman-Romanov97 commented on GitHub (Sep 4, 2026): i have a same problem

bsakaguchi commented

2026-10-13 20:42:40 +00:00

Author

Owner

@HeisLuka commented on GitHub (Sep 8, 2026):

This looks very likely related to #3090 / #3052 rather than to one particular Mint/kernel package.

The most interesting difference in the report is:

working Mint 22.2:
Gateway 10.10.10.1 for interface wlp0s20f3

failing Mint 22.3:
<no Gateway ... line>

Current dev still uses the fixed-size Linux implementation of:

NetworkUtilities::getGatewayAndIface()

with:

constexpr int BUFFER_SIZE = 8192;

and accumulates the complete RTM_GETROUTE multipart dump into that buffer.

#3090 already has a confirmed reproduction where a sufficiently large route table causes exactly this lookup to return no gateway/interface. PR #3052 addresses that by parsing netlink datagrams incrementally instead of depending on a fixed total dump size.

A very quick way to confirm whether #3125 is the same failure would be to compare:

ip -4 route show table all | wc -l
ip -6 route show table all | wc -l

on the working Mint 22.2 and failing Mint 22.3 installations.

Also useful before connecting:

ip route get

There is another correctness issue in the current XRay startup path that makes this failure appear as Connected.

On Linux, Xray::startXray() does:

gatewayAndIface = NetworkUtilities::getGatewayAndIface();
m_defaultIfaceName = defaultIface.name().toUtf8();

but an empty interface is not treated as startup failure.

The socket callback only installs:

SO_BINDTODEVICE
SO_MARK

when m_defaultIfaceName is non-empty.

So the current state machine can become:

default gateway discovery failed
-> XRay starts anyway
-> XRay sockets are not bound/marked for physical underlay
-> tun2socks starts
-> routing setup completes
-> UI reports Connected
-> actual data path is unusable

That suggests two independent fixes:

A. Fix getGatewayAndIface()
(#3052 removes the fixed netlink-dump limit)

B. Do not treat missing required underlay identity as
successful XRay full-tunnel startup

In other words, on Linux:

XRAY_CONNECTED
=>
physical uplink discovered
AND XRay outbound sockets have the required underlay binding/mark
AND tunnel routing setup succeeded

not merely:

xray process started
AND tun2socks stack started

I would add two regression cases:

Synthetic route table whose netlink dump is > 8 KiB

expected:
gateway/interface still discovered
XRay underlay binding installed
connection may reach Connected

and:

No usable default gateway exists

expected:
explicit retry/error/readiness state

forbidden:
empty uplink
+ unbound XRay sockets
+ Connected

This would also make the UI symptom much less misleading even for gateway-discovery failures unrelated to the fixed-buffer bug.

If the route counts on the Mint 22.3 machine are above the #3090 threshold, I think this issue can probably be treated as another reproduction of the same root cause.

@HeisLuka commented on GitHub (Sep 8, 2026): This looks very likely related to #3090 / #3052 rather than to one particular Mint/kernel package. The most interesting difference in the report is: working Mint 22.2: Gateway 10.10.10.1 for interface wlp0s20f3 failing Mint 22.3: <no Gateway ... line> Current dev still uses the fixed-size Linux implementation of: NetworkUtilities::getGatewayAndIface() with: constexpr int BUFFER_SIZE = 8192; and accumulates the complete RTM_GETROUTE multipart dump into that buffer. #3090 already has a confirmed reproduction where a sufficiently large route table causes exactly this lookup to return no gateway/interface. PR #3052 addresses that by parsing netlink datagrams incrementally instead of depending on a fixed total dump size. A very quick way to confirm whether #3125 is the same failure would be to compare: ip -4 route show table all | wc -l ip -6 route show table all | wc -l on the working Mint 22.2 and failing Mint 22.3 installations. Also useful before connecting: ip route get <xray-server-ip> There is another correctness issue in the current XRay startup path that makes this failure appear as Connected. On Linux, Xray::startXray() does: gatewayAndIface = NetworkUtilities::getGatewayAndIface(); m_defaultIfaceName = defaultIface.name().toUtf8(); but an empty interface is not treated as startup failure. The socket callback only installs: SO_BINDTODEVICE SO_MARK when m_defaultIfaceName is non-empty. So the current state machine can become: default gateway discovery failed -> XRay starts anyway -> XRay sockets are not bound/marked for physical underlay -> tun2socks starts -> routing setup completes -> UI reports Connected -> actual data path is unusable That suggests two independent fixes: A. Fix getGatewayAndIface() (#3052 removes the fixed netlink-dump limit) B. Do not treat missing required underlay identity as successful XRay full-tunnel startup In other words, on Linux: XRAY_CONNECTED => physical uplink discovered AND XRay outbound sockets have the required underlay binding/mark AND tunnel routing setup succeeded not merely: xray process started AND tun2socks stack started I would add two regression cases: 1. Synthetic route table whose netlink dump is > 8 KiB expected: gateway/interface still discovered XRay underlay binding installed connection may reach Connected and: 2. No usable default gateway exists expected: explicit retry/error/readiness state forbidden: empty uplink + unbound XRay sockets + Connected This would also make the UI symptom much less misleading even for gateway-discovery failures unrelated to the fixed-buffer bug. If the route counts on the Mint 22.3 machine are above the #3090 threshold, I think this issue can probably be treated as another reproduction of the same root cause.

bsakaguchi commented

2026-10-13 20:42:41 +00:00

Author

Owner

@jhaoda commented on GitHub (Sep 9, 2026):

@HeisLuka

A very quick way to confirm whether https://github.com/amnezia-vpn/amnezia-client/issues/3125 is the same failure would be to compare
ip -4 route show table all | wc -l
ip -6 route show table all | wc -l

~$ ip -4 route show table all | wc -l
19 # Mint 22.2
29 # Mint 22.3

~$ ip -6 route show table all | wc -l
0 # on both machines

~$ ip route get 
need at least a destination address # on both machines

@jhaoda commented on GitHub (Sep 9, 2026): @HeisLuka > A very quick way to confirm whether https://github.com/amnezia-vpn/amnezia-client/issues/3125 is the same failure would be to compare > ip -4 route show table all | wc -l > ip -6 route show table all | wc -l ```bash ~$ ip -4 route show table all | wc -l 19 # Mint 22.2 29 # Mint 22.3 ~$ ip -6 route show table all | wc -l 0 # on both machines ~$ ip route get need at least a destination address # on both machines ```

bsakaguchi commented

2026-10-13 20:42:42 +00:00

Author

Owner

@HeisLuka commented on GitHub (Sep 9, 2026):

Thanks — the route counts change the picture quite a bit.

With 29 IPv4 routes and no IPv6 routes on Mint 22.3, the specific >8 KiB overflow reproduced in #3090 is unlikely to be the cause here. However, the missing

Gateway ... for interface ...

line still strongly suggests that NetworkUtilities::getGatewayAndIface() is returning an empty gateway/interface.

There is another suspicious property of the current netlink receive loop that does not require a large route table: after each recv() it checks only the first nlmsghdr in that received datagram for NLMSG_DONE / NLMSG_ERROR, and only parses all headers later. A netlink datagram may contain multiple nlmsghdr messages, including NLMSG_DONE after route messages. If the kernel's batching differs between the two systems, the current loop can potentially miss the terminator and continue into a timeout/failure even though the dump is well below 8 KiB. #3052's incremental per-datagram parsing would remove this failure mode as well, independently of the buffer-overflow fix.

Could you please capture the following before connecting Amnezia, on both the working Mint 22.2 machine and the failing Mint 22.3 machine?

ip -4 route show table main
ip -4 route show table all
ip rule show
ip -4 route show default

And one more command using the actual IP address of the XRay server as the destination, for example:

ip route get 203.0.113.10

Replace 203.0.113.10 with the real XRay server IP.

My previous <xray-server-ip> placeholder appears to have been swallowed by GitHub's rendered Markdown, which is why copying the rendered command resulted in just ip route get.

The comparison should tell us whether:

Mint 22.3 represents/selects the default route differently, or
the route is perfectly normal and the failure is inside Amnezia's netlink parsing.

If the route tables look equivalent, testing a build with #3052 would be especially useful even though this machine is below the #3090 overflow threshold.

@HeisLuka commented on GitHub (Sep 9, 2026): Thanks — the route counts change the picture quite a bit. With 29 IPv4 routes and no IPv6 routes on Mint 22.3, the specific >8 KiB overflow reproduced in #3090 is unlikely to be the cause here. However, the missing ```bash Gateway ... for interface ... ``` line still strongly suggests that `NetworkUtilities::getGatewayAndIface()` is returning an empty gateway/interface. There is another suspicious property of the current netlink receive loop that does **not** require a large route table: after each `recv()` it checks only the first `nlmsghdr` in that received datagram for `NLMSG_DONE` / `NLMSG_ERROR`, and only parses all headers later. A netlink datagram may contain multiple `nlmsghdr` messages, including `NLMSG_DONE` after route messages. If the kernel's batching differs between the two systems, the current loop can potentially miss the terminator and continue into a timeout/failure even though the dump is well below 8 KiB. #3052's incremental per-datagram parsing would remove this failure mode as well, independently of the buffer-overflow fix. Could you please capture the following **before connecting Amnezia**, on both the working Mint 22.2 machine and the failing Mint 22.3 machine? ```bash ip -4 route show table main ip -4 route show table all ip rule show ip -4 route show default ``` And one more command using the **actual IP address of the XRay server** as the destination, for example: ```bash ip route get 203.0.113.10 ``` Replace `203.0.113.10` with the real XRay server IP. My previous `<xray-server-ip>` placeholder appears to have been swallowed by GitHub's rendered Markdown, which is why copying the rendered command resulted in just `ip route get`. The comparison should tell us whether: 1. Mint 22.3 represents/selects the default route differently, or 2. the route is perfectly normal and the failure is inside Amnezia's netlink parsing. If the route tables look equivalent, testing a build with #3052 would be especially useful even though this machine is below the #3090 overflow threshold.

bsakaguchi commented

2026-10-13 20:42:42 +00:00

Author

Owner

@jhaoda commented on GitHub (Sep 9, 2026):

@HeisLuka

Mint 22.3 (non-working)

~$ ip -4 route show table main
default via 10.10.10.1 dev wlp194s0 proto dhcp src 10.10.10.12 metric 600 
10.10.10.0/24 dev wlp194s0 proto kernel scope link src 10.10.10.12 metric 600 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1 
172.19.0.0/16 dev br-249c888de607 proto kernel scope link src 172.19.0.1 

~$ ip -4 route show table all
default via 10.10.10.1 dev wlp194s0 proto dhcp src 10.10.10.12 metric 600 
10.10.10.0/24 dev wlp194s0 proto kernel scope link src 10.10.10.12 metric 600 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1 
172.19.0.0/16 dev br-249c888de607 proto kernel scope link src 172.19.0.1 
local 10.10.10.12 dev wlp194s0 table local proto kernel scope host src 10.10.10.12 
broadcast 10.10.10.255 dev wlp194s0 table local proto kernel scope link src 10.10.10.12 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1 
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1 
local 172.18.0.1 dev docker_gwbridge table local proto kernel scope host src 172.18.0.1 
broadcast 172.18.255.255 dev docker_gwbridge table local proto kernel scope link src 172.18.0.1 
local 172.19.0.1 dev br-249c888de607 table local proto kernel scope host src 172.19.0.1 
broadcast 172.19.255.255 dev br-249c888de607 table local proto kernel scope link src 172.19.0.1

~$ ip rule show
0:	from all lookup local
32766:	from all lookup main
32767:	from all lookup default

~$ ip -4 route show default
default via 10.10.10.1 dev wlp194s0 proto dhcp src 10.10.10.12 metric 600

Mint 22.2 (working)

~$ ip -4 route show table main
default via 10.10.10.1 dev wlp0s20f3 proto dhcp src 10.10.10.2 metric 600 
10.10.10.0/24 dev wlp0s20f3 proto kernel scope link src 10.10.10.2 metric 600 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1 
172.19.0.0/16 dev br-a5d7ac249a41 proto kernel scope link src 172.19.0.1 linkdown 
172.20.0.0/16 dev br-e6c4a11a3cfa proto kernel scope link src 172.20.0.1 linkdown

~$ ip -4 route show table all
default via 10.10.10.1 dev wlp0s20f3 proto dhcp src 10.10.10.2 metric 600 
10.10.10.0/24 dev wlp0s20f3 proto kernel scope link src 10.10.10.2 metric 600 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 
172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1 
172.19.0.0/16 dev br-a5d7ac249a41 proto kernel scope link src 172.19.0.1 linkdown 
172.20.0.0/16 dev br-e6c4a11a3cfa proto kernel scope link src 172.20.0.1 linkdown 
192.168.1.0/24 dev enp43s0 proto kernel scope link src 192.168.1.1 metric 100 
local 10.10.10.2 dev wlp0s20f3 table local proto kernel scope host src 10.10.10.2 
broadcast 10.10.10.255 dev wlp0s20f3 table local proto kernel scope link src 10.10.10.2 
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 
local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1 
broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1 
local 172.18.0.1 dev docker_gwbridge table local proto kernel scope host src 172.18.0.1 
broadcast 172.18.255.255 dev docker_gwbridge table local proto kernel scope link src 172.18.0.1 
local 172.19.0.1 dev br-a5d7ac249a41 table local proto kernel scope host src 172.19.0.1 
broadcast 172.19.255.255 dev br-a5d7ac249a41 table local proto kernel scope link src 172.19.0.1 linkdown 
local 172.20.0.1 dev br-e6c4a11a3cfa table local proto kernel scope host src 172.20.0.1 
broadcast 172.20.255.255 dev br-e6c4a11a3cfa table local proto kernel scope link src 172.20.0.1 linkdown

~$ ip rule show
0:  from all lookup local
32766:  from all lookup main
32767:  from all lookup default

~$ ip -4 route show default
default via 10.10.10.1 dev wlp0s20f3 proto dhcp src 10.10.10.2 metric 600

And one more command using the actual IP address of the XRay server as the destination

# Amnezia not connected
~$ ip route get <XRay server IP>
<XRay server IP> via 10.10.10.1 dev wlp194s0 src 10.10.10.12 uid 1000 # Mint 22.3
<XRay server IP> via 10.10.10.1 dev wlp0s20f3 src 10.10.10.2 uid 1000 # Mint 22.2
    cache

# Amnezia connected, both machines, even on Mint 22.3
~$ ip route get <XRay server IP>
<XRay server IP> dev tun2 src 10.33.0.2 uid 1000
    cache

@jhaoda commented on GitHub (Sep 9, 2026): @HeisLuka Mint 22.3 (non-working) ```bash ~$ ip -4 route show table main default via 10.10.10.1 dev wlp194s0 proto dhcp src 10.10.10.12 metric 600 10.10.10.0/24 dev wlp194s0 proto kernel scope link src 10.10.10.12 metric 600 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1 172.19.0.0/16 dev br-249c888de607 proto kernel scope link src 172.19.0.1 ~$ ip -4 route show table all default via 10.10.10.1 dev wlp194s0 proto dhcp src 10.10.10.12 metric 600 10.10.10.0/24 dev wlp194s0 proto kernel scope link src 10.10.10.12 metric 600 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1 172.19.0.0/16 dev br-249c888de607 proto kernel scope link src 172.19.0.1 local 10.10.10.12 dev wlp194s0 table local proto kernel scope host src 10.10.10.12 broadcast 10.10.10.255 dev wlp194s0 table local proto kernel scope link src 10.10.10.12 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1 broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1 local 172.18.0.1 dev docker_gwbridge table local proto kernel scope host src 172.18.0.1 broadcast 172.18.255.255 dev docker_gwbridge table local proto kernel scope link src 172.18.0.1 local 172.19.0.1 dev br-249c888de607 table local proto kernel scope host src 172.19.0.1 broadcast 172.19.255.255 dev br-249c888de607 table local proto kernel scope link src 172.19.0.1 ~$ ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default ~$ ip -4 route show default default via 10.10.10.1 dev wlp194s0 proto dhcp src 10.10.10.12 metric 600 ``` Mint 22.2 (working) ```bash ~$ ip -4 route show table main default via 10.10.10.1 dev wlp0s20f3 proto dhcp src 10.10.10.2 metric 600 10.10.10.0/24 dev wlp0s20f3 proto kernel scope link src 10.10.10.2 metric 600 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1 172.19.0.0/16 dev br-a5d7ac249a41 proto kernel scope link src 172.19.0.1 linkdown 172.20.0.0/16 dev br-e6c4a11a3cfa proto kernel scope link src 172.20.0.1 linkdown ~$ ip -4 route show table all default via 10.10.10.1 dev wlp0s20f3 proto dhcp src 10.10.10.2 metric 600 10.10.10.0/24 dev wlp0s20f3 proto kernel scope link src 10.10.10.2 metric 600 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 172.18.0.0/16 dev docker_gwbridge proto kernel scope link src 172.18.0.1 172.19.0.0/16 dev br-a5d7ac249a41 proto kernel scope link src 172.19.0.1 linkdown 172.20.0.0/16 dev br-e6c4a11a3cfa proto kernel scope link src 172.20.0.1 linkdown 192.168.1.0/24 dev enp43s0 proto kernel scope link src 192.168.1.1 metric 100 local 10.10.10.2 dev wlp0s20f3 table local proto kernel scope host src 10.10.10.2 broadcast 10.10.10.255 dev wlp0s20f3 table local proto kernel scope link src 10.10.10.2 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 local 172.17.0.1 dev docker0 table local proto kernel scope host src 172.17.0.1 broadcast 172.17.255.255 dev docker0 table local proto kernel scope link src 172.17.0.1 local 172.18.0.1 dev docker_gwbridge table local proto kernel scope host src 172.18.0.1 broadcast 172.18.255.255 dev docker_gwbridge table local proto kernel scope link src 172.18.0.1 local 172.19.0.1 dev br-a5d7ac249a41 table local proto kernel scope host src 172.19.0.1 broadcast 172.19.255.255 dev br-a5d7ac249a41 table local proto kernel scope link src 172.19.0.1 linkdown local 172.20.0.1 dev br-e6c4a11a3cfa table local proto kernel scope host src 172.20.0.1 broadcast 172.20.255.255 dev br-e6c4a11a3cfa table local proto kernel scope link src 172.20.0.1 linkdown ~$ ip rule show 0: from all lookup local 32766: from all lookup main 32767: from all lookup default ~$ ip -4 route show default default via 10.10.10.1 dev wlp0s20f3 proto dhcp src 10.10.10.2 metric 600 ``` --- > And one more command using the actual IP address of the XRay server as the destination ```bash # Amnezia not connected ~$ ip route get <XRay server IP> <XRay server IP> via 10.10.10.1 dev wlp194s0 src 10.10.10.12 uid 1000 # Mint 22.3 <XRay server IP> via 10.10.10.1 dev wlp0s20f3 src 10.10.10.2 uid 1000 # Mint 22.2 cache # Amnezia connected, both machines, even on Mint 22.3 ~$ ip route get <XRay server IP> <XRay server IP> dev tun2 src 10.33.0.2 uid 1000 cache ```

bsakaguchi commented

2026-10-13 20:42:42 +00:00

Author

Owner

@HeisLuka commented on GitHub (Sep 9, 2026):

Thanks, this is very useful.

The new data makes the system routing itself look normal on both machines:

before connecting, the XRay server is reached via the physical Wi-Fi gateway;
the default route and policy rules are essentially equivalent;
after connecting, ip route get <XRay server IP> points to tun2 on both machines.

So the important difference still seems to be inside Amnezia: on Mint 22.3 NetworkUtilities::getGatewayAndIface() appears to return an empty uplink even though the kernel route is perfectly valid.

That would also explain the XRay symptom: if m_defaultIfaceName is empty, the XRay socket callback does not apply SO_BINDTODEVICE / SO_MARK, but XRay is still allowed to start and the client can reach Connected.

At this point the >8 KiB overflow from #3090 looks unlikely, but the current netlink receive loop still has another possible failure mode: it checks NLMSG_DONE / NLMSG_ERROR only on the first nlmsghdr returned by each recv(). If Mint 22.3 batches route messages and NLMSG_DONE differently, the function could miss the terminator and fail even with a small route table.

#3052 parses every nlmsghdr in every received datagram, so it should also eliminate that failure mode.

If possible, could you test a Linux build with #3052 on the Mint 22.3 machine?

The most useful result would be whether this line comes back:

Gateway 10.10.10.1 for interface wlp194s0

and whether XRay traffic starts working again.

If that happens, #3125 would be a very strong reproduction of the same getGatewayAndIface() parser problem, but through netlink message batching rather than the 8 KiB overflow.

@HeisLuka commented on GitHub (Sep 9, 2026): Thanks, this is very useful. The new data makes the system routing itself look normal on both machines: * before connecting, the XRay server is reached via the physical Wi-Fi gateway; * the default route and policy rules are essentially equivalent; * after connecting, `ip route get <XRay server IP>` points to `tun2` on **both** machines. So the important difference still seems to be inside Amnezia: on Mint 22.3 `NetworkUtilities::getGatewayAndIface()` appears to return an empty uplink even though the kernel route is perfectly valid. That would also explain the XRay symptom: if `m_defaultIfaceName` is empty, the XRay socket callback does not apply `SO_BINDTODEVICE` / `SO_MARK`, but XRay is still allowed to start and the client can reach `Connected`. At this point the >8 KiB overflow from #3090 looks unlikely, but the current netlink receive loop still has another possible failure mode: it checks `NLMSG_DONE` / `NLMSG_ERROR` only on the first `nlmsghdr` returned by each `recv()`. If Mint 22.3 batches route messages and `NLMSG_DONE` differently, the function could miss the terminator and fail even with a small route table. #3052 parses every `nlmsghdr` in every received datagram, so it should also eliminate that failure mode. If possible, could you test a Linux build with #3052 on the Mint 22.3 machine? The most useful result would be whether this line comes back: ```text Gateway 10.10.10.1 for interface wlp194s0 ``` and whether XRay traffic starts working again. If that happens, #3125 would be a very strong reproduction of the same `getGatewayAndIface()` parser problem, but through netlink message batching rather than the 8 KiB overflow.

bsakaguchi commented

2026-10-13 20:42:43 +00:00

Author

Owner

@jhaoda commented on GitHub (Sep 9, 2026):

@HeisLuka sorry, but I don't have the knowledge to build app.

@jhaoda commented on GitHub (Sep 9, 2026): @HeisLuka sorry, but I don't have the knowledge to build app.

bsakaguchi commented

2026-10-13 20:42:43 +00:00

Author

Owner

@jhaoda commented on GitHub (Sep 10, 2026):

@izhddm hmm, it's very interesting. Yesterday ip -6 route show table all | wc -l showed 0, and today it shows 68.

Yes, it's buffer overflow:

~$ python network.py
kernel            : 7.0.0-31-generic
routes v4 / v6    : 16 / 68
datagrams received: 3, bytes accumulated: 8192 of 8192
RESULT            : FAILS -> daemon logs "No default gateway available"
reason            : recv() returned 0 because the remaining buffer space was 0 bytes -> NLMSG_OK fails -> perror("Error in received packet") -> empty result

I disabled IPv6 in the Docker daemon config, stopped Docker, restarted NetworkManager, started Docker, and the number of routes dropped from 72 to 68, but that's still a lot.

ip -6 route show table all

fe80::/64 dev br-249c888de607 proto kernel metric 256 pref medium
fe80::/64 dev docker_gwbridge proto kernel metric 256 pref medium
fe80::/64 dev docker0 proto kernel metric 256 linkdown pref medium
fe80::/64 dev veth3fa3e4b proto kernel metric 256 pref medium
fe80::/64 dev vethaf8e782 proto kernel metric 256 pref medium
fe80::/64 dev vethcb6f9f0 proto kernel metric 256 pref medium
fe80::/64 dev vethe46f1a9 proto kernel metric 256 pref medium
fe80::/64 dev vethcbae635 proto kernel metric 256 pref medium
fe80::/64 dev veth88a05fd proto kernel metric 256 pref medium
fe80::/64 dev veth4ee78dd proto kernel metric 256 pref medium
fe80::/64 dev veth6202d6c proto kernel metric 256 pref medium
fe80::/64 dev vethf3fd50c proto kernel metric 256 pref medium
fe80::/64 dev veth90c6d9c proto kernel metric 256 pref medium
fe80::/64 dev veth3fb9c4c proto kernel metric 256 pref medium
fe80::/64 dev veth5bbc72e proto kernel metric 256 pref medium
fe80::/64 dev veth9e3b45d proto kernel metric 256 pref medium
fe80::/64 dev veth0c558a3 proto kernel metric 256 pref medium
fe80::/64 dev veth053a09c proto kernel metric 256 pref medium
fe80::/64 dev veth930d350 proto kernel metric 256 pref medium
fe80::/64 dev vetha4657b5 proto kernel metric 256 pref medium
fe80::/64 dev veth61a872c proto kernel metric 256 pref medium
fe80::/64 dev wlp194s0 proto kernel metric 1024 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::803:c6ff:fe41:8e91 dev veth053a09c table local proto kernel metric 0 pref medium
local fe80::c1e:c3ff:fe92:f50e dev veth90c6d9c table local proto kernel metric 0 pref medium
local fe80::1445:19ff:fefe:824d dev vethaf8e782 table local proto kernel metric 0 pref medium
local fe80::2461:80ff:fedf:2449 dev veth3fb9c4c table local proto kernel metric 0 pref medium
local fe80::24f1:3aff:fe47:feb1 dev veth930d350 table local proto kernel metric 0 pref medium
local fe80::3413:f8ff:fea5:87de dev docker0 table local proto kernel metric 0 pref medium
local fe80::3468:33ff:fe36:e64d dev vetha4657b5 table local proto kernel metric 0 pref medium
local fe80::3488:43ff:fe99:f8ef dev veth9e3b45d table local proto kernel metric 0 pref medium
local fe80::3825:9cff:fe43:b78e dev docker_gwbridge table local proto kernel metric 0 pref medium
local fe80::48c0:4fff:fefa:8ec4 dev veth61a872c table local proto kernel metric 0 pref medium
local fe80::645b:7fff:fef4:9e0d dev veth5bbc72e table local proto kernel metric 0 pref medium
local fe80::64d9:e0ff:fe44:65ad dev veth88a05fd table local proto kernel metric 0 pref medium
local fe80::78c8:23ff:fe2f:e769 dev vethcb6f9f0 table local proto kernel metric 0 pref medium
local fe80::8819:64ff:fe9c:6070 dev veth6202d6c table local proto kernel metric 0 pref medium
local fe80::9887:45ff:fee7:21b dev veth3fa3e4b table local proto kernel metric 0 pref medium
local fe80::a875:5bff:fedd:8cc3 dev veth0c558a3 table local proto kernel metric 0 pref medium
local fe80::c27d:93a6:19c1:e392 dev wlp194s0 table local proto kernel metric 0 pref medium
local fe80::cc5e:22ff:fe9f:a271 dev vethe46f1a9 table local proto kernel metric 0 pref medium
local fe80::dc4a:f3ff:fe7f:74f1 dev veth4ee78dd table local proto kernel metric 0 pref medium
local fe80::e4cb:39ff:fe98:a7d0 dev vethcbae635 table local proto kernel metric 0 pref medium
local fe80::ec88:81ff:fe75:bed6 dev vethf3fd50c table local proto kernel metric 0 pref medium
local fe80::f0d3:38ff:fe31:5e3d dev br-249c888de607 table local proto kernel metric 0 pref medium
multicast ff00::/8 dev br-249c888de607 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev docker_gwbridge table local proto kernel metric 256 pref medium
multicast ff00::/8 dev docker0 table local proto kernel metric 256 linkdown pref medium
multicast ff00::/8 dev wlp194s0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth3fa3e4b table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vethaf8e782 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vethcb6f9f0 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vethe46f1a9 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vethcbae635 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth88a05fd table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth4ee78dd table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth6202d6c table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vethf3fd50c table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth90c6d9c table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth3fb9c4c table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth5bbc72e table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth9e3b45d table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth0c558a3 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth053a09c table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth930d350 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev vetha4657b5 table local proto kernel metric 256 pref medium
multicast ff00::/8 dev veth61a872c table local proto kernel metric 256 pref medium
multicast ff00::/8 dev enp195s0 table local proto kernel metric 256 pref medium

On the machine with Min 22.2 the situation is as follows:

routes v4 / v6    : 16 / 68
datagrams received: 3, bytes accumulated: 8072 of 8192

I suspect I'm one step away from Amnezia possibly stopping working on this machine too, if I deploy something else in Docker?

@jhaoda commented on GitHub (Sep 10, 2026): @izhddm hmm, it's very interesting. Yesterday `ip -6 route show table all | wc -l` showed 0, and today it shows 68. Yes, it's buffer overflow: ```bash ~$ python network.py kernel : 7.0.0-31-generic routes v4 / v6 : 16 / 68 datagrams received: 3, bytes accumulated: 8192 of 8192 RESULT : FAILS -> daemon logs "No default gateway available" reason : recv() returned 0 because the remaining buffer space was 0 bytes -> NLMSG_OK fails -> perror("Error in received packet") -> empty result ``` I disabled IPv6 in the Docker daemon config, stopped Docker, restarted NetworkManager, started Docker, and the number of routes dropped from 72 to 68, but that's still a lot. <details> <summary>ip -6 route show table all</summary> ```bash fe80::/64 dev br-249c888de607 proto kernel metric 256 pref medium fe80::/64 dev docker_gwbridge proto kernel metric 256 pref medium fe80::/64 dev docker0 proto kernel metric 256 linkdown pref medium fe80::/64 dev veth3fa3e4b proto kernel metric 256 pref medium fe80::/64 dev vethaf8e782 proto kernel metric 256 pref medium fe80::/64 dev vethcb6f9f0 proto kernel metric 256 pref medium fe80::/64 dev vethe46f1a9 proto kernel metric 256 pref medium fe80::/64 dev vethcbae635 proto kernel metric 256 pref medium fe80::/64 dev veth88a05fd proto kernel metric 256 pref medium fe80::/64 dev veth4ee78dd proto kernel metric 256 pref medium fe80::/64 dev veth6202d6c proto kernel metric 256 pref medium fe80::/64 dev vethf3fd50c proto kernel metric 256 pref medium fe80::/64 dev veth90c6d9c proto kernel metric 256 pref medium fe80::/64 dev veth3fb9c4c proto kernel metric 256 pref medium fe80::/64 dev veth5bbc72e proto kernel metric 256 pref medium fe80::/64 dev veth9e3b45d proto kernel metric 256 pref medium fe80::/64 dev veth0c558a3 proto kernel metric 256 pref medium fe80::/64 dev veth053a09c proto kernel metric 256 pref medium fe80::/64 dev veth930d350 proto kernel metric 256 pref medium fe80::/64 dev vetha4657b5 proto kernel metric 256 pref medium fe80::/64 dev veth61a872c proto kernel metric 256 pref medium fe80::/64 dev wlp194s0 proto kernel metric 1024 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local fe80::803:c6ff:fe41:8e91 dev veth053a09c table local proto kernel metric 0 pref medium local fe80::c1e:c3ff:fe92:f50e dev veth90c6d9c table local proto kernel metric 0 pref medium local fe80::1445:19ff:fefe:824d dev vethaf8e782 table local proto kernel metric 0 pref medium local fe80::2461:80ff:fedf:2449 dev veth3fb9c4c table local proto kernel metric 0 pref medium local fe80::24f1:3aff:fe47:feb1 dev veth930d350 table local proto kernel metric 0 pref medium local fe80::3413:f8ff:fea5:87de dev docker0 table local proto kernel metric 0 pref medium local fe80::3468:33ff:fe36:e64d dev vetha4657b5 table local proto kernel metric 0 pref medium local fe80::3488:43ff:fe99:f8ef dev veth9e3b45d table local proto kernel metric 0 pref medium local fe80::3825:9cff:fe43:b78e dev docker_gwbridge table local proto kernel metric 0 pref medium local fe80::48c0:4fff:fefa:8ec4 dev veth61a872c table local proto kernel metric 0 pref medium local fe80::645b:7fff:fef4:9e0d dev veth5bbc72e table local proto kernel metric 0 pref medium local fe80::64d9:e0ff:fe44:65ad dev veth88a05fd table local proto kernel metric 0 pref medium local fe80::78c8:23ff:fe2f:e769 dev vethcb6f9f0 table local proto kernel metric 0 pref medium local fe80::8819:64ff:fe9c:6070 dev veth6202d6c table local proto kernel metric 0 pref medium local fe80::9887:45ff:fee7:21b dev veth3fa3e4b table local proto kernel metric 0 pref medium local fe80::a875:5bff:fedd:8cc3 dev veth0c558a3 table local proto kernel metric 0 pref medium local fe80::c27d:93a6:19c1:e392 dev wlp194s0 table local proto kernel metric 0 pref medium local fe80::cc5e:22ff:fe9f:a271 dev vethe46f1a9 table local proto kernel metric 0 pref medium local fe80::dc4a:f3ff:fe7f:74f1 dev veth4ee78dd table local proto kernel metric 0 pref medium local fe80::e4cb:39ff:fe98:a7d0 dev vethcbae635 table local proto kernel metric 0 pref medium local fe80::ec88:81ff:fe75:bed6 dev vethf3fd50c table local proto kernel metric 0 pref medium local fe80::f0d3:38ff:fe31:5e3d dev br-249c888de607 table local proto kernel metric 0 pref medium multicast ff00::/8 dev br-249c888de607 table local proto kernel metric 256 pref medium multicast ff00::/8 dev docker_gwbridge table local proto kernel metric 256 pref medium multicast ff00::/8 dev docker0 table local proto kernel metric 256 linkdown pref medium multicast ff00::/8 dev wlp194s0 table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth3fa3e4b table local proto kernel metric 256 pref medium multicast ff00::/8 dev vethaf8e782 table local proto kernel metric 256 pref medium multicast ff00::/8 dev vethcb6f9f0 table local proto kernel metric 256 pref medium multicast ff00::/8 dev vethe46f1a9 table local proto kernel metric 256 pref medium multicast ff00::/8 dev vethcbae635 table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth88a05fd table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth4ee78dd table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth6202d6c table local proto kernel metric 256 pref medium multicast ff00::/8 dev vethf3fd50c table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth90c6d9c table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth3fb9c4c table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth5bbc72e table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth9e3b45d table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth0c558a3 table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth053a09c table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth930d350 table local proto kernel metric 256 pref medium multicast ff00::/8 dev vetha4657b5 table local proto kernel metric 256 pref medium multicast ff00::/8 dev veth61a872c table local proto kernel metric 256 pref medium multicast ff00::/8 dev enp195s0 table local proto kernel metric 256 pref medium ``` </details> --- On the machine with Min 22.2 the situation is as follows: ```bash routes v4 / v6 : 16 / 68 datagrams received: 3, bytes accumulated: 8072 of 8192 ``` I suspect I'm one step away from Amnezia possibly stopping working on this machine too, if I deploy something else in Docker?

bsakaguchi commented

2026-10-13 20:42:43 +00:00

Author

Owner

@jhaoda commented on GitHub (Sep 10, 2026):

Yep, I deleted a couple of Docker stacks on Mint 22.3 and Amnezia started working!

@izhddm @HeisLuka Huge thanks for the help, guys, I would never have looked into routing!

@jhaoda commented on GitHub (Sep 10, 2026): Yep, I deleted a couple of Docker stacks on Mint 22.3 and Amnezia started working! @izhddm @HeisLuka Huge thanks for the help, guys, I would never have looked into routing!

bsakaguchi referenced this issue

2026-10-13 21:21:15 +00:00

[PR #1448] [MERGED] fix: iOS/iPadOS crashes on a start of the app because of there's no k… #2356