[tor-bugs] #33336 [Circumvention/Snowflake]: Deploy a Turbo Tunnel–aware Snowflake bridge
Tor Bug Tracker & Wiki
blackhole at torproject.org
Thu Feb 20 18:04:09 UTC 2020
#33336: Deploy a Turbo Tunnel–aware Snowflake bridge
-------------------------------------+--------------------------
Reporter: dcf | Owner: dcf
Type: task | Status: accepted
Priority: Medium | Milestone:
Component: Circumvention/Snowflake | Version:
Severity: Normal | Resolution:
Keywords: turbotunnel | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------+--------------------------
Comment (by dcf):
My observations from running the quic and kcp browsers more or less
continuously since yesterday.
* The experience is still pretty hit or miss. Sometimes you get a good
proxy and cruise on it for a while; other times you get delays of several
minutes caused by a series of non-working proxies—not slow proxies, but
ones that never send any downstream data at all. I don't know why so many
proxies should be broken in this way; for me it must be over 50% of them.
* I got to the point of continuously tailing both snowflake-client logs
to get some insight into what was happening.
* The worst is when a series of bad proxies causes a delay of a few
minutes with no data transfer; in that case tor gets into a "No running
bridges" bridges state that it is hard to coax out of. When this happens
it's not evident in the snowflake-client log; you have to go to
about:preferences#tor and look at the tor log. It may look like this:
{{{
[NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
$3F50D11DE55C028B8F3EFC272BB1CD9138C1F9A4~0x616e6f6e at 178.17.171.78.
Retrying on a new circuit.
[NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
$3F50D11DE55C028B8F3EFC272BB1CD9138C1F9A4~0x616e6f6e at 178.17.171.78.
Retrying on a new circuit.
[NOTICE] Delaying directory fetches: No running bridges
[NOTICE] Application request when we haven't received a consensus with
exits. Optimistically trying known bridges again.
[NOTICE] Delaying directory fetches: No running bridges
[NOTICE] Application request when we haven't received a consensus with
exits. Optimistically trying known bridges again.
[NOTICE] Delaying directory fetches: No running bridges
[NOTICE] Application request when we haven't received a consensus with
exits. Optimistically trying known bridges again.
}}}
Or this:
{{{
[NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
$6B062B0FDFEAC3C6F9203FB9584451E295574DAD~idideditTheconfig at
51.15.37.97. Retrying on a new circuit.
[NOTICE] We tried for 15 seconds to connect to '[scrubbed]' using exit
$7761DDC7EB1BE26D4155F74A15F12C32A36FE0F2~CalyxInstitute09 at
162.247.74.217. Retrying on a new circuit.
[NOTICE] Delaying directory fetches: No running bridges
[NOTICE] Application request when we haven't received a consensus with
exits. Optimistically trying known bridges again.
}}}
When this happens, I usually have luck in going to
about:preferences#tor, momentarily switching from snowflake to obfs4, then
switching back to snowflake. This restarts the snowflake-client process
and seems to cause tor to have a fresh look at its bridges.
* I'm not noticing a ton of subjective difference in the feel of the two
browsers. The main difference I have seen is that the quic one
occasionally spends a few minutes at 100% CPU: #33401.
* It may be my imagination, but I get the impression that everything
works better while the connection is being used. Initially my impression
was positive as I was trying to stress the system by having videos playing
in the background. Then the experience became more frustrating as I tried
normal text browsing and I encountered the occasional delays mentioned
above. It made me think that perhaps there is something in the proxy that
drops idle connections, but I didn't find anything like that. It's
possible that this is my imagination and that my initial impression was
just getting good luck with proxies.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33336#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list