interfaces.State.String tries to print a concise summary of the
network state, removing any interfaces that don't have any or any
interesting IP addresses. On macOS and iOS, for instance, there are a
ton of misc things.
But the link monitor based its are-there-changes decision on
interfaces.State.Equal, which just used reflect.DeepEqual, including
comparing all the boring interfaces. On macOS, when turning wifi on or off, there
are a ton of misc boring interface changes, resulting in hitting an earlier
check I'd added on suspicion this was happening:
[unexpected] network state changed, but stringification didn't
This fixes that by instead adding a new
interfaces.State.RemoveUninterestingInterfacesAndAddresses method that
does, uh, that. Then use that in the monitor. So then when Equal is
used later, it's DeepEqualing the already-cleaned version with only
interesting interfaces.
This makes cmd/tailscaled debug --monitor much less noisy.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Not beautiful, but I'm debugging connectivity problems on
NEProvider.sleep+wake and need more clues.
Updates #1426
Updates tailscale/corp#1289
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Also change the type to netaddr.IP while here, because it made sorting
easier.
Updates tailscale/corp#1397
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
We often see things in logs like:
2021-03-02 17:52:45.2456258 +0800 +0800: winhttp: Open: The parameter is incorrect.
2021-03-02 17:52:45.2506261 +0800 +0800: tshttpproxy: winhttp: GetProxyForURL("https://log.tailscale.io/c/tailnode.log.tailscale.io/5037bb42f4bc330e2d6143e191a7ff7e837c6be538139231de69a439536e0d68"): ERROR_INVALID_PARAMETER [unexpected]
I have a hunch that WinHTTP has thread-local state. If so, this would fix it.
If not, this is pretty harmless.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
DefaultRouteInterface was previously guarded by build tags such that
it was only accessible to tailscaled-on-macos, but there was no reason
for that. It runs fine in the sandbox and gives better default info,
so merge its file into interfaces_darwin.go.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
And add a --socks5-server flag.
And fix a race in SOCKS5 replies where the response header was written
concurrently with the copy from the backend.
Co-authored with Naman Sood.
Updates #707
Updates #504
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
* move probing out of netcheck into new net/portmapper package
* use PCP ANNOUNCE op codes for PCP discovery, rather than causing
short-lived (sub-second) side effects with a 1-second-expiring map +
delete.
* track when we heard things from the router so we can be less wasteful
in querying the router's port mapping services in the future
* use portmapper from magicsock to map a public port
Fixes#1298Fixes#1080Fixes#1001
Updates #864
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This allows proxy URLs such as:
http://azurediamond:hunter2@192.168.122.154:38274
to be used in order to dial out to control, logs or derp servers.
Signed-off-by: Christine Dodrill <xe@tailscale.com>
The interface.State logging tried to only log interfaces which had
interesting IPs, but the what-is-interesting checks differed between
the code that gathered the interface names to print and the printing
of their addresses.
Upstream wireguard-go decided to use errors.Is(err, net.ErrClosed)
instead of checking the error string.
It also provided an unsafe linknamed version of net.ErrClosed
for clients running Go 1.15. Switch to that.
This reduces the time required for the wgengine/magicsock tests
on my machine from ~35s back to the ~13s it was before
456cf8a3765948d6f1992162993eaf3844371592.
Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>
Unused for now, but I want to backport this commit to 1.4 so 1.6 can
start sending these and then at least 1.4 logs will stringify nicely.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
The code was using a C "int", which is a signed 32-bit integer.
That means some valid IP addresses were negative numbers.
(In particular, the default router address handed out by AT&T
fiber: 192.168.1.254. No I don't know why they do that.)
A negative number is < 255, and so was treated by the Go code
as an error.
This fixes the unit test failure:
$ go test -v -run=TestLikelyHomeRouterIPSyscallExec ./net/interfaces
=== RUN TestLikelyHomeRouterIPSyscallExec
interfaces_darwin_cgo_test.go:15: syscall() = invalid IP, false, netstat = 192.168.1.254, true
--- FAIL: TestLikelyHomeRouterIPSyscallExec (0.00s)
Signed-off-by: David Crawshaw <crawshaw@tailscale.com>
Windows has a low resolution timer.
Some of the tests assumed that unblock takes effect immediately.
Consider:
t := time.Now()
elapsed := time.Now().After(t)
It seems plausible that elapsed should always be true.
However, with a low resolution timer, that might fail.
Change time.Now().After to !time.Now().Before,
so that unblocking always takes effect immediately.
Fixes#873.
This adds a new IP Protocol type, TSMP on protocol number 99 for
sending inter-tailscale messages over WireGuard, currently just for
why a peer rejects TCP SYNs (ACL rejection, shields up, and in the
future: nothing listening, something listening on that port but wrong
interface, etc)
Updates #1094
Updates tailscale/corp#1185
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Users in Amsterdam (as one example) were flipping back and forth
between equidistant London & Frankfurt relays too much.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
In practice, we already provide IPv6 endpoint addresses via netcheck,
and that address is likely to match a local address anyway (i.e. no NAT66).
The comment at that piece of the code mentions needing to figure out a
good priority ordering, but that only applies to non-active-discovery
clients, who already don't do anything with IPv6 addresses.
Signed-off-by: David Anderson <danderson@tailscale.com>
likelyHomeRouterIPDarwinSyscall iterates through the list of routes,
looking for a private gateway, returning the first one it finds.
likelyHomeRouterIPDarwinExec does the same thing,
except that it returns the last one it finds.
As a result, when there are multiple gateways,
TestLikelyHomeRouterIPSyscallExec fails.
(At least, I think that that is what is happening;
I am going inferring from observed behavior.)
Signed-off-by: Josh Bleecher Snyder <josh@tailscale.com>
David Anderson
Brad Fitzpatrick
Naman Sood
Christine Dodrill
Josh Bleecher Snyder
David Crawshaw
Denton Gentry