Close can hang and leak the WireGuard engine and DERP connection: bump tailscale.com past the netstack close fix, and close the backend regardless

Abierto
  • ¿Algo no está bien?
#151 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@ryjen ya está trabajando en esto.

Desde el 20/10/2026.

  • #3 de @ryjen — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
22/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
go
Área
backend, networking

Línea de trabajo

Start with locoBackend.Close in tailcat.go (around lines 374-392), where the WireGuard engine, network monitor, dialer and event bus only close after ns.Close() returns, and with Client.Close (around lines 2003-2010), which holds startMu across lb.Close. Bumping the tailscale.com version in go.mod is the first step, and the backend-teardown change needs a test that makes netstack close block. Done means a close that hangs in the netstack still releases the remaining resources and does not block other Client use. The TCP option and abortive-close requests are API design and should be scoped separately.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What is the issue?

Tailcat v0.7.0 requires tailscale.com v1.103.0-pre.0.20260916030321-a2263542f260, and main (52fbad3) requires v1.103.0-pre.0.20260929142145-a0e471a35b8f. Both predate tailscale/tailscale#21668 (merged as fb79793 on 2026-10-13), which fixes tailscale/tailscale#21631: wgengine/netstack.(*Impl).Close blocks forever once more TCP endpoints need a reset than its 512-packet outbound queue holds.

We hit that through Tailcat. A Server holding 497 endpoints in TIME-WAIT closed in about 1 ms; one holding 539 never returned. A server that carried a few hundred short connections in the last minute is enough, since gVisor keeps TIME-WAIT for 60 s.

Requests, roughly in order of value:

  1. Bump tailscale.com past fb79793.
  2. Close the rest of the backend even when the netstack's close blocks. locoBackend.Close (tailcat.go:374-392, v0.7.0) closes the WireGuard engine, the network monitor, the dialer and the event bus only after ns.Close() returns. When that blocks, the process keeps the magicsock UDP sockets, the DERP connection (with its keepalive every 60 to 65 s, reconnecting after each relay restart) and their goroutines until it exits. Measured per stuck Client: about 104 goroutines, 7.5 MiB of live heap and one DERP connection. A program that closes a Client whenever a peer goes away leaks one of these per peer change.
  3. Client.Close holds startMu across lb.Close (tailcat.go:2003-2010), so a close stuck in the backend also blocks any concurrent use of that Client.
  4. A way to set the netstack's TCP options, at least tcpip.TCPTimeWaitTimeoutOption. tailscale.com's netstack.Impl already has SetTransportProtocolOption; a Server/Client field for the TIME-WAIT timeout, or the accessor the TODO at tcpipStackOf (tailcat.go:960-963) asks for, would do.
  5. Optionally, an exported abortive close (linger 0) for the conns Tailcat returns. Related to google/gvisor#15013: Server accepts through tcp.Forwarder, and gVisor drops a new SYN on a 4-tuple the server still holds in TIME-WAIT until TIME-WAIT expires. A client that makes one short connection per request, with the server closing first, sees about 60 x R / 49,536 of its dials stall (R connections a second over one client/server pair): we measured 2.4% at 20/s, 9.7% at 80/s and 36% at 300/s, each stalled dial waiting out the caller's timeout. Setting linger 0 on the client's conn before closing it (through gonet's unexported ep, the field Tailcat's own gonetTCPConnInternals reads) removed the stalls and left no TIME-WAIT on either side: 60,000 short connections over one pair in 4.2 s, none failed. An exported option would avoid the reflection.
Environment

Tailcat v0.7.0; tailscale.com v1.103.0-pre.0.20260916030321-a2263542f260; gVisor v0.0.0-20260915211658-a6f909f08a72; Go 1.27.2; Linux (Docker 29.8) and macOS. Measured with Tailcat's Server and Client in one process over an in-process relay, and between containers.

Lenguaje dominante
Go
Estrellas
8.8k
Forks
404
Merge medio
3 h 48 min
PR fusionados (30 d)
1

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de tailscale/tailcat

Todos los issues de tailscale/tailcat

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.