tailscale

Commit Graph

Author	SHA1	Message	Date
Josh Bleecher Snyder	3fd5f4380f	util/multierr: new package github.com/go-multierror/multierror served us well. But we need a few feature from it (implement Is), and it's not worth maintaining a fork of such a small module. Instead, I did a clean room implementation inspired by its API. Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>	3 years ago
Brad Fitzpatrick	09e692e318	health: don't look for UDP goroutines in js/wasm health check Updates #3157 Change-Id: I43d97e6876eeb2d1936fc567835134568bb8615c Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	3 years ago
Brad Fitzpatrick	aae622314e	tailcfg, health: add way for control plane to add problems to health check So if the control plane knows that something's broken about the node, it can include problem(s) in MapResponse and "tailscale status" will show it. (and GUIs in the future, as it's in ipnstate.Status/JSON) This also bumps the MapRequest.Version, though it's not strictly required. Doesn't hurt. Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	3 years ago
Brad Fitzpatrick	4549d3151c	cmd/tailscale: make status show health check problems Fixes #2775 RELNOTE=tailscale status now shows health check problems Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	3 years ago
Brad Fitzpatrick	5bacbf3744	wgengine/magicsock, health, ipn/ipnstate: track DERP-advertised health And add health check errors to ipnstate.Status (tailscale status --json). Updates #2746 Updates #2775 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	3 years ago
Josh Bleecher Snyder	9d542e08e2	wgengine/magicsock: always run ReceiveIPv6 One of the consequences of the bind refactoring in `6f23087175` is that attempting to bind an IPv6 socket will always result in c.pconn6.pconn being non-nil. If the bind fails, it'll be set to a placeholder packet conn that blocks forever. As a result, we can always run ReceiveIPv6 and health check it. This removes IPv4/IPv6 asymmetry and also will allow health checks to detect any IPv6 receive func failures. Signed-off-by: Josh Bleecher Snyder <josharian@gmail.com>	4 years ago
Josh Bleecher Snyder	fe50ded95c	health: track whether we have a functional udp4 bind Suggested-by: Brad Fitzpatrick <bradfitz@tailscale.com> Signed-off-by: Josh Bleecher Snyder <josharian@gmail.com>	4 years ago
Josh Bleecher Snyder	744de615f1	health, wgenegine: fix receive func health checks for the fourth time The old implementation knew too much about how wireguard-go worked. As a result, it missed genuine problems that occurred due to unrelated bugs. This fourth attempt to fix the health checks takes a black box approach. A receive func is healthy if one (or both) of these conditions holds: * It is currently running and blocked. * It has been executed recently. The second condition is required because receive functions are not continuously executing. wireguard-go calls them and then processes their results before calling them again. There is a theoretical false positive if wireguard-go go takes longer than one minute to process the results of a receive func execution. If that happens, we have other problems. Updates #1790 Signed-off-by: Josh Bleecher Snyder <josharian@gmail.com>	4 years ago
Josh Bleecher Snyder	0d4c8cb2e1	health: delete ReceiveFunc health checks They were not doing their job. They need yet another conceptual re-think. Start by clearing the decks. Signed-off-by: Josh Bleecher Snyder <josharian@gmail.com>	4 years ago
Josh Bleecher Snyder	8d7f7fc7ce	health, wgenegine: fix receive func health checks yet again The existing implementation was completely, embarrassingly conceptually broken. We aren't able to see whether wireguard-go's receive function goroutines are running or not. All we can do is model that based on what we have done. This commit fixes that model. Fixes #1781 Signed-off-by: Josh Bleecher Snyder <josharian@gmail.com>	4 years ago
Josh Bleecher Snyder	5835a3f553	health, wgengine/magicsock: avoid receive function false positives Avery reported a sub-ms health transition from "receiveIPv4 not running" to "ok". To avoid these transient false-positives, be more precise about the expected lifetime of receive funcs. The problematic case is one in which they were started but exited prior to a call to connBind.Close. Explicitly represent started vs running state, taking care with the order of updates. Signed-off-by: Josh Bleecher Snyder <josharian@gmail.com>	4 years ago
Josh Bleecher Snyder	f845aae761	health: track whether magicsock receive functions are running Signed-off-by: Josh Bleecher Snyder <josharian@gmail.com>	4 years ago
David Anderson	f007a9dd6b	health: add DNS subsystem and plumb errors in. Signed-off-by: David Anderson <danderson@tailscale.com>	4 years ago
Brad Fitzpatrick	85138d3183	health: track whether any network interface is up Fixes #1562 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	4 years ago
Brad Fitzpatrick	9eb65601ef	health, ipn/ipnlocal: track, log overall health Updates #1505 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	4 years ago
Brad Fitzpatrick	232cfda280	wgengine/router: report to control when setPrivateNetwork fails Fixes #1503 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	4 years ago
Brad Fitzpatrick	ba8c6d0775	health, controlclient, ipn, magicsock: tell health package state of things Not yet checking anything. Just plumbing states into the health package. Updates #1505 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	4 years ago
Brad Fitzpatrick	fd8e070d01	health, control/controlclient, wgengine: report when router unhealthy Updates tailscale/corp#1338 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>	4 years ago

1 2

68 Commits (da40609abd128b522684adcf06923d2faaad6fac)