If Wrapper.StatisticsEnable is enabled,
then per-connection counters are maintained.
If enabled, Wrapper.StatisticsExtract must be periodically called
otherwise there is unbounded memory growth.
Signed-off-by: Joe Tsai <joetsai@digital-static.net>
* tka.State.staticValidateCheckpoint could call methods on a contained key prior to calling StaticValidate on that key
* Remove broken backoff / RPC retry logic from tka methods in ipn/ipnlocal, to be fixed at a later time
* Fix NetworkLockModify() which would attempt to take b.mu twice and deadlock, remove now-unused dependence on netmap
* Add methods on ipnlocal.LocalBackend to be used in integration tests
* Use TAILSCALE_USE_WIP_CODE as the feature flag so it can be manipulated in tests
Signed-off-by: Tom DNetto <tom@tailscale.com>
xterm 5.0 was released a few weeks ago, and it picks up
xtermjs/xterm.js#4069, which was the main reason why we were on a 5.0
beta.
Signed-off-by: Mihai Parparita <mihai@tailscale.com>
High-level API:
type Statistics struct { ... }
type Counts struct { TxPackets, TxBytes, RxPackets, RxBytes uint64 }
func (*Statistics) UpdateTx([]byte)
func (*Statistics) UpdateRx([]byte)
func (*Statistics) Extract() map[flowtrack.Tuple]Counts
The API accepts a []byte instead of a packet.Parsed so that a future
implementation can directly hash the address and port bytes,
which are contiguous in most IP packets.
This will be useful for a custom concurrent-safe hashmap implementation.
Signed-off-by: Joe Tsai <joetsai@digital-static.net>
From the original commit that implemented it:
It accepts Postgres connections over Tailscale only, dials
out to the configured upstream database with TLS (using
strong settings, not the swiss cheese that postgres defaults to),
and proxies the client through.
It also keeps an audit log of the sessions it passed through,
along with the Tailscale-provided machine and user identity
of the connecting client.
In our other repo, this was:
commit 92e5edf98e8c2be362f564a408939a5fc3f8c539,
Change-Id I742959faaa9c7c302bc312c7dc0d3327e677dc28.
Co-authored-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Signed-off-by: David Anderson <danderson@tailscale.com>
HTTP/2 server connections can hang forever waiting for a clean
shutdown that was preempted by a fatal error. This condition can
be exploited by a malicious client to cause a denial of service.
Signed-off-by: Florian Lehner <dev@der-flo.net>
Due to improper path santization, RPMs containing relative file
paths can cause files to be written (or overwritten) outside of the
target directory.
Signed-off-by: Florian Lehner <dev@der-flo.net>
And add a CLI/localapi and c2n mechanism to enable it for a fixed
amount of time.
Updates #1548
Change-Id: I71674aaf959a9c6761ff33bbf4a417ffd42195a7
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
This information is super helpful when debugging and it'd be nice to not
have to scroll around in the logs to find it near a bugreport.
Signed-off-by: Andrew Dunham <andrew@du.nham.ca>
Most visible when using tsnet.Server, but could have resulted in dropped
messages in a few other places too.
Fixes#5743
Signed-off-by: Mihai Parparita <mihai@tailscale.com>
Sync with golang.org/x/sync/singleflight at commit
8fcdb60fdcc0539c5e357b2308249e4e752147f1
Fixes#5790
Signed-off-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Callers of LogHost often jump through hoops to undo the
loss of information dropped by LogHost (e.g., the HTTP scheme).
Signed-off-by: Joe Tsai <joetsai@digital-static.net>
I brain-o'ed the math earlier. The NextDNS prefix is /32 (actually
/33, but will guarantee last bit is 0), so we have 128-32 = 96 bits
(12 bytes) of config/profile ID that we can extract. NextDNS doesn't
currently use all those, but might.
Updates #2452
Change-Id: I249bd28500c781e45425fd00fd3f46893ae226a2
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
Context: https://github.com/tailscale/tailscale/pull/5588#issuecomment-1260655929
It seems that if the interface at index 1 is down, the rule is not installed. As such,
we increase the range we detect up to 2004 in the hope that at least one of the interfaces
1-4 will be up.
Signed-off-by: Tom DNetto <tom@tailscale.com>
I added new functions to winutil to obtain the state of a service and all
its depedencies, serialize them to JSON, and write them to a Logf.
When tstun.New returns a wrapped ERROR_DEVICE_NOT_AVAILABLE, we know that wintun
installation failed. We then log the service graph rooted at "NetSetupSvc".
We are interested in that specific service because network devices will not
install if that service is not running.
Updates https://github.com/tailscale/tailscale/issues/5531
Signed-off-by: Aaron Klotz <aaron@tailscale.com>
Control may not be bound to (just) localhost when sharing dev servers,
allow the Wasm client to connect to it in that case too.
Signed-off-by: Mihai Parparita <mihai@tailscale.com>
* and move goroutine scrubbing code to its own package for reuse
* bump capver to 45
Change-Id: I9b4dfa5af44d2ecada6cc044cd1b5674ee427575
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
SetDNS calls were broken by 6d04184325 the other day. Unreleased.
Caught by tests in another repo.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
At some point we started restarting map polls on health change, but we
don't remember why. Maybe it was a desperate workaround for something.
I'm not sure it ever worked.
Rather than have a haunted graveyard, remove it.
In its place, though, and somewhat as a safety backup, send those
updates over the HTTP/2 noise channel if we have one open. Then if
there was a reason that a map poll restart would help we could do it
server-side. But mostly we can gather error stats and show
machine-level health info for debugging.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
In prep for a future change that would've been very copy/paste-y.
And because the set-dns call doesn't currently use a context,
so timeouts/cancelations are plumbed.
Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com>
- removed some in-flow time calls
- increase buffer size to 2MB to overcome syscall cost
- move relative time computation from record to report time
Signed-off-by: James Tucker <james@tailscale.com>
The fragment offset is an 8 byte offset rather than a byte offset, so
the short packet limit is now in fragment block size in order to compare
with the offset value.
The packet flags are in the first 3 bits of the flags/frags byte, and
so after conversion to a uint16 little endian value they are at the
start, not the end of the value - the mask for extracting "more
fragments" is adjusted to match this byte.
Extremely short fragments less than 80 bytes are dropped, but fragments
over 80 bytes are now accepted.
Fixes#5727
Signed-off-by: James Tucker <james@tailscale.com>
