#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs