Allow Tor client functionality even when we hibernate
When Tor runs into its accountingmax limit, it hibernates. This step also shuts off the client functionality. Bad news if we're trying to let people run their Tor client as a relay as well.
We should separate client behavior from relay behavior, leave the socksport (and transport/natdport/dnsport/etc) open, and continue to fetch directory info if we've used client functionality recently.
Activity
changed milestone to %Tor: unspecified
I have a branch with the requisite changes to attempt to leave AP connections open during hibernation.
This then allows a client of Tor to still use it while the node is hibernating from handling OR, Exit circuits.
You can find my branch with the changes made here: https://github.com/grubWare/Tor-0.2.3.14-alpha-custom-hibernateOrOnly.git
Trac:
Username: ioneyes
Actualpoints: N/A to N/A
Points: N/A to N/A-
A newer branch and possibly more accurate is available for 0.2.3.15 here: https://github.com/grubWare/Tor-0.2.3.15-alpha-custom.git
Trac:
Username: ioneyes 
This sounds like a pretty good idea!
A couple of quick comments:
- It looks like you've made a git repository by importing the "HEAD" commit of the Tor repository, rather than by cloning the Tor repository. This makes it basically impossible for Git to merge your changes cleanly. The right way to use Git here would be to use "git clone" to make a copy of the Tor repo, then using "git branch" or "git checkout -b" to make a new branch, making your changes to that branch, and pushing that branch to your public repo. If you use that workflow, it becomes very easy for Git to find and merge your changes. Also, that way you won't need to open a separate repository for every version of Tor.
- So you know what to expect, this is probably going to have to wait for 0.2.4.x (which should open for merges very soon, I hope)! I am not merging new features into 0.2.3.x if I can possibly help it right now.
Based on review of the 0.2.3.14-alpha branch:
- It looks like there are some unrelated CBT changes on this branch?
- Changing connection_is_listener() directly is probably not a good idea. After all, AP_LISTENER connections are still listeners-- this patch doesn't make them not be listeners; it just tries to treat them in a different way.
- Sebastian's comment about hibernation and bandwidth probably still applies.
Trac:
Status: new to needs_revision
Milestone: Tor: unspecified to Tor: 0.2.4.x-final-
Replying to arma:
ioneyes: any news here? Now is a fine time to get this revised and into 0.2.4.
Hi Arma,
I will clean up what I have done and submit it for review, taking on board NickM's comments.
I am not sure my solution is as clean as Tor dev's would like, baptism by fire is still a baptism.
Trac:
Username: ioneyes -
I have created a 'hibernate' branch with projected code changes within it. Please note this is not as clean as it should be. The code should seperate all client behaviour from OrPort and HiddenService behaviour with regard to shutting down at the time the hibernate limits are hit.
This is a best effort.
Please find the new branch here: git://github.com/grubWare/hibernate.git
Trac:
Username: ioneyes
Status: needs_revision to needs_review -
Wow; sorry for not getting back to you for so long. We need to get better at looking at these things faster.
When I went to fetch the repository just now, I didn't actually see any code. I saw a README file in one branch, and no changes in the other. Is there code somewhere else I should be looking at?
-
Hi Nick,
I tried again. git://github.com/grubWare/hibernate.git If there are any problems, let me know.
Trac:
Username: ioneyes -
Big stuff:
It looks like what the branch does now is to change it so that instead of marking all listeners when we start to hibernate, we only mark the OR listeners. But there's more work to do.
In hibernate_go_dormant:
- We'll need to shut down the OR connections that don't have origin_circuit_t circuits on them, but leave the others open. Right now it kills all the OR connections.
- For the OR connections that we do keep, we'll need to kill all the circuits that aren't ours.
- For the OR connections that we do keep, we'll need to reject any circuit creation attempts on them while we're hibernating. (We didn't need to reject these attempts before, since we weren't leaving OR connections open at all.)
- In 0.2.5, we need to close EXT_OR listeners too.
Generally:
- We'll need to figure what to do with bandwidth that clients use while we're hibernating. Should we count it? If the clients use enough, the server might never wake up.
- We'll want this behavior to be controlled by a torrc option.
Small stuff:
- Looks like the indentation doesn't match the rest of Tor.
Trac:
Status: needs_review to needs_revision -
Oh, one more suggestion:
- Have a look through everything that calls we_are_hibernating(). Some of these will need to change now that the rules for hibernation are different.
Also, I said:
- For the OR connections that we do keep, we'll need to reject any circuit creation attempts on them while we're hibernating. (We didn't need to reject these attempts before, since we weren't leaving OR connections open at all.)
But it looks as if we already do reject these attempts in command_process_create_cell(). The log message there is wrong, though.
-
(See also #192 (moved) and #318 (moved) for earlier discussion on the same topic.)
-
Hello NickM, Arma, Sebastian,
Was this ever merged ?
I may have some time to spend on taking NickM's comments into account. What really scares me with this is I don't know the Tor code base well enough to accommodate all of NickM's suggestions. On the plus side, all of his comments made sense to me.
With that in mind, I may have enough to do the research and become more adept with the code base.
That aside, I just wanted to give you folks a big thumbs up. I have been tracking Tor for some time now and you folks humble me. Keep up the good work.
Trac:
Username: ioneyes
Reviewer: N/A to N/A
Sponsor: N/A to N/A
Severity: N/A to Normal Replying to ioneyes:
Hello NickM, Arma, Sebastian,
Was this ever merged ?
I may have some time to spend on taking NickM's comments into account. What really scares me with this is I don't know the Tor code base well enough to accommodate all of NickM's suggestions. On the plus side, all of his comments made sense to me.
With that in mind, I may have enough to do the research and become more adept with the code base.
That aside, I just wanted to give you folks a big thumbs up. I have been tracking Tor for some time now and you folks humble me. Keep up the good work.
Hi ioneyes,
Thanks for being willing to help out!
We no longer recommend that people run their Tor relay as a client. It makes it too easy for them to be de-anonymised. Much better if they run a separate Tor instance for the client and relay.
It might be best to focus on another patch to start with - try the ones tagged "easy" or "intro".
Tim
-
We no longer recommend that people run their Tor relay as a client. It makes it too easy for them to be de-anonymised. Much better if they run a separate Tor instance for the client and relay.
Thanks for the prompt response.
What about running a bridge and a client ?
That is interesting advice. Thank you.
Trac:
Username: ioneyes mentioned in issue #6785 (moved)
mentioned in issue #8276 (moved)
moved to tpo/core/tor#2129 (closed)
