Graceful Shutdown & ID Questions

Support Censorship Circumvention
,
1

Last I read (man page) there was a way to signal tor to shutdown (when being run as a relay) so it would not accept new circuits and just let existing ones run their course, and after some time tor would exit, thus preserving a persons existing browsing session.

I don’t recall seeing an option like this when running the Snowflake Proxy. When I first began running it about two weeks ago it almost immediately took on users. But I had to reboot after a week or so. When it came back up I think it took ~ 2 hours to be used again. Not such a huge deal to me but I thought I’d ask. Mainly I’m sure it’s a bummer to be browsing the web and suddenly your snowflake on-ramp goes away. Not sure how Tor Browser recovers from that. I guess it sees the circuit is broken and negotiates a new snowflake connection.

Also, I went looking for an option to find my snowflake ID/fingerprint to see if I could use it like a bridge, i.e. enter its fingerprint before connecting, but it seems this is not possible. I thought this might make my browsing experience a tiny bit faster. Is that possible? Planned?

Finally, with regards to nomenclature, I understand what guards are, versus middle relays and exits. I also understand there’s a diversity of methods to get into the tor network, aka pluggable transports. Aren’t bridges and snowflake proxies also guards? I mean, bridges and snowflake proxies aren’t used as middle nodes best I can tell from my reading.

Thanks.

2

I think it happened because long-lived connections were dropped.
But rate of arrival for fresh connections should be the same I think.
Another question is why it is generally low.
But most probably you just don’t have public IP.
There is less demand for proxies with private IP (but they are still useful of course).

Snowflake was designed with such situations in mind.
If such switching works bad, it is just a reason to make bug report.

I make restarts for my proxy several times a week.
Because it still contains memory leaks, developers are not fixing them and I can’t afford wasting RAM.

You can’t, because snowflake proxies are not Tor nodes, they are just proxies.

3

You’re right, it searches for a new proxy. And yes, there is no such option currently, though it shouldn’t be too hard to implement - juts stop polling the broker and shut down when there are no connections.
But Snowflake is supposed to be resistant to that, as @Vort said.
Also see

Weird, I don’t know what it can be explained with.

You can do this, but it’s a ton of work, I’d say it’s not worth it. It was discussed in greater detail here. If you have a static server that you can connect to, you probably better off going for a classic obfs4 bridge, or something VPN-like, say, v2ray.

Also here’s a (not quite) similar proposal: (More) Distributed servers (#40248) · Issues · The Tor Project / Anti-censorship / Pluggable Transports / Snowflake · GitLab

Tor bridges are entry nodes. Snowflake proxies are not entry nodes, as @Vort said. Look at the pic on https://snowflake.torproject.org/ . You connect to a Tor bridge (entry node) through a Snowflake proxy. Currently there are just two bridges that all Snowflake clients are connecting to.

1 Like
4

@Vort & @WofWca Thank you for your replies.

Because it still contains memory leaks…

I have been running snowflake proxy since around last August and have checked the logs every once in a while, as well as running top to check resource usage. For awhile that’s all I ran. It’s in a VM running OpenBSD 7.3 and logs “NAT type: restricted.”

Even after weeks of uptime I haven’t seen any signs of a memory leak (Swap is always 0). Which is good for me since the hardware only has 4 GiB of RAM and I use it to do/host other things.

Rarely do I see something like this:

Aug 27 15:08:03 [host] snowflake_proxy[11374]: sctp ERROR: 2023/08/27 15:08:03 [0xc0029e6c40] stream 1 not found)

But they are transient and not flooding the logs, at most I’ve seen two together (always at the same second).

Sometimes it’s once per day, sometimes many days pass without it.

There has been one other “ERROR” messages but very rarely, the ‘ortc’ error.

Oct  2 20:58:42 [host] snowflake_proxy[7323]: ortc ERROR: 2023/10/02 20:58:42 Failed to accept data channel: failed to send ChannelOpen ACK: sending payload data in non-established state: state=Closed

The only problem I’ve had is once in a while I find the VM locked up and the host machine at 100% CPU usage. When I first started (~ August), it happened more often than towards the end of the year. So I suspected it was some specially crafted packet/payload which caused it (tor hater/hacker), versus a bug in snowflake_proxy.

Since I’ve not set up (or written) any log analysis software I can only give you my impressions versus statistics. But I see there are some days there’s just 1 “0 connections. Traffic Relayed IN 0 KB, OUT 0 KB.” logged, other days it may happen multiple times. So I’m not so concerned about being intentionally blocked or ignored somehow.

But it does seem every once in a while some hacker figures out how to send me a devastating payload that maxes out the CPU and I end up forcibly shutting down the VM and rebooting my computer. Which is why I can say at most I’ve had weeks of uptime versus months.

My other questions about snowflake should probably be a separate thread. This was just a bunch of general questions. Not really a problem to be solved. But I thank you @WofWca for the link; I have a feeling if I set up the required software it will be pretty far in the future.

5

Do you use latest version of snowflake proxy?
If not, try updating it. There is a chance hangs will go away.

6

I install from ports, I don’t build my own. Right now I’m kind of buried so updating from 7.3 to 7.4 is on my to-do list.