[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25600 [Obfuscation/Snowflake]: Running 2 instances of snowflake-client leads to the former one stopping
#25600: Running 2 instances of snowflake-client leads to the former one stopping
-----------------------------------+---------------------------
Reporter: cypherpunks | Owner: (none)
Type: defect | Status: closed
Priority: Medium | Milestone:
Component: Obfuscation/Snowflake | Version:
Severity: Normal | Resolution: not a bug
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-----------------------------------+---------------------------
Comment (by cypherpunks):
Replying to [comment:5 dcf]:
> I've seen this too, not only with snowflake. I suspect it's actually a
tor bug. Sometimes a loading tab in Tor Browser will stall, and I'll see
this message. Then, I open another tab and go to a domain that doesn't
have an existing circuit, and it will "un-stall" the first tab. It's like
tor sometimes starts believing that none of its bridges are working, and
refuses to even try again, until you ask for a new circuit.
>
> It may happen more often with snowflake because of #25429 (disconnects
after 30 s). Some other tor-related tickets are #20379 (fixed in November
2016) and #24392 (fixed in November 2018). I'm not sure if #24392 is fixed
in a released Tor Browser yet.
So I did a methodology to know for sure whether it's due to the switch to
the newer `snowflake-client` or not (in which case it would primarily be
an issue with tor, FWIW I'm using 0.3.3.x-a in all of this).
1. First, I switched everything back to the older `snowflake-client`
(`sha256sum
ff94f6ed041263eb4e3bc8c215d9469a3a8cca7957ba4bccea617dc220294a74`),
including the one in my `/usr/bin`.
2. I restarted the two instances of `tor` that I had running, and I opened
the Tor Browser and went to two sites then clicked on New Identity.
3. I stopped from any activity for 40 minutes.
4. I went back and first looked at the task manager and saw that the
receiving/sending rates were varying around `0.9-4KiB/s - 2-5KiB/s` with
no dips and can go higher than that when snowflake rotates to another
snowflake proxy (I don't have any other significant application running
that could affect the network activity). Then, I opened
check.torproject.org in the Tor Browser, it took a bit of time but it
eventually worked. I did `apt-get update` (I'm torifying my apt-gets so it
uses the `debian-tor` service which was setup to use the older `snowflake-
client`) and it worked as well.
Afterwards I switched everything back to the newer `snowflake-client`
(`44ab0a493573b4f95a3b01f7495676cca6cd7ea2ae2afe1b69c4591ae4dbba2a`), and
I did the same step (2) above.
1. I stopped from any activity for 30 minutes.
2. Looking at the task manager one clearly sees that everything stopped
working, [[Image(newer-snowflake-client-task-manager-test.png)]] And
looking at wireshark one mostly sees STUN packets with `Binding Request`
and `Binding Success Response XOR-MAPPED-ADDRESS: ...` Opening the console
of the Tor Browser one sees `Delaying directory fetches: No running
bridges` and opening up check.torproject.org eventually times out. Going
to another site yields another timeout. Same for running `apt-get update`,
and one sees `Delaying directory fetches: No running bridges` as well in
the `/var/log/syslog`.
I hope you can reproduce this so that you can then narrow down the problem
to a specific commit. (Note that in my testing I had 3 instances of tor
running in total all of them with snowflake, but the issue may be present
with just one running it's just that I didn't have time to test)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25600#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs