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

Aperta
  • Qualcosa non va?
#151 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@ryjen ci sta già lavorando.

Dal 20/10/2026.

  • #3 di @ryjen — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
22/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend, networking

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Go
Stelle
8.8k
Fork
404
Merge medio
3h 48m
PR unite (30g)
1

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di tailscale/tailcat

Tutte le issue di tailscale/tailcat

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.