[tor-bugs] #25600 [Obfuscation/Snowflake]: Running 2 instances of snowflake-client leads to the former one stopping

[Tor Bug Tracker & Wiki]

#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