2 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
YoungReckless4andSanaei	8f162994ef	feat(clients): let admins set PersistentKeepalive on tunnel clients (#6377) ... * feat(clients): let admins set PersistentKeepalive on tunnel clients model.Client already carries KeepAlive, and every AmneziaWG/WireGuard client config emitter already writes PersistentKeepalive when it is above zero -- but nothing in the UI could set it, so it stayed 0 and the line was never emitted. Without it a peer that goes quiet has nothing to trigger a handshake: WireGuard only initiates when it has data to send. An idle client stays disconnected after any interruption -- a NAT mapping timing out, a device sleeping, the panel restarting -- until the user generates traffic themselves. New clients default to 25, the conventional value, which also keeps the NAT mapping open. Existing clients keep whatever they have, and 0 remains valid and means "do not send keepalives". * fix(clients): let an explicit 0 actually disable PersistentKeepalive Addresses review feedback on the previous commit. UpdateInboundClient carries a stored keepalive forward whenever the incoming one is zero, so the settings JSON and the running peer survive a metadata-only edit that omits the field. That was a 0 -> 0 no-op while no UI could set a nonzero value. Now that the client form can, the carry-forward became reachable in the other direction: a client created at the form's default of 25 could never be returned to 0, and the hint text shipped to all 13 locales -- "0 disables it" -- described something the backend silently refused. The save even reported success, because a settings blob that came back byte-identical skips the transaction entirely. The zero value cannot carry that distinction, so model.Client.KeepAlive becomes *int: nil means the field was never sent, &0 means "send no keepalives". The pointer survives the internal marshal in ClientService.Update, which is where an explicit 0 was being erased by omitempty before UpdateInboundClient ever saw it. ClientRecord.KeepAlive stays a plain int -- it is the stored column, where "unset" has no meaning -- and the conversions bridge the two. Two tests, both red before this change in the direction they cover: an explicit 0 must reach wg_keep_alive, and an update that omits the field must still leave a stored 25 alone. Also adds the output transform every other numeric field in the client form already has, so a cleared box sends 0 rather than null. * fix(clients): repair the keepalive pointer conversion after the main merge Merging main brought buildAmneziaWGProxy (#6326) in beside the Client.KeepAlive int -> *int change without reconciling the new call site, so internal/sub stopped compiling and took every package importing it with it. The two sides touched different lines, so git merged them without a conflict -- the green `make verify` on 112b19a8 predates the break. ToClient also wrapped a stored 0 in a pointer, so omitempty stopped omitting: a VLESS client's settings JSON gained "keepAlive": 0 on the attach and bulk-attach paths, and that JSON reaches xray-core verbatim through GenXrayInboundConfig. wg_keep_alive cannot tell "off" from "never set", so a stored 0 now stays nil. Also copies the regenerated openapi.json over the docs mirror, which nothing in CI checks, and trims two comment blocks to the two-line cap. --------- Co-authored-by: Sanaei <ho3ein.sanaei@gmail.com>	2026-09-10 22:32:42 +02:00
YoungReckless4	3cd3836d77	fix(amneziawg): account for S4 junk in the default tunnel MTU (#6376) ... * fix(amneziawg): account for S4 junk in the default tunnel MTU amneziawg prepends S4 random bytes to every transport packet (device.NewOutboundElement) and, unlike content padding and random trailers, never clamps them against the tunnel MTU. A full-size packet therefore lands on the wire at MTU + 60 + S4 bytes: 20 IPv4 + 8 UDP + S4 + 16 transport header + 16 poly1305 tag. With the 1420 default that overflows a 1500-byte link once S4 exceeds 20, and GenerateObfuscation31 draws S4 from 12..27 inclusive -- so roughly 44% of newly created inbounds fragment every full-size packet they send. Measured on a live pair of interfaces, predicted against observed: MTU 1380 S4 12 -> 1452 on the wire (fits) MTU 1420 S4 12 -> 1492 (fits) MTU 1420 S4 20 -> 1500 (exactly at the limit) MTU 1420 S4 21 -> 1501 (fragments) MTU 1420 S4 27 -> 1507 (fragments) EffectiveMTU now subtracts S4 from the default; an explicit MTU is untouched. Client configs carry the same number. They previously omitted the MTU line whenever the server had no explicit value, which left the client on its own 1420 default and fragmented the client-to-server direction even after the server side was fixed -- silently, and only in one direction. All three emitters (the Go subscription text and the two TypeScript ones) now agree, which is what the existing parity test exists to protect. * fix(amneziawg): rebuild the device when S4 changes the derived MTU Addresses review feedback on the previous commit. Deriving the default MTU from S4 made a construction-time-only property depend on a hot-reloadable input, but addressFingerprint -- ensureLocked's only rebuild trigger -- still hashed the raw inst.MTU. S4 is a UAPI field, so an S4-only edit took the in-place IpcSet branch and the gVisor netstack kept the MTU derived from the old S4 while all three client emitters already advertised the new one. Every panel-created inbound leaves mtu unset, so that was the normal case, not an edge one: with S4 raised far enough the fragmentation this fix exists to remove came straight back, and stayed until a panel restart or an unrelated address edit. Folding EffectiveMTU into the fingerprint fixes it. An explicit MTU still takes the in-place branch on an S4 edit, since it does not move the interface MTU. Also trims four comment blocks to the 2-line cap in CLAUDE.md, and points NewDevice's doc comment at EffectiveMTU instead of the deleted defaultMTU.	2026-09-08 16:55:32 +02:00