Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2021-07-09T18:26:26Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/18627Run a separate websocket server reporting the transport as "snowflake"2021-07-09T18:26:26ZArlo BreaultRun a separate websocket server reporting the transport as "snowflake"> > > Also, maybe we also need to spin up a pretty much identical but separate websocket server, to more easily measure the number of snowflake proxies available?
> > >
> > If we wanted to purely count Snowflake users, does it make sense...> > > Also, maybe we also need to spin up a pretty much identical but separate websocket server, to more easily measure the number of snowflake proxies available?
> > >
> > If we wanted to purely count Snowflake users, does it make sense to spin up another websocket server and maybe label it as "snowflake" instead? Is there anything special we need to do to get it displayed on the metrics website?
> >
> This is what we should do. (I meant to do it already...) It will be a websocket server but will record users as snowflake.David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/18628Devise some way for the browser proxy to forward metadata to the bridge befor...2023-08-01T19:33:11ZArlo BreaultDevise some way for the browser proxy to forward metadata to the bridge before the OR data> > What does a user in that graph refer to? A connection from a unique ip? Part of the Flashproxy/Snowflake model is that the proxies will be ephemeral (and hard to block) so a single user session may rotate through several proxies, cor...> > What does a user in that graph refer to? A connection from a unique ip? Part of the Flashproxy/Snowflake model is that the proxies will be ephemeral (and hard to block) so a single user session may rotate through several proxies, corresponding to several unique ips. I can imagine that messing with the numbers.
>>
> Connections from multiple ephemeral IP address won't cause a problem for counting the total number of users. As Karsten says, that figure is driven by clients' consensus downloads, which aren't related to the specifics of the connection.
>
> What *will* get messed up is if we report the proxy IP addresses as if they were client IP addresses. Then we'll be counting the countries of the browser proxies, not of real users. My thinking was that for the time being, we just ignore that issue by not reporting an IP address through the ExtORPort. I.e.,
>
```
pt.DialOr(&ptInfo, "", "snowflake")
// https://godoc.org/git.torproject.org/pluggable-transports/goptlib.git#DialOr
```
>
> In this way, we will not get per-country info, but the total number of snowflake users will be correct.
>
> In order to report true client IP addresses, we will need to devise some way for the browser proxy to forward that metadata to the bridge before the OR data.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/18653Copy-paste not working in snowflake client (global webrtcRemote is uninitiali...2021-07-09T18:26:26ZDavid Fifielddcf@torproject.orgCopy-paste not working in snowflake client (global webrtcRemote is uninitialized)The copy-paste rendezvous doesn't work in [6efb5cb8](https://gitweb.torproject.org/pluggable-transports/snowflake.git/log/?id=6efb5cb8ef56bc84a56a8244f81a0817d7202912). The `readSignalingMessages` goroutine panics because the global `web...The copy-paste rendezvous doesn't work in [6efb5cb8](https://gitweb.torproject.org/pluggable-transports/snowflake.git/log/?id=6efb5cb8ef56bc84a56a8244f81a0817d7202912). The `readSignalingMessages` goroutine panics because the global `webrtcRemote` is `nil` at [client/snowflake.go:142](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/snowflake.go?id=6efb5cb8ef56bc84a56a8244f81a0817d7202912#n142):
```
webrtcRemote.answerChannel <- sdp
```
`git bisect` says [b8815627](https://gitweb.torproject.org/pluggable-transports/snowflake.git/commit/?id=b8815627bd189c3ee0829ce09152684726c6933c) "defer conn.Close for simplicity and remove unnecessary goroutines, improve error handling (close !legacy/trac#12)" is the first bad commit.
I'm using the copy-paste rendezvous because I want to test a server locally for legacy/trac#18627.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/18999go-webrtc: fixes for 3862021-07-09T18:26:25ZDavid Fifielddcf@torproject.orggo-webrtc: fixes for 386In preparing a Gitian build of Snowflake for linux-386, I ran into architecture problems that are fixed by the attached patch.
The first just adds a webrtc-linux-386.pc, like already existed for linux-amd64 and darwin-amd64.
The second...In preparing a Gitian build of Snowflake for linux-386, I ran into architecture problems that are fixed by the attached patch.
The first just adds a webrtc-linux-386.pc, like already existed for linux-amd64 and darwin-amd64.
The second reduces the size of some static Cgo array bounds, to avoid this error:
```
configuration.go:228[/tmp/go-build928087590/github.com/keroserene/go-webrtc/_obj/configuration.cgo1.go:238]: type [1073741824]*_Ctype_char larger than address space
```https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/20813Start producing snowflakes2023-08-01T19:29:39ZArlo BreaultStart producing snowflakesOnce `snowflake-client` gets in the alpha Tor Browser builds (tpo/applications/tor-browser#20735), we're going to have some unhappy users if we don't have a sufficient number of proxies available.
We should start ramping up production a...Once `snowflake-client` gets in the alpha Tor Browser builds (tpo/applications/tor-browser#20735), we're going to have some unhappy users if we don't have a sufficient number of proxies available.
We should start ramping up production asap.
Some ideas in,<br>
https://github.com/glamrock/cupcake<br>
https://github.com/keroserene/snowflake/issues/30
We probably also want to close out the opt-in issue,<br>
https://github.com/keroserene/snowflake/issues/21Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21304Sanitize snowflake.log2023-08-01T23:17:12ZArlo BreaultSanitize snowflake.logFor starters, the timestamps are in the local timezone. We can make that UTC
See also legacy/trac#19026
Known problems:
* The client logs full SDP stanzas, which include local IP addresses.
* When the websocket server panics (as in ...For starters, the timestamps are in the local timezone. We can make that UTC
See also legacy/trac#19026
Known problems:
* The client logs full SDP stanzas, which include local IP addresses.
* When the websocket server panics (as in legacy/trac#29125), it writes the client IP address to the log:
{{{
2019/01/18 18:56:29 http2: panic serving X.X.X.X:YYYY: interface conversion: *http2.responseWriter is not http.Hijacker: missing method Hijack
}}}
* The websocket server logs an IP address on certain connection errors. (These are probably automated scanners, but still...)
{{{
2019/04/01 07:02:50 http: TLS handshake error from X.X.X.X:YYYY: acme/autocert: missing server name
2019/04/01 07:53:03 http: TLS handshake error from X.X.X.X:YYYY: tls: oversized record received with length 21536
}}}
* The broker logs the raw bytes of ICE answers:
{{{
2019/03/22 06:28:32 Received answer: [XXX XXX XXX XXX ... XXX]
}}}Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21305Client gets into an unrecoverable connect / close loop2021-07-09T18:26:25ZArlo BreaultClient gets into an unrecoverable connect / close loopThis was after briefly losing internet connectivity. It was just endlessly repeating this pattern. We tried giving it a new proxy to connect to but with no luck. Restarting the client immediately resolved the issue, so it seems to hav...This was after briefly losing internet connectivity. It was just endlessly repeating this pattern. We tried giving it a new proxy to connect to but with no luck. Restarting the client immediately resolved the issue, so it seems to have got itself into a bad state.
```
2017/01/24 13:35:12 ---- Handler: closed ---
2017/01/24 13:35:12 SOCKS listening...
2017/01/24 13:35:12 SOCKS accepted: {0.0.3.0:1 map[]}
2017/01/24 13:35:14 WebRTC: Collecting a new Snowflake. Currently at [0/1]
2017/01/24 13:35:14 snowflake-61xONPqOrMQ67aWl connecting...
2017/01/24 13:35:14 WebRTC: PeerConnection created.
2017/01/24 13:35:14 WebRTC: OnNegotiationNeeded
2017/01/24 13:35:14 WebRTC: DataChannel created.
2017/01/24 13:35:14 candidate:4096217215 1 udp 2122260223 192.168.1.154 40594 typ host generation 0 ufrag ko968AKONjQ/Rpya network-id 1
2017/01/24 13:35:14 candidate:1970230987 1 udp 1686052607 108.16.226.229 40594 typ srflx raddr 192.168.1.154 rport 40594 generation 0 ufrag ko968AKONjQ/Rpya network-id 1
2017/01/24 13:35:14 candidate:3131354255 1 tcp 1518280447 192.168.1.154 53340 typ host tcptype passive generation 0 ufrag ko968AKONjQ/Rpya network-id 1
2017/01/24 13:35:14 WebRTC: OnIceComplete
2017/01/24 13:35:14 Negotiating via BrokerChannel...
Target URL: snowflake-reg.appspot.com
Front URL: www.google.com
2017/01/24 13:35:14 BrokerChannel Response:
200 OK
2017/01/24 13:35:14 Received Answer:
v=0
o=mozilla...THIS_IS_SDPARTA-51.0 6797456362141212310 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 A8:2C:FA:1D:33:46:8F:57:5D:56:AC:5C:EF:32:B5:8D:8E:2C:A5:FD:8E:33:6E:88:DD:5F:CC:4A:8B:02:BA:64
a=ice-options:trickle
a=msid-semantic:WMS *
m=application 38953 DTLS/SCTP 5000
c=IN IP4 88.159.72.23
a=candidate:0 1 UDP 2122252543 88.159.72.23 38953 typ host
a=sendrecv
a=end-of-candidates
a=ice-pwd:acc3c9ec8efb8d0a16a500203da69560
a=ice-ufrag:6cb61e26
a=mid:data
a=sctpmap:5000 webrtc-datachannel 256
a=setup:active
a=ssrc:2244974687 cname:{c72775ac-0151-48b1-9063-0922a11994e6}
2017/01/24 13:35:14 ---- Handler: snowflake assigned ----
2017/01/24 13:35:14 Buffered 218 bytes --> WebRTC
2017/01/24 13:35:14 WebRTC: DataChannel.OnOpen
2017/01/24 13:35:14 Flushed 218 bytes.
2017/01/24 13:35:16 Traffic Bytes (in|out): 749 | 218 -- (1 OnMessages, 1 Sends)
2017/01/24 13:35:23 Traffic Bytes (in|out): 4803 | 3907 -- (8 OnMessages, 7 Sends)
2017/01/24 13:35:24 WebRTC: At capacity [1/1] Retrying in 10 seconds...
2017/01/24 13:35:34 WebRTC: At capacity [1/1] Retrying in 10 seconds...
2017/01/24 13:35:44 WebRTC: At capacity [1/1] Retrying in 10 seconds...
2017/01/24 13:35:49 WebRTC: No messages received for 30 seconds -- closing stale connection.
2017/01/24 13:35:49 WebRTC: closing DataChannel
2017/01/24 13:35:49 WebRTC: DataChannel.OnClose [locally]
2017/01/24 13:35:49 WebRTC: closing PeerConnection
2017/01/24 13:35:49 WebRTC: Closing
2017/01/24 13:35:49 copy loop ended
```Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21312Memory and file descriptor leaks in programs that use go-webrtc2022-03-16T15:45:50ZArlo BreaultMemory and file descriptor leaks in programs that use go-webrtc```
1:30:49 AM - arma5: 2017/01/24 18:57:44 candidate:3131354255 1 tcp 1518280447 192.168.1.154 36729 typ host tcptype passive generation 0 ufrag YXKXffPBBnA3SJ3K network-id 1
1:30:52 AM - arma5: this is the last line in its log
1:31:20 ...```
1:30:49 AM - arma5: 2017/01/24 18:57:44 candidate:3131354255 1 tcp 1518280447 192.168.1.154 36729 typ host tcptype passive generation 0 ufrag YXKXffPBBnA3SJ3K network-id 1
1:30:52 AM - arma5: this is the last line in its log
1:31:20 AM - arma5: and snowflake-client is pegged at 100% cpu
1:32:39 AM - arma5: % strace -p3074
1:32:39 AM - arma5: Process 3074 attached
1:32:39 AM - arma5: futex(0x1059710, FUTEX_WAIT, 0, NULL
```Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21748Snowflake breaks nightly builds as of March 152023-04-01T17:44:34ZGeorg KoppenSnowflake breaks nightly builds as of March 15Our nightly builds are broken now due to Snowflake compilation being unhappy:
```
+ go install github.com/keroserene/go-webrtc
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-lin...Our nightly builds are broken now due to Snowflake compilation being unhappy:
```
+ go install github.com/keroserene/go-webrtc
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
../../go/src/github.com/keroserene/go-webrtc/peerconnection.cc:13:51: fatal error: webrtc/pc/test/fakeaudiocapturemodule.h: No such file or directory
compilation terminated.
```Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21954Snowflake breaks the 7.0a3 build2022-07-09T04:20:15ZGeorg KoppenSnowflake breaks the 7.0a3 buildBuilding Snowflake breaks our 7.0a3 build with the following error:
```
+ mkdir -p /home/debian/go/src/github.com/keroserene/
+ ln -sf /home/debian/build/go-webrtc /home/debian/go/src/github.com/keroserene/go-webrtc
+ CGO_CXXFLAGS='-D_GL...Building Snowflake breaks our 7.0a3 build with the following error:
```
+ mkdir -p /home/debian/go/src/github.com/keroserene/
+ ln -sf /home/debian/build/go-webrtc /home/debian/go/src/github.com/keroserene/go-webrtc
+ CGO_CXXFLAGS='-D_GLIBCXX_USE_CXX11_ABI=1 -D__STDC_FORMAT_MACROS=1'
+ CGO_LDFLAGS=-latomic
+ go install github.com/keroserene/go-webrtc
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
# github.com/keroserene/go-webrtc
<command-line>:0:0: warning: "_GLIBCXX_USE_CXX11_ABI" redefined
<command-line>:0:0: note: this is the location of the previous definition
# github.com/keroserene/go-webrtc
/home/debian/install/binutils/bin/ld.gold.real: error: ../../go/src/github.com/keroserene/go-webrtc/lib/libwebrtc-linux-386-magic.a(dump_syms_regtest.o): unsupported ELF file type 2
collect2: error: ld returned 1 exit status
```
I double-checked that the commits I am on are the same as in the patch for legacy/trac#21748. Furthermore, I made a `make clean-webrtc` and the build started with `tbb-7.0a3-build3`.
There are actually two issues here:
1) We need to unblock the 7.0a3 build as soon as possible as we want to release the first ESR52-based Tor Browser alpha next week.
2) I'd like to understand how this can happen at all given that we did not change the commits compared to the fix in legacy/trac#21748 and I tested that the building worked back then. I somehow doubt that arlolra and I made the same mistake (by using the wrong commit or something).
I need to have a fix for that within the next 24 hours, otherwise do I need to disable Snowflake in the alphas.Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/23209When I opened Tor Launcher and changed my pluggable transport to snowflake a ...2022-07-09T04:20:15ZTracWhen I opened Tor Launcher and changed my pluggable transport to snowflake a message from my firewall popped upWhen I opened Tor Launcher and changed my pluggable transport to snowflake a message from my firewall popped up, it said "do you want to allow snowflake-client to allow incoming connections", some users may be concerned because this mess...When I opened Tor Launcher and changed my pluggable transport to snowflake a message from my firewall popped up, it said "do you want to allow snowflake-client to allow incoming connections", some users may be concerned because this message has never popped up when using Tor Browser Bundle.
TBB 7.5a4
**Trac**:
**Username**: Dbryrtfbcbhgfhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/23257Snowflake doesn't connect on the CalVisitor network2022-07-09T04:20:15ZDavid Fifielddcf@torproject.orgSnowflake doesn't connect on the CalVisitor networkSnowflake doesn't work on [one of the wireless networks](https://telecom.berkeley.edu/calvisitor) at UC Berkeley. It sends an offer and receives an answer, but then hangs here:
```
2017/08/16 13:56:38 ---- Handler: snowflake assigned ---...Snowflake doesn't work on [one of the wireless networks](https://telecom.berkeley.edu/calvisitor) at UC Berkeley. It sends an offer and receives an answer, but then hangs here:
```
2017/08/16 13:56:38 ---- Handler: snowflake assigned ----
2017/08/16 13:56:38 Buffered 203 bytes --> WebRTC
2017/08/16 13:56:43 Traffic Bytes (in|out): 0 | 203 -- (0 OnMessages, 1 Sends)
```
I initially suspected that it had something to do with the network not assigning a public IPv4 address, only a public IPv6 address. I moved our existing proxy-go instances to a host with an IPv6 address, and that didn't help.
Here's the part of the log where client gathers its candidates. Notice the IPv6 address 2607:f140:6000:2:c53e:4d3e:19d5:d94c and the IPv4 address 10.105.136.190.
```
2017/08/16 13:55:58 WebRTC: DataChannel created.
2017/08/16 13:55:58 candidate:1109156821 1 udp 2122262783 2607:f140:6000:2:c53e:4d3e:19d5:d94c 56748 typ host generation 0 ufrag 3h4p network-id 2 network-cost 50
2017/08/16 13:55:58 candidate:2027054270 1 udp 2122194687 10.105.136.190 61395 typ host generation 0 ufrag 3h4p network-id 1 network-cost 50
2017/08/16 13:55:58 candidate:211787557 1 tcp 1518283007 2607:f140:6000:2:c53e:4d3e:19d5:d94c 49259 typ host tcptype passive generation 0 ufrag 3h4p network-id 2 network-cost 50
2017/08/16 13:55:58 candidate:911317070 1 tcp 1518214911 10.105.136.190 49260 typ host tcptype passive generation 0 ufrag 3h4p network-id 1 network-cost 50
2017/08/16 13:55:59 SOCKS accepted: {0.0.3.0:1 map[]}
```
Here's an abridged form of the answer. Notice how the candidates (`a=candidate:`) include both IPv6 2a00:c6c0:0:151:4:8f94:69f5:7c01 and IPv4 37.218.242.151. However, the connection address (`c=`) is the IPv4 address.
```
o=- 5000276783403536546 2 IN IP4 127.0.0.1
m=application 41242 DTLS/SCTP 5000
c=IN IP4 37.218.242.151
a=candidate:836092752 1 udp 2122262783 2a00:c6c0:0:151:4:8f94:69f5:7c01 40571 typ host generation 0 network-id 1 network-cost 50
a=candidate:404726760 1 udp 2122194687 37.218.242.151 41242 typ host generation 0 network-id 2 network-cost 50
a=candidate:2136358816 1 tcp 1518283007 2a00:c6c0:0:151:4:8f94:69f5:7c01 39103 typ host tcptype passive generation 0 network-id 1 network-cost 50
a=candidate:1453088536 1 tcp 1518214911 37.218.242.151 49703 typ host tcptype passive generation 0 network-id 2 network-cost 50
```
Is this one of those weird NAT cases where a TURN server is needed? Is that why it's not working? The CalVisitor does block some applications like IMAP.
I tested this with Tor Browser 7.5a4 for mac.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25429Need something better than client's `checkForStaleness`2023-08-01T23:54:09ZArlo BreaultNeed something better than client's `checkForStaleness`If no message has been received on the datachannel on the client for `SnowflakeTimeout` (30 seconds), `checkForStaleness` closes the connection. The comment says this is to,
> // Prevent long-lived broken remotes.
but there's no hear...If no message has been received on the datachannel on the client for `SnowflakeTimeout` (30 seconds), `checkForStaleness` closes the connection. The comment says this is to,
> // Prevent long-lived broken remotes.
but there's no heartbeat at this level of abstraction so the connection is constantly being reset anytime the user pauses their activity (for example, to read a webpage).
This greatly exacerbated legacy/trac#21312Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25688proxy-go is still deadlocking occasionally2022-07-09T04:20:16ZDavid Fifielddcf@torproject.orgproxy-go is still deadlocking occasionallyThe three fallback proxy-go instances are still hanging, after variable delays of a few days. This is even after removing all memory restrictions I discussed in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowf...The three fallback proxy-go instances are still hanging, after variable delays of a few days. This is even after removing all memory restrictions I discussed in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/21312#note_2591535.
The more heavily used instances seem to deadlock sooner. Those for the currently used broker would be more likely to stop than those for the standalone broker. But the ones for the standalone broker would stop too.
In the meantime, I've put the fallback proxies back on periodic restarts. Before the intervals were 1h,2h,10h; now I increased them to 17h,23h,29h (prime numbers, so the average time before the next restart is < 17h).
I'll update this ticket with a graph showing uptimes when I have time.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/27385https://snowflake.torproject.org/embed is confusing2022-07-09T04:20:15Zcypherpunkshttps://snowflake.torproject.org/embed is confusing`embed.html` should be the go to for embedding snowflake badges in webpages but it currently has a couple of problems,
1. No description, nothing to suggest to the lambda visitor about what to do.
2. Clicking on the badge redirects to ...`embed.html` should be the go to for embedding snowflake badges in webpages but it currently has a couple of problems,
1. No description, nothing to suggest to the lambda visitor about what to do.
2. Clicking on the badge redirects to the options page hosted in torproject.org, but this means that users who have first-party isolation manually enabled (as can be done in Firefox) won't be able to enable it on the page where embed.html is embedded.
Ideally what should be done is:
1. Small description ("Do you want to help censored users access the Tor network?") with a snowflake logo.
2. If user clicks on yes, then in that same iframe there's some JS check to see if WebRTC is disabled, if it is inform the user that WebRTC is necessary and perhaps add a link on how to enable it back.
3. If WebRTC is enabled, then load up snowflake.js and modernizr.js. Description should contain if the connection to the broker is done and is waiting for a client request, and if it is then maybe the logo should change as well as the description. (Since everything is done on the same page then there won't be any problems with first party isolation -- except with 3rd party cookies disabled)
Ideally it should be easy to embed into webpages if what's above is done, and should be small enough.
(cc'ing antonela of the ux-team for her opinions :)Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40103mix of past and present in snowflake proxy log2022-07-09T04:20:15Ztoralfmix of past and present in snowflake proxy log"In the last 1h0m0s, there are 28 connections. Traffic Relayed ↑ 273 MB, ↓ 273 MB."
are -> were
or ?"In the last 1h0m0s, there are 28 connections. Traffic Relayed ↑ 273 MB, ↓ 273 MB."
are -> were
or ?https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/29861Snowflake is not working right now for some reason2021-07-09T18:26:25ZcypherpunksSnowflake is not working right now for some reasonCecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31200Hand out proxy-go snowflakes more frequently than webextension snowflakes2022-07-25T17:59:44ZCecylia BocovichHand out proxy-go snowflakes more frequently than webextension snowflakesWe're now seeing several volunteers running both proxy-go instances and webextension Snowflake proxies (yay!). However, throughout the course of my dogfooding, it seems the quality of the connections has degraded and I get frequent disco...We're now seeing several volunteers running both proxy-go instances and webextension Snowflake proxies (yay!). However, throughout the course of my dogfooding, it seems the quality of the connections has degraded and I get frequent disconnects. This requires more investigation, but I suspect the higher ratio of web extension proxies is part of the reason.
Right now we can tell the difference between the two because of the length of the ids. I propose prioritizing the handout of proxy-go instances in the short term until the root of this problem is more thoroughly investigated.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31201Allow webextension users to specify how many resources it uses2021-07-09T18:26:26ZCecylia BocovichAllow webextension users to specify how many resources it usesI'm not sure what the default behaviour for webrtc connections is, but we should allow users to throttle or set a bandwidth cap on their connections to avoid over-using their resources.I'm not sure what the default behaviour for webrtc connections is, but we should allow users to throttle or set a bandwidth cap on their connections to avoid over-using their resources.Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31391Do a reachability check before polling for clients2023-11-12T02:27:25ZcypherpunksDo a reachability check before polling for clientsI'm looking at https://trac.torproject.org/projects/tor/attachment/ticket/29461/example_metrics.log and I've seen one `TR=2` and another `TR=5` record. I'm not aware of the current situation in TR but as far as I remember Tor was censore...I'm looking at https://trac.torproject.org/projects/tor/attachment/ticket/29461/example_metrics.log and I've seen one `TR=2` and another `TR=5` record. I'm not aware of the current situation in TR but as far as I remember Tor was censored there (it is even stated in the Torlauncher).
We can have a snowflake do a reachability check of the bridge(s) and broker (and maybe Tor domains/dirauths) before trying to poll for clients. If this check fails, we should display a user-facing error message or warning and hold off on polling while the bridge is unreachableArlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31407Create a broker spec for metrics collection2020-07-14T22:23:11ZCecylia BocovichCreate a broker spec for metrics collectionWe're in the process of creating a module for the collection of snowflake metrics (legacy/trac#21315, legacy/trac#29461). We need a better place to put the spec for the metrics data output by the snowflake broker than a comment in the so...We're in the process of creating a module for the collection of snowflake metrics (legacy/trac#21315, legacy/trac#29461). We need a better place to put the spec for the metrics data output by the snowflake broker than a comment in the source code (see https://trac.torproject.org/projects/tor/ticket/29461#comment:5)
A spec for the broker will also be useful to expand upon later to specify how the broker interacts with other pieces of either Snowflake or the Tor ecosystem in the case that the broker assumes more of the responsibilities of BridgeDB.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31425Snowflake broker is sluggish and sometimes fails2022-07-09T04:20:15ZCecylia BocovichSnowflake broker is sluggish and sometimes failsThis morning while trying to deploy a change I noticed that my SSH connection is extremely sluggish.
I'm also getting a lot of timeouts at the client:
```
2019/08/16 15:37:54 Negotiating via BrokerChannel...
Target URL: snowflake-broke...This morning while trying to deploy a change I noticed that my SSH connection is extremely sluggish.
I'm also getting a lot of timeouts at the client:
```
2019/08/16 15:37:54 Negotiating via BrokerChannel...
Target URL: snowflake-broker.azureedge.net
Front URL: ajax.aspnetcdn.com
2019/08/16 15:38:05 BrokerChannel Response:
504 Gateway Timeout
2019/08/16 15:38:05 BrokerChannel Error: Unexpected error, no answer.
2019/08/16 15:38:05 Failed to retrieve answer. Retrying in 10 seconds
```
Some requests go through, but the timeouts seem to be occurring more frequently. At first glance, this doesn't seem to be a CPU or memory resources consumption problem. Maybe there's a data transfer limit we're hitting?David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/31902Add a short FAQ to snowflake.tp.o2021-07-09T18:26:26ZArlo BreaultAdd a short FAQ to snowflake.tp.oThis should include explanations for the missing feature error messages. See comment:13:ticket:31391This should include explanations for the missing feature error messages. See comment:13:ticket:31391https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/32576Fix race condition in snowflake broker2022-07-09T04:20:15ZCecylia BocovichFix race condition in snowflake brokerThere is a race condition with the snowflake heap that has been causing the broker to crash several times a day. This race condition has existed in the broker for several years, but some recent updates as well as the host migration manag...There is a race condition with the snowflake heap that has been causing the broker to crash several times a day. This race condition has existed in the broker for several years, but some recent updates as well as the host migration managed to shake it loose.
----
This race condition is causing the snowflake broker to crash repeatedly and often since the migration. We noticed because CollecTor stopped collecting metrics since the restart on 14 November 2019.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33112snowflake-webextension "Could not connect to the bridge."2021-07-09T18:26:25Zcypherpunkssnowflake-webextension "Could not connect to the bridge."My snowflake webextension has been working well up to this point but recently started having the error "Could not connect to the bridge." for the past few days. I'm not sure if this is something on my end or something with Snowflake.My snowflake webextension has been working well up to this point but recently started having the error "Could not connect to the bridge." for the past few days. I'm not sure if this is something on my end or something with Snowflake.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33211proxy-go sometimes gets into a 100+% CPU state2021-07-09T18:26:26ZDavid Fifielddcf@torproject.orgproxy-go sometimes gets into a 100+% CPU stateproxy-go sometimes works itself into a state where it is still running and working, but using more than 100% CPU. I have had it happen locally a couple of times while testing turbotunnel stuff, and it's currently happening with proxy-go-...proxy-go sometimes works itself into a state where it is still running and working, but using more than 100% CPU. I have had it happen locally a couple of times while testing turbotunnel stuff, and it's currently happening with proxy-go-restartless:
```
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
13844 snowfla+ 20 0 551292 320692 8844 R 161.1 15.6 129356:18 proxy-go
```
Or looking at single threads:
```
$ top -H
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24628 snowfla+ 20 0 551292 320692 8844 R 39.7 15.6 15219:01 proxy-go
13844 snowfla+ 20 0 551292 320692 8844 R 35.4 15.6 15431:52 proxy-go
1637 snowfla+ 20 0 551292 320692 8844 R 34.8 15.6 16057:40 proxy-go
13848 snowfla+ 20 0 551292 320692 8844 S 27.5 15.6 13669:02 proxy-go
13846 snowfla+ 20 0 551292 320692 8844 S 22.5 15.6 17021:57 proxy-go
```
I caught it once and attached to the process with GDB, but didn't know what to make of it. `thread apply all bt` seemed to show all the threads being somewhere in the Go runtime; the thread that wasn't was not one of the threads using a lot of CPU. (Matching up the `PID` field from `top -H` with the `LWP` identifiers in gdb.)
I had the idea to make proxy-go emit profiling output, and then exmine the call chain that was resulting the in the most CPU using [profiling tools](https://blog.golang.org/profiling-go-programs). A patch to do that is [proxy-go-profile.patch.](None/proxy-go-profile.patch.) But I haven't been able to reproduce the high CPU usage yet.Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33365Probe Snowflake bridge from proxy 1x a day2021-07-09T18:26:25ZCecylia BocovichProbe Snowflake bridge from proxy 1x a dayWe're getting reports that the Snowflake bridge isn't reachable in legacy/trac#33364, but it's taking awhile for volunteers to notice because the probe check only happens once at installation or if you disable/enable the proxy.
Perhaps ...We're getting reports that the Snowflake bridge isn't reachable in legacy/trac#33364, but it's taking awhile for volunteers to notice because the probe check only happens once at installation or if you disable/enable the proxy.
Perhaps we can do the probe check 1x a day (e.g., when we do the stats refresh)?Arlo BreaultArlo Breaulthttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33367Goroutine leak in websocketconn2022-07-09T04:20:16ZDavid Fifielddcf@torproject.orgGoroutine leak in websocketconnThinking about legacy/trac#33364, I found that snowflake-server is chewing a lot of memory. It may be some memory leak or something.
```
$ top -o%MEM
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26910 debi...Thinking about legacy/trac#33364, I found that snowflake-server is chewing a lot of memory. It may be some memory leak or something.
```
$ top -o%MEM
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
26910 debian-+ 20 0 1916628 1.522g 0 S 0.0 77.8 58:51.37 snowflake-serve
```
The memory use seems to be inhibiting other processes. `runsvdir` puts status messages in its own `argv` so you can inspect them with `ps`. Currently it's reflecting `xz` not being able to allocate memory to compress logs:
```
$ ps ax | grep runsvdir
1358 ? Ss 94:01 runsvdir -P /etc/service log: locate memory \
svlogd: warning: processor failed, restart: /home/snowflake-proxy/snowflake-proxy-standalone-17h.log.d xz: (stdin): Cannot allocate memory \
svlogd: warning: processor failed, restart: /home/snowflake-proxy/snowflake-proxy-standalone-17h.log.d xz: (stdin): Cannot allocate memory \
svlogd: warning: processor failed, restart: /home/snowflake-proxy/snowflake-proxy-standalone-17h.log.d
```
I even got it just now trying to run a diagnostic command (it doesn't always happen):
```
$ ps ax | grep standal
-bash: fork: Cannot allocate memory
```
In the short term, looks like we need to restart the server. Then we need to figure out what's causing it to use so much memory.
The server was last restarted 2020-02-10 18:57 (one week ago) at [ca9ae12c383405bc9a755e1bc902e9755495c1f1](https://gitweb.torproject.org/pluggable-transports/snowflake.git/log/?id=ca9ae12c383405bc9a755e1bc902e9755495c1f1) for legacy/trac#32964.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33401turbotunnel-quic snowflake-client occasionally uses lots of CPU2022-07-09T04:20:15ZDavid Fifielddcf@torproject.orgturbotunnel-quic snowflake-client occasionally uses lots of CPUAs originally noted at comment:7:ticket:33211, the quic-go turbotunnel client sometimes uses 100+% CPU for a few minutes before returning to normal operation. It is specific to the quic-go implementation; it doesn't happen with the kcp-g...As originally noted at comment:7:ticket:33211, the quic-go turbotunnel client sometimes uses 100+% CPU for a few minutes before returning to normal operation. It is specific to the quic-go implementation; it doesn't happen with the kcp-go implementation nor the non-turbotunnel client.
As best I can figure, the cause has something to do with timers created under `(*session) maybeResetTimer`.
[profile001.png](None/profile001.png)David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33519Support multiple simultaneous SOCKS connections2022-03-14T05:36:27ZDavid Fifielddcf@torproject.orgSupport multiple simultaneous SOCKS connectionsThe Snowflake client accepts multiple simultaneous SOCKS connections from tor, but it only tries to collect one proxy at a time, and each proxy can service only one SOCKS connection (this is true in the turbotunnel branch as well). One o...The Snowflake client accepts multiple simultaneous SOCKS connections from tor, but it only tries to collect one proxy at a time, and each proxy can service only one SOCKS connection (this is true in the turbotunnel branch as well). One of the SOCKS connections gets the only available proxy, while the others starve.
I can think of a few ways to approach this.
1. Dynamically adjust the `max` parameter according to how many SOCKS connections there are currently. If there's one SOCKS connection, we need only one proxy. If there's another SOCKS connection, raise the limit to allow the proxy-collecting thread to pick up another one, and lower the limit again if the number of SOCKS connections drops back down.
2. Start up a separate proxy-collecting thread for each SOCKS connection, as suggested at comment:12:ticket:21314. Each SOCKS connection will make its own broker requests and collect its own proxies, not interacting with those of any other SOCKS connection. A downside of this is that the number of Snowflake proxies you are contacting leaks the number of SOCKS connections you have ongoing. (Which can also be seen as a benefit in that if there are zero SOCKS connections, you don't even bother to contact the broker.)
3. Make it possible for multiple SOCKS connections to share the same proxy. Continue using a global proxy-collecting thread, and make there be a single shared `RedialPacketConn` instead of a separate one for each SOCKS connection. As things work now, this would require tagging _every packet_ with the ClientID, instead of [sending the ClientID once](https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/snowflake.go?h=turbotunnel&id=47312dd1eccc8456652853bd66f8ed396e9ba6ec#n52) and letting it be the same implicitly for all packets that follow.
4. Make it possible for multiple SOCKS connections to share the same proxy, and use a single KCP/QUIC connection for all SOCKS connections. Separate SOCKS connections go into separate streams within the KCP/QUIC connection. In other words, rather than doing both `sess = kcp.NewConn2/quic.Dial` and `sess.OpenStream` in the SOCKS handler, we do `sess = kcp.NewConn2/quic.Dial` in `main` and then `sess.OpenStream` in the SOCKS handler. This way we could continue tagging the ClientID just once, because the program would only ever work with one ClientID at a time. However this way would make it harder to do the "stop using the network when not being used" of legacy/trac#21314, because that single KCP/QUIC connection would try to keep itself alive all the time and would contact the broker every time it needed a new proxy. Perhaps we could make it so that if there are zero streams, we close the KCP/QUIC connection, and lazily create a new one if and when we get another SOCKS connection.
| |= status quo=|= 1=|= 2=|= 3=|= 4=|
|---------------------------|--------------|--------------|--------------|--------------|--------------|
|= proxy-collecting threads=| one global| one global| one per SOCKS| one global| one global|
|= proxy limit per thread=| 1| # of SOCKS| 1| 1| 1|
|= proxies shared between SOCKSes?=| dedicated| dedicated| dedicated| shared| shared|
|= `PacketConn`s=| one per SOCKS| one per SOCKS| one per SOCKS| one global| one global|
|= KCP/QUIC connections=| one per SOCKS| one per SOCKS| one per SOCKS| one per SOCKS| one global|
|= KCP/QUIC streams=| one per SOCKS| one per SOCKS| one per SOCKS| one per SOCKS| one per SOCKS|
|= ClientID on every packet?=| no| no| no| yes| no|https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/33744Remove local LAN address ICE candidates from JS proxy answer2021-07-09T18:26:25ZArlo BreaultRemove local LAN address ICE candidates from JS proxy answerThis is a follow up from legacy/trac#19026 where it was done for the clients and golang proxies.This is a follow up from legacy/trac#19026 where it was done for the clients and golang proxies.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/34080Avoid double delays from ReconnectTimeout2022-07-09T04:20:16ZDavid Fifielddcf@torproject.orgAvoid double delays from ReconnectTimeout[ReconnectTimeout](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/lib/snowflake.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n18) is used in 2 places:
* In [exchangeSDP](https://gitweb.torproject.org/plug...[ReconnectTimeout](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/lib/snowflake.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n18) is used in 2 places:
* In [exchangeSDP](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/lib/webrtc.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n223), where it is a delay inserted between calls to `broker.Negotiate` until one of them succeeds.
`Failed to retrieve answer. Retrying in 10s`
* In the main [ConnectLoop](https://gitweb.torproject.org/pluggable-transports/snowflake.git/tree/client/snowflake.go?id=72cfb96edeb7c9a3c93d38539bc31a51e30dbe8d#n27), where it is a delay inserted between every check for getting a new snowflake.
```
WebRTC: <errmsg> Retrying in 10s...
```
The broker itself also terminates requests after 10s when the chosen proxy doesn't respond: `BrokerChannel Response: 504 Gateway Timeout`.
This situation sometimes results in double delays. Here are two cases I've identified.
* The client requests a proxy, the broker responds immediately with an answer, but the proxy doesn't work. After waiting the `DataChannelTimeout` to decide that the proxy doesn't work, the client waits an _additional_ `ReconnectTimeout` in `ConnectLoop`.
Here, I've set `DataChannelTimeout` to 10s. Notice that between `DataChannel created` and `Collecting a new Snowflake` there are 20s (which is `DataChannelTimeout` + `ReconnectTimeout`), when it really should only be 10s.
```
2020/04/30 22:38:29 Received Answer.
2020/04/30 22:38:29 WebRTC: DataChannel created.
2020/04/30 22:38:39 establishDataChannel: timeout waiting for DataChannel.OnOpen
2020/04/30 22:38:39 WebRTC: closing PeerConnection
2020/04/30 22:38:39 WebRTC: Closing
2020/04/30 22:38:39 WebRTC: WebRTC: Could not establish DataChannel Retrying in 10s...
2020/04/30 22:38:49 WebRTC: Collecting a new Snowflake. Currently at [0/1]
```
* The client requests a proxy, and the broker waits for 10s to respond with a 504 Gateway Timeout (indicating that the chosen proxy did not return an answer to the broker in time). The client waits 10s for the broker to respond, then waits another `ReconnectTimeout` in exchangeSDP before trying the broker again.
```
2020/04/30 22:39:30 Negotiating via BrokerChannel...
2020/04/30 22:39:41 BrokerChannel Response: 504 Gateway Timeout
2020/04/30 22:39:41 BrokerChannel Error: Unexpected error, no answer.
2020/04/30 22:39:41 Failed to retrieve answer. Retrying in 10s
2020/04/30 22:39:51 Negotiating via BrokerChannel...
```
Both these cases can probably be fixed by running the timer in parallel with the periodic operation they are rate limiting. That is, instead of
```
for {
operation()
<-time.After(ReconnectTimeout)
}
```
it can be
```
for {
timer := time.After(ReconnectTimeout)
operation()
<-timer
}
```
That way, if the operation itself takes more than 10s, `ReconnectTimeout` doesn't impose any additional delay.Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/34147Remove redundant languages from snowflake page2021-07-09T18:26:26ZRoger DingledineRemove redundant languages from snowflake pagehttps://snowflake.torproject.org/
offers me en, en_GB, and en_US in the language drop-down menu. We should have one English, not three.
More generally, I bet we have a policy somewhere about which languages we want to be sure to include...https://snowflake.torproject.org/
offers me en, en_GB, and en_US in the language drop-down menu. We should have one English, not three.
More generally, I bet we have a policy somewhere about which languages we want to be sure to include when we have translated something, and we should see if we're missing any of those; and also I hope we have a policy about which languages to *not* include (and ideally we should go back to transifex and remove those from the set that people can translate, to avoid giving people the impression that they will be doing something useful if they e.g. translate en_US to en_GB).
I'm sorry I don't know more -- I bet Emma or Antonela or Gus will know more about whether we have languages policies and habits in place. :)https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/34435Update bug-reporting links for gitlab2021-07-09T18:26:25ZDavid Fifielddcf@torproject.orgUpdate bug-reporting links for gitlabAfter the [gitlab migration](https://lists.torproject.org/pipermail/tor-project/2020-June/002866.html) we need to update bug-reporting instructions.
* https://snowflake.torproject.org/#bugs<br>
https://gitweb.torproject.org/pluggabl...After the [gitlab migration](https://lists.torproject.org/pipermail/tor-project/2020-June/002866.html) we need to update bug-reporting instructions.
* https://snowflake.torproject.org/#bugs<br>
https://gitweb.torproject.org/pluggable-transports/snowflake-webext.git/tree/static/index.html?h=webext-0.3.1&id=d2a9a8fd136ac6bbba393de3d51fb7ca85e17b8a#n75
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/wikis/home#reporting-bugs
I checked in snowflake.git and did not find anything that needs to be changed.Gabagaba@torproject.orgGabagaba@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40088Snowflake server keeps failing unexpectedly2022-07-09T04:20:46ZCecylia BocovichSnowflake server keeps failing unexpectedlyThe snowflake server has failed twice now in the last two weeks.
[After the first failure](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40060#note_2767868), we upgraded the capacity of the Sn...The snowflake server has failed twice now in the last two weeks.
[After the first failure](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40060#note_2767868), we upgraded the capacity of the Snowflake bridge (#40085).
Today when it failed we received an alert from monit: https://lists.torproject.org/pipermail/anti-censorship-alerts/2021-December/000786.html
Unfortunately, in my rush to fix it I didn't check the CPU usage :/ let's use this ticket to track the issue and note what we notice the next time it occurs.Sponsor 96: Rapid Expansion of Access to the Uncensored Internet through Tor in China, Hong Kong, & Tibetshelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40058Snowflake embed refuses to work on Chromium?2022-07-09T04:20:16ZkoutsieSnowflake embed refuses to work on Chromium?Snowflake (embed) simply refuses to enable on Chromium and Chrome.
At first i thought it was one of my extensions but a couple of friends reported the inability to enable Snowflake's embed while stating that the web extension version wor...Snowflake (embed) simply refuses to enable on Chromium and Chrome.
At first i thought it was one of my extensions but a couple of friends reported the inability to enable Snowflake's embed while stating that the web extension version works fine.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40098snowflake_server.httpHandler.ln is not initialized, leading to panic in onesh...2022-07-09T04:20:16ZDavid Fifielddcf@torproject.orgsnowflake_server.httpHandler.ln is not initialized, leading to panic in oneshotModeThere are a few of these in the snowflake-server log:
```
2022/02/01 16:44:11 http: panic serving [scrubbed]: runtime error: invalid memory address or nil pointer dereference
goroutine 2513699 [running]:
net/http.(*conn).serve.func1(0xc...There are a few of these in the snowflake-server log:
```
2022/02/01 16:44:11 http: panic serving [scrubbed]: runtime error: invalid memory address or nil pointer dereference
goroutine 2513699 [running]:
net/http.(*conn).serve.func1(0xc007576dc0)
/usr/lib/go-1.15/src/net/http/server.go:1801 +0x147
panic(0x7ea7a0, 0xb0c450)
/usr/lib/go-1.15/src/runtime/panic.go:975 +0x47a
git.torproject.org/pluggable-transports/snowflake.git/v2/server/lib.(*SnowflakeListener).queueConn(0x0, 0x8dc820, 0xc04b943740, 0xc03557fbb0, 0xc04b9436e0)
./snowflake/server/lib/snowflake.go:275 +0x37
git.torproject.org/pluggable-transports/snowflake.git/v2/server/lib.oneshotMode(...)
./snowflake/server/lib/http.go:117
git.torproject.org/pluggable-transports/snowflake.git/v2/server/lib.(*httpHandler).ServeHTTP(0xc0001a0e80, 0x8d9800, 0xc057a75880, 0xc0dda2cd00)
./snowflake/server/lib/http.go:105 +0x5b7
net/http.serverHandler.ServeHTTP(0xc0001ee0e0, 0x8d9800, 0xc057a75880, 0xc0dda2cd00)
/usr/lib/go-1.15/src/net/http/server.go:2843 +0xa3
net/http.(*conn).serve(0xc007576dc0, 0x8da1c0, 0xc013b86b00)
/usr/lib/go-1.15/src/net/http/server.go:1925 +0x8ad
created by net/http.(*Server).Serve
/usr/lib/go-1.15/src/net/http/server.go:2969 +0x36c
```
`oneshotMode` is called with `httpHandler.ln` as the `*SnowflakeListener` argument:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/e828b0607662c7325f4d1bbf4c5072ce81f38fb9/server/lib/http.go#L100-105
```go
// We didn't find a matching token, which means that we are
// dealing with a client that doesn't know about such things.
// "Unread" the token by constructing a new Reader and pass it
// to the old one-session-per-WebSocket mode.
conn2 := &overrideReadConn{Conn: conn, Reader: io.MultiReader(bytes.NewReader(token[:]), conn)}
err = oneshotMode(conn2, addr, handler.ln)
```
`httpHandler` is:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/e828b0607662c7325f4d1bbf4c5072ce81f38fb9/server/lib/http.go#L63-68
```go
type httpHandler struct {
// pconn is the adapter layer between stream-oriented WebSocket
// connections and the packet-oriented KCP layer.
pconn *turbotunnel.QueuePacketConn
ln *SnowflakeListener
}
```
But in the only place `httpHandler` is instantiated, its `ln` field is left uninitialized:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/e828b0607662c7325f4d1bbf4c5072ce81f38fb9/server/lib/snowflake.go#L80-85
```go
handler := httpHandler{
// pconn is shared among all connections to this server. It
// overlays packet-based client sessions on top of ephemeral
// WebSocket connections.
pconn: turbotunnel.NewQueuePacketConn(addr, clientMapTimeout),
}
```Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40135Cannot build snowflake/proxy2022-07-09T04:20:15ZcypherpunksCannot build snowflake/proxyHello! I want to install the snowflake proxy on my raspberry pi, but I can't seem to build it. I updated my system via apt-get update/update succesfully and the installation of git and golang were also successful. But after cloning the ...Hello! I want to install the snowflake proxy on my raspberry pi, but I can't seem to build it. I updated my system via apt-get update/update succesfully and the installation of git and golang were also successful. But after cloning the git, I went to /home/pi/snowflake/proxy and when I enter go build the system gives me this:
```
pi@raspberrypi:~/snowflake/proxy $ go build
main.go:5:2: cannot find package "git.torproject.org/pluggable-transports/snowflake.git/v2/common/event" in any of:
/usr/lib/go-1.7/src/git.torproject.org/pluggable-transports/snowflake.git/v2/common/event (from $GOROOT)
($GOPATH not set)
main.go:12:2: cannot find package "git.torproject.org/pluggable-transports/snowflake.git/v2/common/safelog" in any of:
/usr/lib/go-1.7/src/git.torproject.org/pluggable-transports/snowflake.git/v2/common/safelog (from $GOROOT)
($GOPATH not set)
main.go:13:2: cannot find package "git.torproject.org/pluggable-transports/snowflake.git/v2/proxy/lib" in any of:
/usr/lib/go-1.7/src/git.torproject.org/pluggable-transports/snowflake.git/v2/proxy/lib (from $GOROOT)
($GOPATH not set)
```
What is the problem here, and how can I fix it? Whe I look into /usr/lib/go-1.7/src/ there is no git.torproject.org subdirectory
I hope, you can help me.itchyonionitchyonion