Snowflake issueshttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues2023-01-06T12:58:15Zhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40030Increase number of proxies available for restricted clients2023-01-06T12:58:15ZCecylia BocovichIncrease number of proxies available for restricted clientsIt looks like our solution to #33666 has solved the connectivity issues for clients behind restricted NATs, but we still have a relatively small number of unrestricted proxies available for restricted clients.
See the counts of proxy by...It looks like our solution to #33666 has solved the connectivity issues for clients behind restricted NATs, but we still have a relatively small number of unrestricted proxies available for restricted clients.
See the counts of proxy by type:
![proxy_types](/uploads/0edc55334e2fdeef8e295a18e7850377/proxy_types.png)
And a close-up on the counts of unrestricted proxies:
![unrestricted_proxies](/uploads/1be8466c9dd85144196606fc2c22b47a/unrestricted_proxies.png)
So, we're making progress! But, I'm still seeing a lot of restricted clients getting turned away at the broker because there were no available proxies. Here's a plot of the times a restricted client failed to be matched with a snowflake:
![unmatches](/uploads/cefc6c1067d3d78a62064ab59da4ea41/unmatches.png)
For reference, November (when we start seeing the spikes) was around the time we rolled out our remote probe test and started correctly classifying browser-based proxies. This both increased the amount of unrestricted proxies we had, but also decreased the number of unknown proxies we had. The end result for restricted clients (since they are handed either unknown or unrestricted proxies), is that while each proxy they get is more likely to work for them, the pool of proxies they can pull from is greatly reduced.
The spikes themselves are interesting. Some days we don't get any denied counts and some days we get way more than I'd expect. We almost surely need more unrestricted proxies, but it would also be useful to get some more metrics on what proportion of successful matches are for unrestricted vs restricted clients, and how many times a restricted client has to poll to get a working proxy.
So this ticket is both for measurements, but I also think we should try to run some reliable proxy-go instances that have unrestricted NATs.Snowflake in Tor Browser 10.5Cecylia BocovichCecylia Bocovichhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40131Unix socket support.2023-01-05T17:20:17ZcheakoUnix socket support.I usually want to have nginx reverse proxy over Unix sockets. Otherwise, there are strange fw rules for "random" port numbers.
For both the websocket to tor server and the broker.I usually want to have nginx reverse proxy over Unix sockets. Otherwise, there are strange fw rules for "random" port numbers.
For both the websocket to tor server and the broker.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40242Order of parameters may suppress other parameters2023-01-03T16:00:26Zn0tooseOrder of parameters may suppress other parameters### Steps to reproduce
- `snowflake-proxy -broker https://snowflake-broker.torproject.net/ -capacity 10 -nat-retest-interval 24h -relay wss://snowflake.bamsoftware.com/ -stun stun:stun.stunprotocol.org:3478 -summary-interval 1s -verbose...### Steps to reproduce
- `snowflake-proxy -broker https://snowflake-broker.torproject.net/ -capacity 10 -nat-retest-interval 24h -relay wss://snowflake.bamsoftware.com/ -stun stun:stun.stunprotocol.org:3478 -summary-interval 1s -verbose true -keep-local-addresses false` prints a summary once every second. Works fine.
- `snowflake-proxy -broker https://snowflake-broker.torproject.net/ -capacity 10 -keep-local-addresses false -nat-retest-interval 24h -relay wss://snowflake.bamsoftware.com/ -stun stun:stun.stunprotocol.org:3478 -summary-interval 1s -verbose true` prints a summary once every hour, ignoring the summary-interval argument. I wrote it that way, as that was the order in `snowflake-proxy -help`.
This was attempted in a Docker container running on Debian Bookworm.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25596Configure TURN servers for the proxy and/or client2022-12-20T20:57:52ZArlo BreaultConfigure TURN servers for the proxy and/or client> This may require spinning up our own TURN servers somewhere.
>
>> In most cases, the public ip candidates given by STUN servers are sufficient for peers to negotiate a working p2p path. But sometimes, maybe 14% of the time [1], this is...> This may require spinning up our own TURN servers somewhere.
>
>> In most cases, the public ip candidates given by STUN servers are sufficient for peers to negotiate a working p2p path. But sometimes, maybe 14% of the time [1], this isn't enough -- usually due to symmetric NAT / lack of port preservation, and a TURN relay is required as a last resort.
>>
>> Also, once snowflake proxies & clients are multiplexed, perhaps the likelihood that TURN continuous to be absolutely required for every pair of peers greatly decreases and we might be fine again. More thought is needed here.
\\ Migrated from https://github.com/keroserene/snowflake/issues/18https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40238Server versionFlag duplicates -unsafe-logging option, causes immediate panic2022-12-14T17:20:49ZDavid Fifielddcf@torproject.orgServer versionFlag duplicates -unsafe-logging option, causes immediate panicRecent versions of the Snowflake server (e.g. 839d2218837dfbd1682ff39b375f45660b3974b5) panic immediately on startup:
```
snowflake/server$ ./server
./server flag redefined: unsafe-logging
panic: ./server flag redefined: unsafe-logging...Recent versions of the Snowflake server (e.g. 839d2218837dfbd1682ff39b375f45660b3974b5) panic immediately on startup:
```
snowflake/server$ ./server
./server flag redefined: unsafe-logging
panic: ./server flag redefined: unsafe-logging
```
The cause is a copy-paste error at https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/commit/33248f3dec5594c985cfd11e6c6143ddaa5613c0#2bfd4afce737f8dc3bb3ba69c068895274dac4e5_140_142,
which was part of !111.
The option name should have been `"version"`, but it duplicates `"unsafe-logging"` instead.
```go
flag.BoolVar(&unsafeLogging, "unsafe-logging", false, "prevent logs from being scrubbed")
flag.BoolVar(&versionFlag, "unsafe-logging", false, "display version info to stderr and quit")
```itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40189snowflake-01: Disable conntrack2022-12-13T20:25:17ZLinus Nordberglinus@torproject.orgsnowflake-01: Disable conntrackBased on output from perf(1) we should disable conntrack. We would have to deal with that regardless, since we're running out of slots in the conntrack table.Based on output from perf(1) we should disable conntrack. We would have to deal with that regardless, since we're running out of slots in the conntrack table.Linus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40230fix: send SDP answer if ICE gathering is taking long to complete2022-12-13T16:59:46ZWofWcawofwca@protonmail.comfix: send SDP answer if ICE gathering is taking long to completeSee https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/merge_requests/55. Probably need to implement it here as well (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake...See https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/merge_requests/55. Probably need to implement it here as well (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/merge_requests/55#note_2851693).
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40164 has the same title, but suggests a different approach, maybe close then this in favor of that.
Also I think it's best if we can still send the `end-of-candidates` marker in the SDP so that the remote peer knows not to expect any more ICE candidates.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40192Experiment with bypassing extor-static-cookie on snowflake-012022-12-12T01:03:33ZDavid Fifielddcf@torproject.orgExperiment with bypassing extor-static-cookie on snowflake-01The [12](tpo/anti-censorship/pluggable-transports/snowflake#40176) extor-static-cookie processes
collectively use about 300% of a CPU core (25% each).
We can open up some CPU headroom by cutting them out of the pipeline—but
then we need ...The [12](tpo/anti-censorship/pluggable-transports/snowflake#40176) extor-static-cookie processes
collectively use about 300% of a CPU core (25% each).
We can open up some CPU headroom by cutting them out of the pipeline—but
then we need another way doing static ExtORPort authentication.
https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000253.html
> For CPU pressure, I don't see any quick fixes. In an emergency, we could
> hack the tor binary to use a static ExtORPort authentication cookie, and
> remove the extor-static-cookie shim from the pipeline.
There's also the idea that the extra localhost communication required by
extor-static-cookie is a cause of the current performance bottleneck.
https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000263.html
> First, let's patch tor to get rid of the extor processes, as suggested
> by David earlier when discussing RAM pressure. This should bring down
> context switches.
Cf. [Two features that would help load-balanced bridges](https://lists.torproject.org/pipermail/tor-dev/2022-February/014695.html).
As a preliminary test to see if removing extor-static-cookie actually has an effect,
this issue is to try bypassing extor-static-cookie and having haproxy connect directly
to the "regular" ORPort of the tor processes.
The downside of this is that we will not be counting transport- and country-specific
metrics while the experiment is in place.
But it should take only a few hours maximum to see if it has an effect.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40237client suggested torrc does not suggest utls-imitate2022-12-09T23:08:29ZRoger Dingledineclient suggested torrc does not suggest utls-imitatehttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/client/torrc
no longer matches the snowflake bridge line in Tor Browser.
In particular, the utls-imitate line in not present in the recommended...https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/client/torrc
no longer matches the snowflake bridge line in Tor Browser.
In particular, the utls-imitate line in not present in the recommended example torrc file.
[Discovered while helping a user in iran who was running snowflake + tor directly rather than inside Tor Browser]https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40179Reduce turbotunnel queueSize from 2048 to 5122022-12-08T15:04:48ZDavid Fifielddcf@torproject.orgReduce turbotunnel queueSize from 2048 to 512After yesterday's deployment of `io.Copy` memory mitigations (tpo/anti-censorship/pluggable-transports/snowflake#40177), memory use has crept up above 90% again.
I recommend implementing the [next most effective memory save](https://list...After yesterday's deployment of `io.Copy` memory mitigations (tpo/anti-censorship/pluggable-transports/snowflake#40177), memory use has crept up above 90% again.
I recommend implementing the [next most effective memory save](https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000253.html)
revealed by [profiling](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40086#note_2837328): decreasing the turbotunnel `queueSize`.
This is a fixed block of memory that's allocated per connected client.
In https://gitlab.torproject.org/dcf/snowflake/-/commit/328f0f4137145c08e58311888ad359362abaea79
I've reduced the parameter from 2048 to 512.
I don't know what effect this might have on performance,
apart from reducing memory use.
Past discussion about `queueSize`:
* https://lists.torproject.org/pipermail/anti-censorship-team/2021-July/000188.html
* https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/48#note_2744619David Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-09-27https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40224utls RoundTripper does not work when it is supposed to use HTTP/12022-12-06T14:17:27ZDavid Fifielddcf@torproject.orgutls RoundTripper does not work when it is supposed to use HTTP/1Try setting `utls=hellorandomizednoalpn` in the bridge line. snowflake-client's rendezvous will fail with:
```
WebRTC: incorrect ALPN negotiated Retrying...
```
Lack of ALPN should cause a fallback to HTTP/1, and the connection should ...Try setting `utls=hellorandomizednoalpn` in the bridge line. snowflake-client's rendezvous will fail with:
```
WebRTC: incorrect ALPN negotiated Retrying...
```
Lack of ALPN should cause a fallback to HTTP/1, and the connection should still work. What's going wrong.
The problem is the internal `connectWithH1` map, which is inconsistently keyed. Entries are written to the map with `host:port` keys. Entries are read from the map using sometimes `host:port` keys, and sometimes `host` keys.
* [`RoundTrip`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/v2.3.1/common/utls/roundtripper.go#L64) calls gets its domain name from `req.URL.Host`; i.e., it uses a key like `"cdn.sstatic.net"`.
* [`dialOrGetTLSWithExpectedALPN`](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/v2.3.1/common/utls/roundtripper.go#L124) gets its domain name from an `addr` argument to `DialTLS`; i.e., it uses a key like `"cdn.sstatic.net:443"`.
Adding a few debugging logs makes it clear what is going wrong:
```
2022/10/21 23:26:48 Target URL: snowflake-broker.torproject.net.global.prod.fastly.net
2022/10/21 23:26:48 Front URL: cdn.sstatic.net
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net") -> false
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net:443") -> false
2022/10/21 23:26:48 setShouldConnectWithH1("cdn.sstatic.net:443")
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net") -> false
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net:443") -> true
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net") -> false
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net:443") -> true
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net") -> false
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net:443") -> true
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net") -> false
2022/10/21 23:26:48 getShouldConnectWithH1("cdn.sstatic.net:443") -> true
2022/10/21 23:26:48 WebRTC: closing DataChannel
2022/10/21 23:26:48 WebRTC: closing PeerConnection
2022/10/21 23:26:48 WebRTC: Closing
2022/10/21 23:26:48 WebRTC: incorrect ALPN negotiated Retrying...
```shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40208"./proxy -h" does not show default value of a -capacity parameter2022-12-04T17:19:49Zslrslr"./proxy -h" does not show default value of a -capacity parameterHello at
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tree/main/proxy
"proxy -h"
Regarding “-capacity” parameter it would be handy to know what value is used when i do not use the -capacity switch.Hello at
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/tree/main/proxy
"proxy -h"
Regarding “-capacity” parameter it would be handy to know what value is used when i do not use the -capacity switch.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40031Improve instructions on how to to set up snowflake standalone proxy and add t...2022-12-04T16:44:53ZLhayamImprove instructions on how to to set up snowflake standalone proxy and add to Tor community portalSnowflake standalone proxy is such an effortless and easy way to contribute, it deserves more straight forward and more prominently placed documentation I think. Contrary to the web- and browser extension, it also covers volunteers which...Snowflake standalone proxy is such an effortless and easy way to contribute, it deserves more straight forward and more prominently placed documentation I think. Contrary to the web- and browser extension, it also covers volunteers which are running headless, or are just hesitant to run WebRTC in their browsers.
--- edit ---
Adding a checklist here so we can keep track of the work that should be done:
- [x] Update https://snowflake.torproject.org to point to community documentation
- [ ] The building from source instructions are not clear
- [ ] include instructions for go1.11
- [x] Update the README for `/proxy` in the git repository to include build instructions and point to community pages for running the proxy
- [ ] Some info for how to keep the proxy up to date (this actually should be discussed and completed for #32677)
- [ ] Some instructions on checking Snowflake logs
- [ ] How to check that it is working
- [ ] How to see how much bandwidth it is using
--- end edit ---
Couple of points/ideas:
The existing instructions on how to set up the GOPATH will leave many users with a more or less broken system, since the majority of distros don't use `bash_profile`, but `.profile`. After creating `.bash_profile`, `.profile` will [not be read any more](https://www.gnu.org/savannah-checkouts/gnu/bash/manual/bash.html#Bash-Startup-Files), and all what's configured after copy- and pasting the commands, is the GOPATH, which is ..bad.
On every semi updated installation, setting the GOPATH is not even necessary, beginning with the release of go-1.8 (2017) it will default to $HOME/go when no other path is specified. Since a lot of users will run go for the first time when setting up snowflake proxy, checking if $GOPATH exists and if it doesn't, exporting the GOPATH _temporarily_ for the shell might be a good idea still (?).
Use variables, like `mkdir -p "$GOPATH/src"`, to make the guide more universal.
How about offering a simple setup.sh (maybe that's another ticket though)?
Everybody who has some understanding of their system will know a way how to auto start snowflake at boot, there's no reason to alienate less technical inclined users with torproject's specific runit configuration.
Tell the user where to run the command to start the proxy. At least on go versions < 1.16 (Q1 2020, Debian stable is on 1.11 for reference), neither `$GOPATH/bin` nor `$GOPATH/src/snowflake/proxy/proxy` is in PATH by default, so just executing `nohup ./proxy &` will blatantly fail.
Tell the user how to save logs, since lack of feedback whether snowflake is doing as intended or not might discourage users.
Provide instructions on how to update. Personally I've a start-up script running which checks for updates every time snowflake is started, but even a manual approach will do.https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40173Increase number of tor instances from 4 to 8 on snowflake-01 bridge2022-12-03T20:40:46ZDavid Fifielddcf@torproject.orgIncrease number of tor instances from 4 to 8 on snowflake-01 bridgeBackground:
https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000247.html
The current 4 tor instances on the snowflake-01 bridge are saturated near 100% CPU since yesterday, due to increased usage. (Right now th...Background:
https://lists.torproject.org/pipermail/anti-censorship-team/2022-September/000247.html
The current 4 tor instances on the snowflake-01 bridge are saturated near 100% CPU since yesterday, due to increased usage. (Right now the bridge is at about 200 MB/s outgoing, 140 MB/s incoming.) We need to increase the number of instances.
I am a bit worried that 8 instances will permit more traffic than the hardware of the bridge will permit. I'll watch the performance and be prepared to step it back to 6.
While making the change, also increase `clientIDAddrMapCapacity` because snowflake-server is reporting constant "no address in clientID-to-IP map (capacity 10240)". Previous issue: #40084.
/cc @linusDavid Fifielddcf@torproject.orgDavid Fifielddcf@torproject.org2022-09-23https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40204pion errors don't go into the log2022-12-03T13:45:30ZRoger Dingledinepion errors don't go into the logMy snowflake proxy tells me, I guess on either stdout or stderr,
```
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0...My snowflake proxy tells me, I guess on either stdout or stderr,
```
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
sctp ERROR: 2022/10/03 13:47:32 [0xc002986380] stream 1 not found)
```
but I am using -log, and these lines don't show up in the log. It is unexpected that "error" category messages would be the ones that are transient and not captured for posterity.
(Also, the timestamps in the log seem to be utc, and the timestamps on my stdout/stderr appear to be local timezone. Not sure if that merits a separate ticket -- let me know if yes and I can open it.)Linus Nordberglinus@torproject.orgLinus Nordberglinus@torproject.orghttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40160Snowflake stops working after large size tests (v2.1.0)2022-11-30T17:16:47ZitchyonionSnowflake stops working after large size tests (v2.1.0)
> Snowflake, after some of the large message size tests, suddenly stopped being able to send/receive. The race app was still running, but starting/stopping the deployment seemed to fix the issue.
Fairly sure this is the culprit: https...
> Snowflake, after some of the large message size tests, suddenly stopped being able to send/receive. The race app was still running, but starting/stopping the deployment seemed to fix the issue.
Fairly sure this is the culprit: https://github.com/RACECAR-GU/plugin/blob/snowflake-rc-2.1.0/source/TA2Plugin.go#L180
```go
func (connection *ta2ConnUnicast) Write(msg []byte) error {
conn, dialErr := connection.ClientFactory.Dial()
if dialErr != nil {
logError("Error Connecting to Send Socket: ", dialErr.Error())
return dialErr
}
// We can't just close this connection right away before it gets a chance to send
//FIXME: This is a kludge
//go func() {
// <-time.After(5 * time.Minute)
// conn.Close()
//}()
// Send Message to Socket
_, writeErr := conn.Write(msg)
if writeErr != nil {
logError("Error Writing Message to Send Socket: ", writeErr.Error())
}
return writeErr
}
```
`connection.ClientFactory.Dial()` is basically the same as defined [here.](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/client/lib/snowflake.go#L157)
Is there an easy way to properly close this `conn` that you can think of? @shelikhoo @meskio
Here's from my previous discussion with @cohosh
```
<cohosh> the reason we can't close the connection when this function terminates is that conn.Write() is not a blocking call here
<cohosh> so that will return before the message is actually written
<cohosh> and in some cases, it takes a few minutes to write the message to the connection'
<cohosh> so if we close the connection before the message has been received by the other side, the message will never be sent
```
```
The best thing to do is implement some higher level connection management/connection caching logic.
So that we're reusing connections when multiple messages are sent to the same destination(s).
```Sponsor 28: Reliable Anonymous Communication Evading Censors and Repressors (RACECAR)itchyonionitchyonionhttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40220Close stale connections in standalone proxy2022-11-29T14:20:34ZCecylia BocovichClose stale connections in standalone proxyWe've received several reports (#40211) of standalone proxies that have long-lived connections with clients but zero bytes transferred. The browser-based snowflake proxies (i.e., the web extension and badge) have a [timeout in place to c...We've received several reports (#40211) of standalone proxies that have long-lived connections with clients but zero bytes transferred. The browser-based snowflake proxies (i.e., the web extension and badge) have a [timeout in place to close stale connections](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/blob/29a4cc6e0970f2e10ed610b8ae8449eafe75472c/proxypair.js#L163) after [30 seconds](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake-webext/-/blob/29a4cc6e0970f2e10ed610b8ae8449eafe75472c/config.js#L38) of inactivity. This aligns with a [client-side timeout](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/ac8562803ab9621d037bd1b3710c59799c7aa6d5/client/lib/snowflake.go#L49) that closes stale connections to proxies after 20s of inactivity.
It's possible that the long-lived connections these standalone proxies are seeing are from clients not using our snowflake client code. Or that the client-side closures are not being received by the proxies. In any case, we should add an inactivity timeout to the standalone proxies to try and clean up these connections and free up resources in a similar way that the browser-based proxies do.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/40212Deploy Secondary Bridge's definition on Snowflake Broker2022-11-22T15:34:33ZshelikhooDeploy Secondary Bridge's definition on Snowflake BrokerWe should be ready to include the definition of [secondary bridge](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40122) on to the broker.
This would allow users with new client to connect to ...We should be ready to include the definition of [secondary bridge](https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40122) on to the broker.
This would allow users with new client to connect to the secondary bridge on the production pool.
- [x] Assign a `*snowflake.torproject.net` domain name to the secondary bridge.
- [x] Update broker definition.shelikhooshelikhoohttps://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40185overflow in bandwidth reporting2022-11-21T15:34:42Ztrinity-1686aoverflow in bandwidth reportingA user reported on `#tor` they see strange bandwidth report on their snowflake proxy.
![image](/uploads/2840f9598f1d194a89058c04a84023e4/image.png)
It looks very much like an overflowed signed 32b integer. They use snowflake on raspber...A user reported on `#tor` they see strange bandwidth report on their snowflake proxy.
![image](/uploads/2840f9598f1d194a89058c04a84023e4/image.png)
It looks very much like an overflowed signed 32b integer. They use snowflake on raspberry pi 3 (64 bit), however I've heard more than one time of things going 32b on raspberries, so may be reproducible only in 32b mode