amnezia-vpn/amneziawg-linux-kernel-module

Fork 0

mirror of https://github.com/amnezia-vpn/amneziawg-linux-kernel-module.git synced 2026-10-14 05:41:56 +00:00

[GH-ISSUE #215] Regression after amneziawg-dkms 202608051436+ce16310 → 202608140352+4680320: handshake succeeds but no data transfer (Keenetic client) #124

New issue

Open

opened 2026-10-13 21:06:48 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-13 21:06:48 +00:00

Owner

Originally created by @sefferito on GitHub (Aug 15, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/215

Environment

Server: Ubuntu 24.04.4 LTS, kernel 6.8.0-137-generic, x86_64
Package: amneziawg-dkms (from ppa:amnezia/ppa)
Client: Keenetic Sprinter KN-3710, KeeneticOS 5.2 Alpha 5, native NDMS WireGuard client (not amneziawg-go)
Deployment: bivlked/amneziawg-installer (kernel-module, non-Docker)

Summary

After amneziawg-dkms updated from 1.0.0-0~202608051436+ce16310~ubuntu24.04.1 to 1.0.0-0~202608140352+4680320~ubuntu24.04.1 (server reboot to apply), the tunnel to a Keenetic router client stopped passing data. This is a clean regression: the older build (ce16310) had been running without any issue for 9 days prior.

Symptom

Handshake completes periodically (~every 3 minutes), server shows a fresh latest handshake timestamp
No data flows afterward in either direction — server-side transfer counter for that peer stays frozen indefinitely even while sent bytes on the client keep growing
Client-side (Keenetic) log shows repeated handshake ... did not complete after N seconds, retrying messages, some with clearly invalid/overflowed N values (this display artifact is a separately-acknowledged Keenetic cosmetic bug, not something I'm claiming is caused by this module — flagging only for context, since it shows up alongside the real symptom)
The same server/port/obfuscation-config is fully reachable and passes real traffic when connected directly from a different network path (mobile carrier, different client peer) — rules out a server-wide outage or firewall issue
Recreating the affected client peer from scratch (fresh keypair) reproduces the identical symptom
Changing I1 (tried <r 128>, <r 64>, and a QUIC-mimicry CPS packet) made no difference

Timing

ce16310 build: installed ~2026-08-05, stable through 2026-08-14 (9 days, no issues)
4680320 build: installed and activated via reboot at 2026-08-14 23:57 UTC
First failed-handshake log line on the client: 2026-08-15 02:57:33 (client is UTC+3) — i.e. within the same minute as the server reboot
Symptom has been continuous since, with 1000+ retry log lines in the following ~10 hours

#30 (same garbled-seconds log pattern on a Keenetic client, though that report describes brief hourly drops rather than a sustained regression tied to a specific update)

Not yet tested

Have not been able to obtain the ce16310 build for a clean A/B rollback test (not available via apt-cache policy, not cached locally, and I haven't located it in the PPA's build history). If anyone knows how to pull a specific historical build from the amnezia PPA, that would let me confirm definitively.

Originally created by @sefferito on GitHub (Aug 15, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amneziawg-linux-kernel-module/issues/215 ## Environment - Server: Ubuntu 24.04.4 LTS, kernel 6.8.0-137-generic, x86_64 - Package: amneziawg-dkms (from ppa:amnezia/ppa) - Client: Keenetic Sprinter KN-3710, KeeneticOS 5.2 Alpha 5, native NDMS WireGuard client (not amneziawg-go) - Deployment: bivlked/amneziawg-installer (kernel-module, non-Docker) ## Summary After amneziawg-dkms updated from `1.0.0-0~202608051436+ce16310~ubuntu24.04.1` to `1.0.0-0~202608140352+4680320~ubuntu24.04.1` (server reboot to apply), the tunnel to a Keenetic router client stopped passing data. This is a clean regression: the older build (ce16310) had been running without any issue for 9 days prior. ## Symptom - Handshake completes periodically (~every 3 minutes), server shows a fresh `latest handshake` timestamp - No data flows afterward in either direction — server-side `transfer` counter for that peer stays frozen indefinitely even while sent bytes on the client keep growing - Client-side (Keenetic) log shows repeated `handshake ... did not complete after N seconds, retrying` messages, some with clearly invalid/overflowed N values (this display artifact is a separately-acknowledged Keenetic cosmetic bug, not something I'm claiming is caused by this module — flagging only for context, since it shows up alongside the real symptom) - The same server/port/obfuscation-config is fully reachable and passes real traffic when connected directly from a different network path (mobile carrier, different client peer) — rules out a server-wide outage or firewall issue - Recreating the affected client peer from scratch (fresh keypair) reproduces the identical symptom - Changing I1 (tried `<r 128>`, `<r 64>`, and a QUIC-mimicry CPS packet) made no difference ## Timing - ce16310 build: installed ~2026-08-05, stable through 2026-08-14 (9 days, no issues) - 4680320 build: installed and activated via reboot at 2026-08-14 23:57 UTC - First failed-handshake log line on the client: 2026-08-15 02:57:33 (client is UTC+3) — i.e. within the same minute as the server reboot - Symptom has been continuous since, with 1000+ retry log lines in the following ~10 hours ## Possibly related #30 (same garbled-seconds log pattern on a Keenetic client, though that report describes brief hourly drops rather than a sustained regression tied to a specific update) ## Not yet tested Have not been able to obtain the ce16310 build for a clean A/B rollback test (not available via apt-cache policy, not cached locally, and I haven't located it in the PPA's build history). If anyone knows how to pull a specific historical build from the amnezia PPA, that would let me confirm definitively.

bsakaguchi commented

2026-10-13 21:06:48 +00:00

Author

Owner

@bivlked commented on GitHub (Aug 24, 2026):

I maintain the installer this server was deployed with, so I tried to reproduce this on a box that matches yours closely. I could not. But I did find something that changes what the two builds in your title are.

They are different module generations. I installed each one and read what the loaded module reports:

dkms build	published	`/sys/module/amneziawg/version`
`1.0.0-0~202608051436+ce16310`	5 Aug	`3.0.20260805`
`1.0.0-0~202608122133+0d5f03c`	12 Aug	`3.0.20260805`
`1.0.0-0~202608140352+4680320`	14 Aug	`3.1.20260812`

So the update you bisected to is not a rebuild of the same code, it is the 3.0 to 3.1 transition. I installed the intermediate 12 Aug build as well, expecting the boundary to sit earlier, and it does not: that one is still 3.0. The generation flip lands exactly on 4680320, the build your symptom started on. If anyone here suggests downgrading, note that it rolls the generation back too, and the package version string gives no hint of that.

Getting those old builds, since you said you could not. Launchpad keeps superseded binaries downloadable:

https://launchpad.net/~amnezia/+archive/ubuntu/ppa/+files/amneziawg-dkms_<version>_all.deb

The package is architecture independent, so it is _all.deb; _amd64.deb gives 404. Version strings come from the API, no install needed:

curl -s "https://api.launchpad.net/1.0/~amnezia/+archive/ubuntu/ppa?ws.op=getPublishedBinaries&binary_name=amneziawg-dkms&exact_match=true&distro_arch_series=https://api.launchpad.net/1.0/ubuntu/noble/amd64"

This may well be what stopped you: those file URLs throw an occasional HTTP 503. I hit it twice today and a plain retry worked both times, so use curl --retry 5 --retry-all-errors.

What I measured. Ubuntu 24.04.4, kernel 6.8.0-138 against your 6.8.0-137, x86_64, same installer, so the server config carries only the 2.0 parameters (Jc/Jmin/Jmax, S1-S4, H1-H4, I1) and none of HeaderProtectionKey, ContentPaddingAddition, RandomTrailers or DisableCookies. Every pairing below carried traffic both ways with no loss and no stalls: 200 ICMP packets of 1200 bytes at 0% loss, then iperf3 each way, moving 576 MiB to 1.37 GiB per direction depending on the pairing. With the kernel client I also repeated the whole run after an idle gap long enough to force a rekey, and it passed again.

server module	client	data
`3.1.20260812`	kernel module	flows
`3.1.20260812`	`amneziawg-go` master	flows
`3.1.20260812`	`amneziawg-go` at `08d68cda`, the last commit before `1f50ad73` "feat: awg 3.1 features"	flows
`3.0.20260805`	kernel module	flows

That third row was meant to confirm a theory of mine and killed it instead. I expected the 3.1 module to break peers that predate 3.1, which would have fit your Keenetic firmware nicely. It does not: a userspace client built before 3.1 support existed talks to the 3.1 module fine, and the two sides agree on their byte counters. So that branch of the search is closed, at least for reference implementations.

Before anyone reads those green rows as "no bug". I ran the client on the same host in a separate network namespace, so this exercises the module rather than a real network path, and it says nothing about MTU, fragmentation or NAT timeouts. And I have no Keenetic, so the one pairing that matters in your report is the one I cannot test.

I did check that my setup can see your symptom at all. I broke the data path on purpose while keeping the handshake alive, by pointing the peer's allowed-ips at a different address. The handshake stayed fresh, ping went to 100% loss and the peer counters stopped moving, which is your description almost word for word. So the green rows are a real result rather than a measurement that cannot fail.

The cheapest thing that would split this. Point any reference client at your server while it runs 4680320: a Linux box with the kernel module, or amneziawg-go with the same config. If that pairing passes traffic, the module's data path is not broken in general and the search narrows to the Keenetic side. And during a failing session, tcpdump on the server's UDP port separates "the client's data packets never arrive" from "they arrive and get dropped after decryption", which are very different bugs. Post either result and I will help dig.

@bivlked commented on GitHub (Aug 24, 2026): I maintain [the installer](https://github.com/bivlked/amneziawg-installer) this server was deployed with, so I tried to reproduce this on a box that matches yours closely. I could not. But I did find something that changes what the two builds in your title are. **They are different module generations.** I installed each one and read what the loaded module reports: | dkms build | published | `/sys/module/amneziawg/version` | |---|---|---| | `1.0.0-0~202608051436+ce16310` | 5 Aug | `3.0.20260805` | | `1.0.0-0~202608122133+0d5f03c` | 12 Aug | `3.0.20260805` | | `1.0.0-0~202608140352+4680320` | 14 Aug | `3.1.20260812` | So the update you bisected to is not a rebuild of the same code, it is the 3.0 to 3.1 transition. I installed the intermediate 12 Aug build as well, expecting the boundary to sit earlier, and it does not: that one is still 3.0. The generation flip lands exactly on `4680320`, the build your symptom started on. If anyone here suggests downgrading, note that it rolls the generation back too, and the package version string gives no hint of that. **Getting those old builds, since you said you could not.** Launchpad keeps superseded binaries downloadable: ``` https://launchpad.net/~amnezia/+archive/ubuntu/ppa/+files/amneziawg-dkms_<version>_all.deb ``` The package is architecture independent, so it is `_all.deb`; `_amd64.deb` gives 404. Version strings come from the API, no install needed: ``` curl -s "https://api.launchpad.net/1.0/~amnezia/+archive/ubuntu/ppa?ws.op=getPublishedBinaries&binary_name=amneziawg-dkms&exact_match=true&distro_arch_series=https://api.launchpad.net/1.0/ubuntu/noble/amd64" ``` This may well be what stopped you: those file URLs throw an occasional HTTP 503. I hit it twice today and a plain retry worked both times, so use `curl --retry 5 --retry-all-errors`. **What I measured.** Ubuntu 24.04.4, kernel 6.8.0-138 against your 6.8.0-137, x86_64, same installer, so the server config carries only the 2.0 parameters (Jc/Jmin/Jmax, S1-S4, H1-H4, I1) and none of `HeaderProtectionKey`, `ContentPaddingAddition`, `RandomTrailers` or `DisableCookies`. Every pairing below carried traffic both ways with no loss and no stalls: 200 ICMP packets of 1200 bytes at 0% loss, then iperf3 each way, moving 576 MiB to 1.37 GiB per direction depending on the pairing. With the kernel client I also repeated the whole run after an idle gap long enough to force a rekey, and it passed again. | server module | client | data | |---|---|---| | `3.1.20260812` | kernel module | flows | | `3.1.20260812` | `amneziawg-go` master | flows | | `3.1.20260812` | `amneziawg-go` at `08d68cda`, the last commit before `1f50ad73` "feat: awg 3.1 features" | flows | | `3.0.20260805` | kernel module | flows | That third row was meant to confirm a theory of mine and killed it instead. I expected the 3.1 module to break peers that predate 3.1, which would have fit your Keenetic firmware nicely. It does not: a userspace client built before 3.1 support existed talks to the 3.1 module fine, and the two sides agree on their byte counters. So that branch of the search is closed, at least for reference implementations. **Before anyone reads those green rows as "no bug".** I ran the client on the same host in a separate network namespace, so this exercises the module rather than a real network path, and it says nothing about MTU, fragmentation or NAT timeouts. And I have no Keenetic, so the one pairing that matters in your report is the one I cannot test. I did check that my setup can see your symptom at all. I broke the data path on purpose while keeping the handshake alive, by pointing the peer's `allowed-ips` at a different address. The handshake stayed fresh, ping went to 100% loss and the peer counters stopped moving, which is your description almost word for word. So the green rows are a real result rather than a measurement that cannot fail. **The cheapest thing that would split this.** Point any reference client at your server while it runs `4680320`: a Linux box with the kernel module, or `amneziawg-go` with the same config. If that pairing passes traffic, the module's data path is not broken in general and the search narrows to the Keenetic side. And during a failing session, `tcpdump` on the server's UDP port separates "the client's data packets never arrive" from "they arrive and get dropped after decryption", which are very different bugs. Post either result and I will help dig.

bsakaguchi commented

2026-10-13 21:06:49 +00:00

Author

Owner

@bivlked commented on GitHub (Oct 7, 2026):

Quick correction to my last comment first. The old amneziawg-dkms builds can no longer be downloaded from the PPA. On 24 Aug the +files/ links still worked. As of 7 Oct they return 404 for ce16310, 4680320, b72bb7a and 3c38e16, and only the current 4569c4c is there. Going by the Launchpad API, each recent build was removed from the archive about a day after the next one came out. So you can't downgrade from this PPA anymore. If you kept an old .deb, you can still try sudo apt install ./<file>.deb. To keep the package you have installed now, use sudo apt-mark hold amneziawg-dkms. DKMS will still rebuild that same source for new kernels, but you won't get fixes until you unhold it.

Also, the module version no longer tells builds apart. 4569c4c reports 3.1.20260812, the same as 4680320. The difference shows in srcversion:

build	`/sys/module/amneziawg/version`	`/sys/module/amneziawg/srcversion`
`ce16310`	`3.0.20260805`	`2CAAA0D41116817D097CF12`
`4680320`	`3.1.20260812`	`B55FF16F2E5FAADE434191F`
`4569c4c` (current)	`3.1.20260812`	`7EB84CCAD4C5015BF2AF6A1`

The packages for the first two rows are gone, so I rebuilt them from those commits using the current packaging. They should match the originals, but I can't prove that. cat /sys/module/amneziawg/srcversion shows the loaded module. modinfo -F srcversion amneziawg shows the module file for the running kernel. Until a reboot these two can differ.

I also ran a bigger test, and it still didn't reproduce. It was 38 runs on a freshly installed Ubuntu 24.04 VM with a 6.8 kernel, using two configs:

2.0 parameters only, with the module going from ce16310 to 4569c4c. That's the same kind of jump as yours.
A 3.1 config, with the module downgraded from 4569c4c to 4680320 and then upgraded back.

The clients were:

the kernel module;
amneziawg-go from before and after 3.1 support;
a kernel client on a second machine over the internet, running a different build than the server.

Not every client ran against both configs. Each run sent traffic both ways for 150 s, which included a rekey. Then it waited 200 s with no traffic and keepalive off, and the server sent first. Traffic got through in every run. When I broke the data path on purpose, the test caught it even with a fresh handshake.

I still have no Keenetic, so your exact setup is untested. With amneziawg-go, the server's latest handshake usually reset during the 200 s wait. So the "session expired, server sends first" case came up in only 5 of 16 of those runs. With the kernel client it came up in all 22.

If it still happens, could you post the srcversion from your server? A tcpdump on the server's UDP port during a broken session would also help.

@bivlked commented on GitHub (Oct 7, 2026): Quick correction to my last comment first. The old `amneziawg-dkms` builds can no longer be downloaded from the PPA. On 24 Aug the `+files/` links still worked. As of 7 Oct they return 404 for `ce16310`, `4680320`, `b72bb7a` and `3c38e16`, and only the current `4569c4c` is there. Going by the Launchpad API, each recent build was removed from the archive about a day after the next one came out. So you can't downgrade from this PPA anymore. If you kept an old `.deb`, you can still try `sudo apt install ./<file>.deb`. To keep the package you have installed now, use `sudo apt-mark hold amneziawg-dkms`. DKMS will still rebuild that same source for new kernels, but you won't get fixes until you unhold it. Also, the module version no longer tells builds apart. `4569c4c` reports `3.1.20260812`, the same as `4680320`. The difference shows in `srcversion`: | build | `/sys/module/amneziawg/version` | `/sys/module/amneziawg/srcversion` | |---|---|---| | `ce16310` | `3.0.20260805` | `2CAAA0D41116817D097CF12` | | `4680320` | `3.1.20260812` | `B55FF16F2E5FAADE434191F` | | `4569c4c` (current) | `3.1.20260812` | `7EB84CCAD4C5015BF2AF6A1` | The packages for the first two rows are gone, so I rebuilt them from those commits using the current packaging. They should match the originals, but I can't prove that. `cat /sys/module/amneziawg/srcversion` shows the loaded module. `modinfo -F srcversion amneziawg` shows the module file for the running kernel. Until a reboot these two can differ. I also ran a bigger test, and it still didn't reproduce. It was 38 runs on a freshly installed Ubuntu 24.04 VM with a 6.8 kernel, using two configs: - 2.0 parameters only, with the module going from `ce16310` to `4569c4c`. That's the same kind of jump as yours. - A 3.1 config, with the module downgraded from `4569c4c` to `4680320` and then upgraded back. The clients were: - the kernel module; - `amneziawg-go` from before and after 3.1 support; - a kernel client on a second machine over the internet, running a different build than the server. Not every client ran against both configs. Each run sent traffic both ways for 150 s, which included a rekey. Then it waited 200 s with no traffic and keepalive off, and the server sent first. Traffic got through in every run. When I broke the data path on purpose, the test caught it even with a fresh handshake. I still have no Keenetic, so your exact setup is untested. With `amneziawg-go`, the server's latest handshake usually reset during the 200 s wait. So the "session expired, server sends first" case came up in only 5 of 16 of those runs. With the kernel client it came up in all 22. If it still happens, could you post the `srcversion` from your server? A `tcpdump` on the server's UDP port during a broken session would also help.

bsakaguchi referenced this issue

2026-10-13 21:07:31 +00:00

[PR #124] feat(junk): add protocol mimicry tags for DPI evasion #196