Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2024-03-05T17:40:02Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40339Avoid SQS queue reuse errors2024-03-05T17:40:02ZCecylia BocovichAvoid SQS queue reuse errorsAs described in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40323#note_3002284, the reuse of the `sqsClientID` can cause errors on subsequent rendezvous attempts.As described in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40323#note_3002284, the reuse of the `sqsClientID` can cause errors on subsequent rendezvous attempts.mpumpuhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40322Local LAN access through snowflake2024-02-27T11:30:44Zdreamboat301Local LAN access through snowflakeHi
I'm a little bit late to the party. I've read a report from the 37C3 about the success helping people from Iran and other countries avoiding traffic blocks.
So I installed a snowflake instance in proxmox and I was overwhelmed with t...Hi
I'm a little bit late to the party. I've read a report from the 37C3 about the success helping people from Iran and other countries avoiding traffic blocks.
So I installed a snowflake instance in proxmox and I was overwhelmed with traffic. Mostly from Iran and roughly 25 GB a day. I love it that I could be of help!
But I believe there is an issue with it.
I put the instance in its own VLAN and configured the firewall to block any VLAN traffic to and from this network.
A few times a day I get an alert in my firewall claiming that this machine wants to connect to other VLANs. First I thought it might answer broadcast messages. But the IPs it requests don't exist. E.g. 192.168.1.5 is nowhere to be seen. But these are only the visable connections. Because of the nature of Unifi I can't block access to 192.168.1.1 because it is the same as 192.168.x.1 of any VLAN. So I shut down the instance to avoid people of maybe hacking my network. There were also connections to 10.x.x.x networks.
How can this be possible, that people can access my local LAN? I thought that I'm just a bridge to the Tor network and forwarding any traffic to it. Including local LAN addresses (or blocking it).
I've done a few tests. If I access in Tor Browser the IP 192.168.1.1 it gets blocked right away. Thats fine. I created a subdomain of a domain I own and added 192.168.1.1 as an A record. Suddendly I'm able to get through. Somewhere it is blocked anyway but it looks like that it is not fully blocked.
I'm just a home user. Please have patience with me when you direct me to do something.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/403151 webtunnel bridge instead of two!2024-01-08T18:44:25Zcypherpunks1 webtunnel bridge instead of two!You should give at least two bridges for conflux to work.You should give at least two bridges for conflux to work.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40302Proxy hourly stats did not actually happen during that hour2023-10-30T16:44:18ZRoger DingledineProxy hourly stats did not actually happen during that hourMy snowflake proxy today said in its logs:
```
2023/10/27 09:53:58 In the last 1h0m0s, there were 53 connections. Traffic Relayed ↓ 999064 KB, ↑ 167798 KB.
2023/10/27 10:53:58 In the last 1h0m0s, there were 67 connections. Traffic Relaye...My snowflake proxy today said in its logs:
```
2023/10/27 09:53:58 In the last 1h0m0s, there were 53 connections. Traffic Relayed ↓ 999064 KB, ↑ 167798 KB.
2023/10/27 10:53:58 In the last 1h0m0s, there were 67 connections. Traffic Relayed ↓ 561833 KB, ↑ 97282 KB.
2023/10/27 11:53:58 In the last 1h0m0s, there were 63 connections. Traffic Relayed ↓ 124717270 KB, ↑ 6237157 KB.
2023/10/27 12:53:58 In the last 1h0m0s, there were 48 connections. Traffic Relayed ↓ 745608 KB, ↑ 97699 KB.
```
That "125 gigabytes" entry translates to... almost 35 megabytes per second of traffic, on average during the hour? Probably by only a few or even one user? This did not happen during that hour.
Looking at proxy/lib/pt_event_logger.go:
```
case event.EventOnProxyConnectionOver:
e := e.(event.EventOnProxyConnectionOver)
p.inboundSum += e.InboundTraffic
p.outboundSum += e.OutboundTraffic
p.connectionCount += 1
```
I.e. what is happening here is that the stats for the entire connection are counted during the hour that it closed.
See the forum for somebody else reporting this same issue (forum post noticed courtesy MarkC on irc): https://forum.torproject.org/t/impossible-metric-for-snowflake-proxy/9941/1
We should either (a) make the hourly "In the last 1h0m0s," be accurate, in the sense that they actually tell me what happened in the last 1h0m0s, or (b) change the log message so it's clearer it is telling me how many connections finished during that hour along with total transfer on those recently-closed connections.
I'd prefer solution 'a', since it is what I thought I was getting out of these log entries, and I was using it to e.g. try to judge what timezones my snowflake is popular.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40290standalone snowflake README still says go 1.15+ needed2023-10-20T15:25:32ZRoger Dingledinestandalone snowflake README still says go 1.15+ neededThe proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two t...The proxy/README.md file still says you need Go 1.15+, but it appears from e.g. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/184 like the go version requirement is now 1.21.
So, two things:
* We should update the README to reflect current requirements
and
* We should figure out what we want to tell people on Debian, who can no longer build snowflake, if they don't want to engage in installing and maintaining the whole toolchain manually. Do they stick with v2.6.1? Do they turn off their snowflake? Something even smarter? ...and then write that in the README too.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40286On IPv6-only server, always "NAT type: unknown" even with firewall disabled2023-10-21T16:18:43Zcatharsis71On IPv6-only server, always "NAT type: unknown" even with firewall disabledI have an IPV6-only VPS server, using NAT64 DNS servers for outbound access to IPV4-only hostnames
hostnames with no AAAA records get synthetic AAAA records set by the DNS server so that traffic goes through the NAT64 service
hostnames w...I have an IPV6-only VPS server, using NAT64 DNS servers for outbound access to IPV4-only hostnames
hostnames with no AAAA records get synthetic AAAA records set by the DNS server so that traffic goes through the NAT64 service
hostnames with AAAA records resolve normally and go out directly
there is no access to raw IPv4 IP addresses
running snowflake-proxy, I always get "NAT type: unknown" even if my firewall is completely disabled... is this intended behavior?
I've tested both the Docker container and compiling/running locally but the results are the same
the proxy does seem to work but normally only gets 0-3 connections per hour per proxy (seemingly unaffected by whether the firewall is up or down)
perhaps this is due to the small pool of IPV6 clients wanting to connect, but I'm not sure
snowflake.torproject.net has an AAAA record so traffic to it does not go through NAT64
likewise stun.l.google.com has an AAAA record so traffic to it does not go through NAT64
I am unable to determine the cause of the "NAT type: unknown"https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40275Bump verison of snowflake to v2.6.02023-06-20T18:48:10ZCecylia BocovichBump verison of snowflake to v2.6.0Let's do a library version bump and update the version shipped in Tor BrowserLet's do a library version bump and update the version shipped in Tor BrowserCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40269Snowflake web badge need 3rd-party cookies to run, which is unskilled in toda...2023-04-20T16:09:34ZsolidsSnowflake web badge need 3rd-party cookies to run, which is unskilled in today's most browsersToday most browser set the default setting to disable 3rd-party cookie, in Safari it's called "Prevent corss-site tracking", in Chromium-based browser it's called "Block third-party cookies". For example, the badge in website [relay.love...Today most browser set the default setting to disable 3rd-party cookie, in Safari it's called "Prevent corss-site tracking", in Chromium-based browser it's called "Block third-party cookies". For example, the badge in website [relay.love](https://relay.love) will show "Cookies are not enabled." in my browser and it's not possible to run without re-enabling 3rd-party cookies, which will allow tracking websites sneak in my privacy.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40267Improve bug discovery process2023-06-20T20:59:52ZitchyonionImprove bug discovery processCreating the issue as a follow up to the meeting on March 16th, 2023 about **snowflake-server buffer reuse bug postmortem https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40260**
(The title of th...Creating the issue as a follow up to the meeting on March 16th, 2023 about **snowflake-server buffer reuse bug postmortem https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40260**
(The title of this ticket could be improved as well. Feel free to do so)
> The harm to users was minor, but incidents like this are a good opportunity to reflect on our process, to make similar things less likely in the future.
>
> The bug (#40199) might have been caught, but was not, at multiple points:
> - Code understanding and review by the initial committer
> - Code review on the merge request
> - Automated tests / CI
> - End user reports or logs
> - Logs or instrumentation at the bridge
>
> **Which of these processes, if any, should we change, to decrease the chance of mistakes?**
>
> **Brainstorming during the meeting:**
>
> - Initial merge request should have included a test to prove the assumption that buffers were not reused.
> - The reviewer might have requested that such a test be added.
> - Any such anomalies, if detected at the client, should be logged in such a way that they show up in the tor log.
> - dcf's private branch that logs KCP's internal error counters:
> - https://gitlab.torproject.org/dcf/snowflake/-/commit/9f43843b59b9753686be836f2c55f209ba29c1e9
> - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40262#note_2886018
> - The fix this week made the "KCPInErrors" counter go to zero:
> - https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40262#note_2886032
> - We should log whenever KCPInErrors is non-zero, at least.
> - We are missing integration testing as part of CI. We have unit testing, but nothing where all the pieces are working together as in production.
> - shelikhoo's setup for distributed snowflake server testing: https://github.com/xiaokangwang/snowflake-mu-docker/blob/master/docker-compose.yaml
> - Should we have another more verbose level of log (debug/trace) so that it takes less effort to debug things in general? (no need to modify code then rebuilt like hazae41 did it https://hackerone.com/reports/1880610)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40264Add option to configure private snowflake proxy2023-03-28T18:36:08ZRendezvousPointAdd option to configure private snowflake proxyJust like obfs4 private bridges.Just like obfs4 private bridges.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40260Weird KCP packets received by the client2023-09-25T19:36:14ZCecylia BocovichWeird KCP packets received by the clientWe were notified by @hazae41 of some suspicious looking kcp traffic traffic arriving at the client. This traffic looks like it belongs to KCP sessions that do not correspond to the client's own KCP sessions.
I'm in the process of trying...We were notified by @hazae41 of some suspicious looking kcp traffic traffic arriving at the client. This traffic looks like it belongs to KCP sessions that do not correspond to the client's own KCP sessions.
I'm in the process of trying to reproduce this. Here is the patch they used to see the contents of the KCP packets:
<details>
<summary> kcp library logging patch </summary>
```diff
diff --git a/readloop.go b/readloop.go
index 697395a..1d8e17b 100644
--- a/readloop.go
+++ b/readloop.go
@@ -1,6 +1,7 @@
package kcp
import (
+ "log"
"sync/atomic"
"github.com/pkg/errors"
@@ -11,6 +12,7 @@ func (s *UDPSession) defaultReadLoop() {
var src string
for {
if n, addr, err := s.conn.ReadFrom(buf); err == nil {
+ log.Println("kcp <- ", buf)
// make sure the packet is from the same source
if src == "" { // set source address
src = addr.String()
```
</details>
and the following smux patch:
<details>
<summary> smux library logging patch </summary>
```diff
diff --git a/session.go b/session.go
index bc56066..1fe1122 100644
--- a/session.go
+++ b/session.go
@@ -96,7 +96,7 @@ func newSession(config *Config, conn io.ReadWriteCloser, client bool) *Session {
s.chProtoError = make(chan struct{})
if client {
- s.nextStreamID = 1
+ s.nextStreamID = 5
} else {
s.nextStreamID = 0
}
```
</details>
They report seeing smux headers that have a streamid of 3 regardless of the above change that starts stream ids at 5, and seeing kcp headers that do not contain recognizable kcp conv ids followed by a stream id of 3 and a TLS application packet (despite the fact that new KCP sessions should always contain a TLS handshake first since they represent a new OR conn).Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40258Resynchronization with Upsteamed Remove HelloVerify countermeasure2023-04-06T13:05:39ZshelikhooResynchronization with Upsteamed Remove HelloVerify countermeasureAs of https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249, we have finished upstreaming Remove HelloVerify countermeasure changes to upstream.
We should try to resynchronize our dependency wit...As of https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249, we have finished upstreaming Remove HelloVerify countermeasure changes to upstream.
We should try to resynchronize our dependency with upstream.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40256Standalone Snowflake proxy for Microsoft Windows2023-03-07T14:55:51ZRahim RollinsStandalone Snowflake proxy for Microsoft Windows> If you would like to run a command-line version of the Snowflake proxy on your **desktop** or server, see our guide for running a Snowflake standalone proxy.
[The "Standalone Snowflake proxy" page](https://community.torproject.org/rel...> If you would like to run a command-line version of the Snowflake proxy on your **desktop** or server, see our guide for running a Snowflake standalone proxy.
[The "Standalone Snowflake proxy" page](https://community.torproject.org/relay/setup/snowflake/standalone/) provides instructions for installing and configuring the CLI version of Snowflake proxy on Debian, Fedora, Arch Linux, FreeBSD and Ubuntu. However, most users (working on Windows) would be able to help other users bypass censorship without having to keep the browser running. Now this possibility is impossible for them. At least for such volunteers there is not even an instruction, unlike users of the operating systems listed above.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40249Upstreaming Remove HelloVerify countermeasure2023-03-03T11:45:36ZshelikhooUpstreaming Remove HelloVerify countermeasureWe have already released a version of snowflake with [Remove HelloVerify](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/134) [Orig](https://gitlab.torproject.org/tpo/anti-censorship/plu...We have already released a version of snowflake with [Remove HelloVerify](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/134) [Orig](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/131) countermeasure against Russia's censorship of snowflake. However, as we are currently applying the changes as a series of patch in the forked repo, this situation isn't ideal if that means we need to constantly rebase and maintain this fork.
Thus, we are currently seeking to upstream this change.
Changes to be upstreamed:
1. [DTLS](https://github.com/xiaokangwang/dtls/tree/dev-skiphelloverify) -> [Github Pull Request](https://github.com/pion/dtls/pull/513)
2. [WebRTC](https://github.com/xiaokangwang/webrtc/tree/dev-skiphelloverify) -> [Github Pull Request](https://github.com/pion/webrtc/pull/2407)
See Also: https://gitlab.torproject.org/tpo/applications/tor-browser-build/-/merge_requests/637shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40246Restart snowflake-server on snowflake-01 with num-turbotunnel=42023-07-18T00:47:29ZDavid Fifielddcf@torproject.orgRestart snowflake-server on snowflake-01 with num-turbotunnel=4We are hitting a performance ceiling at about 475 MiB/s TX. The CPUs are not fully saturated: they are averaging about 87%. Currently we have `num-turbotunnel=2`. I want to try increasing this to `num-turbotunnel=4` to see if the KCP sta...We are hitting a performance ceiling at about 475 MiB/s TX. The CPUs are not fully saturated: they are averaging about 87%. Currently we have `num-turbotunnel=2`. I want to try increasing this to `num-turbotunnel=4` to see if the KCP state machines are again a bottleneck.
Cf. #40200/!119 which effectively changed from `num-turbotunnel=1` to `num-turbotunnel=2`.
/cc @linus
![snowflake-01 bandwidth at eno1](/uploads/e50170475883f71f3d3306118dcbd2cd/snowflake-01-bw-20230107.png)David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40244TLS instead of DTLS (TLS Candidates for ICE)2023-01-11T12:28:49ZWofWcawofwca@protonmail.comTLS instead of DTLS (TLS Candidates for ICE)I was thinking about censors blocking DTLS, partially or completely (e.g. https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030), making it impossible to initiate a WebRTC p2p connection, so I thought maybe...I was thinking about censors blocking DTLS, partially or completely (e.g. https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40030), making it impossible to initiate a WebRTC p2p connection, so I thought maybe another protocol could be used. I reached out to the creator of the Pion library (the one that Snowflake uses) and he [told](https://gophers.slack.com/archives/CAK2124AG/p1671995560491059) me that [this draft](https://datatracker.ietf.org/doc/html/draft-martinsen-ice-tls-candidates-00) is probably what I want.
So, the idea: peers connect to each other with TLS, making DPI's job harder, because TLS is probably the last thing censors want to block, unlike DTLS, which offers relatively low collateral IMO.
Sean also said that it might already be implemented in libwebrtc, and that he's willing to add it to Pion.
So, I suggest to evaluate this idea and provide the Pion team the assistance we can offer, if we think that it's a good idea.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40229Proxy log scrubbing misses URL-encoded IPv6 addresses2022-11-28T20:58:21ZDavid Fifielddcf@torproject.orgProxy log scrubbing misses URL-encoded IPv6 addressesThe log scrubbing patterns (tpo/anti-censorship/pluggable-transports/snowflake#21304, tpo/anti-censorship/pluggable-transports/snowflake#40115)
miss IPv6 addresses in URLs, where `:` is encoded as `%3A` or `%3a`.
URLs like these may be l...The log scrubbing patterns (tpo/anti-censorship/pluggable-transports/snowflake#21304, tpo/anti-censorship/pluggable-transports/snowflake#40115)
miss IPv6 addresses in URLs, where `:` is encoded as `%3A` or `%3a`.
URLs like these may be logged in the case of HTTP errors.
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/merge_requests/55#note_2851695
> `error dialing relay: wss://snowflake.torproject.net/?client_ip=2001%3Adb8%3A4000%3A%3A1234 = dial tcp: lookup snowflake.torproject.net: no such host`https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40223Spread snowflake-01 bridges' tor traffic over several IP addresses2024-01-22T15:19:37ZRoger DingledineSpread snowflake-01 bridges' tor traffic over several IP addressesWe discussed a few days ago how 12 super active snowflake back-end bridges on one IP address could trigger the "too many connections plus too many circuits from one IP address" anti-ddos defenses at Tor relays.
I asked Linus if we can g...We discussed a few days ago how 12 super active snowflake back-end bridges on one IP address could trigger the "too many connections plus too many circuits from one IP address" anti-ddos defenses at Tor relays.
I asked Linus if we can get a few more IP addresses for snowflake-01, and he thinks it sounds doable.
(They don't even need to be the sort of addresses that can receive incoming connections. So they could in theory be outbound natted or something. If that's easier -- I suspect it does not make it easier. :)
So step one is that @Linus gets those addresses and adds them to the computer and says here what they are. I think 3 or 4 or 6 total addresses would be good, but even 2 would be a lot more than 1.
And then step two is that @dcf or somebody goes in to the torrc's of the bridges and configures each of them to use the right outbound IP address. This is done by setting the "outboundbindaddress" line in their torrc.
(And I guess step zero, which can happen at any point, is that somebody notices this is a poor idea and jumps in to explain why.)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40216Need documentation for utls-imitate and utls-nosni2023-03-10T15:28:13ZDavid Fifielddcf@torproject.orgNeed documentation for utls-imitate and utls-nosni!76 added support for uTLS in the client for broker rendezvous, using the SOCKS parameters `utls-imitate` and `utls-nosni`.
But I could not find documentation of these options.
They should be described in [client/README.md](client/README...!76 added support for uTLS in the client for broker rendezvous, using the SOCKS parameters `utls-imitate` and `utls-nosni`.
But I could not find documentation of these options.
They should be described in [client/README.md](client/README.md)
and the example client torrc, at least.
There also needs to be a listing somewhere of what values may be passed to `utls-imitate`.
I found the list of understood values in [common/utls/client_hello_id.go](common/utls/client_hello_id.go).
This list should also appear in client/README.md (manually maintained),
the `-help` output (automatically updated), or both.
This is the code in dnstt-client that lists the known fingerprints in `-help` output:
https://repo.or.cz/dnstt.git/blob/14a29048e4b659cb3113a7af37fbdb3349f13d37:/dnstt-client/main.go#l258
Its output looks like this:
```
Known TLS fingerprints for -utls are:
none Firefox Firefox_55 Firefox_56 Firefox_63 Firefox_65 Chrome
Chrome_58 Chrome_62 Chrome_70 Chrome_72 Chrome_83 iOS iOS_11_1
iOS_12_1
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40214standalone proxy: no connections since 2022/10/032022-10-15T14:33:26ZBeckersstandalone proxy: no connections since 2022/10/03I am running snowflake as an standalone proxy. It worked quite well until 2022/10/03 (according to the log file). Since then I get zero connections. Part of my logfile around a daily system restart:
```
2022/10/14 01:07:20 In the last 3...I am running snowflake as an standalone proxy. It worked quite well until 2022/10/03 (according to the log file). Since then I get zero connections. Part of my logfile around a daily system restart:
```
2022/10/14 01:07:20 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 01:37:20 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 01:49:27 error polling broker: read tcp [scrubbed]->[scrubbed]: read: connection reset by peer
2022/10/14 01:49:27 Error reading broker response: unexpected end of JSON input
2022/10/14 01:49:27 body:
2022/10/14 01:49:27 bad offer from broker
2022/10/14 02:00:18 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 02:00:18 starting
2022/10/14 02:00:18 WebRTC: Created offer
2022/10/14 02:00:18 WebRTC: Set local description
2022/10/14 02:00:18 Offer: {"type":"offer","sdp":"v=0\r\no=- 6893084309929587048 1665712818 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 BF:6A:76:02:37:8A:96:A4:6C:16:12:16:F5:40:86:65:F7:06:85:92:9D:3E:D7:8C:85:60:85:85:54:5C:37:ED\r\na=group:BUNDLE 0\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 [scrubbed]\r\na=setup:actpass\r\na=mid:0\r\na=sendrecv\r\na=sctp-port:5000\r\na=ice-ufrag:nhTnpZRAsoeUmxTh\r\na=ice-pwd:RLJbOGidLOUkKOLjDPXTUpWDbrRmWIgn\r\na=candidate:4056006514 1 udp 2130706431 [scrubbed] 43420 typ host\r\na=candidate:4056006514 2 udp 2130706431 [scrubbed] 43420 typ host\r\na=candidate:1367571592 1 udp 1694498815 [scrubbed] 43757 typ srflx raddr [scrubbed] rport 43757\r\na=candidate:1367571592 2 udp 1694498815 [scrubbed] 43757 typ srflx raddr [scrubbed] rport 43757\r\na=candidate:1309294897 1 udp 2130706431 [scrubbed] 43290 typ host\r\na=candidate:1309294897 2 udp 2130706431 [scrubbed] 43290 typ host\r\na=end-of-candidates\r\n"}
2022/10/14 02:00:44 NAT Type measurement: unknown -> restricted = restricted
2022/10/14 02:00:44 NAT type: restricted
2022/10/14 02:00:44 WebRTC: Created offer
2022/10/14 02:00:44 WebRTC: Set local description
2022/10/14 02:00:44 Offer: {"type":"offer","sdp":"v=0\r\no=- 1174260446418312236 1665712844 IN IP4 [scrubbed]\r\ns=-\r\nt=0 0\r\na=fingerprint:sha-256 71:98:09:F4:C4:3F:FB:78:58:26:0E:A8:E3:25:4F:E7:36:F4:E1:96:55:40:9E:8A:F2:8C:EC:53:04:7D:5F:E1\r\na=group:BUNDLE 0\r\nm=application 9 UDP/DTLS/SCTP webrtc-datachannel\r\nc=IN IP4 [scrubbed]\r\na=setup:actpass\r\na=mid:0\r\na=sendrecv\r\na=sctp-port:5000\r\na=ice-ufrag:YQHqUMIrLPzrDWPO\r\na=ice-pwd:KVyewBeBGOZfJJXmHKTJBNxwjVadqxkj\r\na=candidate:4056006514 1 udp 2130706431 [scrubbed] 40071 typ host\r\na=candidate:4056006514 2 udp 2130706431 [scrubbed] 40071 typ host\r\na=candidate:1367571592 1 udp 1694498815 [scrubbed] 50127 typ srflx raddr [scrubbed] rport 50127\r\na=candidate:1367571592 2 udp 1694498815 [scrubbed] 50127 typ srflx raddr [scrubbed] rport 50127\r\na=candidate:1309294897 1 udp 2130706431 [scrubbed] 55970 typ host\r\na=candidate:1309294897 2 udp 2130706431 [scrubbed] 55970 typ host\r\na=end-of-candidates\r\n"}
2022/10/14 02:01:41 NAT Type measurement: restricted -> restricted = restricted
2022/10/14 02:30:50 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
2022/10/14 03:00:50 In the last 30m0s, there were 0 connections. Traffic Relayed ↑ 0 B, ↓ 0 B.
```
The planned restart takes place at 02:00 GMT. I don't know whether the error at 01:49 has any meaning. Broker seems to be 37.218.245.111 (greenhost.nl).