Opened 4 years ago

Closed 4 years ago

#17624 closed enhancement (invalid)

Extend NEWNYM to also clear rendezvous caches and rendezvous connections

Reported by: karsten Owned by:
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords:
Cc: nickm, asn, robgjansen Actual Points:
Parent ID: Points:
Reviewer: Sponsor: SponsorR

Description

Rob and I would like to measure hidden/onion/rendezvous service performance by running two local tor clients to host and repeatedly access a service, respectively. In order to make subsequent requests as independent as possible, we'd want to clear all rendezvous caches and forget about rendezvous connections before making the next request. Roger suggests on #1944 to add the necessary functionality to the NEWNYM control command.

Here's the current patch that we're using, which is loosely based on arma's bug1944 branch and rebased to master from a year or so ago (4c8b809). Of course, the downside of using this patch is that we can't just use a recent-enough tor but have to patch a tor and also maintain the patch. The patch is pretty simple:

diff --git a/src/or/main.c b/src/or/main.c
index 094120f..ad7fa0b 100644
--- a/src/or/main.c
+++ b/src/or/main.c
@@ -2102,9 +2102,13 @@ process_signal(uintptr_t sig)
       control_event_signal(sig);
       break;
     case SIGUSR2:
-      switch_logs_debug();
-      log_debug(LD_GENERAL,"Caught USR2, going to loglevel debug. "
-                "Send HUP to change back.");
+      /* Replace the USR2 functionality with bug1944-specific plans.
+       * Ugly hack, but it'll do. */
+      log_info(LD_GENERAL, "Clearing all rendezvous caches and "
+                           "forgetting about rendezvous connections...");
+      rend_cache_purge();
+      rend_client_purge_last_hid_serv_requests();
+      circuit_mark_all_dirty_circs_as_unusable();
       control_event_signal(sig);
       break;
     case SIGHUP:

If there are no major concerns against this idea, I'll prepare and test a branch that actually does things when receiving a NEWNYM command, not when receiving SIGUSR2.

Thanks for considering this!

Child Tickets

Change History (5)

comment:1 in reply to:  description Changed 4 years ago by dgoulet

Cc: dgoulet removed
Milestone: Tor: unspecifiedTor: 0.2.8.x-final
Sponsor: SponsorR
Status: newneeds_information

Replying to karsten:

Here's the current patch that we're using, which is loosely based on arma's bug1944 branch and rebased to master from a year or so ago (4c8b809). Of course, the downside of using this patch is that we can't just use a recent-enough tor but have to patch a tor and also maintain the patch. The patch is pretty simple:

Can you explain why NEWNYM is not enough? Actually, NEWNYM now, for client HS side, cleans the caches correctly where this proposed patch is missing some stuff. rend_client_purge_state() is the function you want instead of rend_cache_purge() unless you have a different goal in mind?

comment:2 Changed 4 years ago by karsten

Ah, oh! Looks like that's indeed already implemented. Would we want to use tor-0.2.7.3-rc or later that contain your d06af95, or can we safely use an older tor version?

comment:3 in reply to:  2 ; Changed 4 years ago by dgoulet

Replying to karsten:

Ah, oh! Looks like that's indeed already implemented. Would we want to use tor-0.2.7.3-rc or later that contain your d06af95, or can we safely use an older tor version?

Latest change in the NEWNYM function is from 7bb51fdd8 which is tor-0.2.4.12-alpha so you should be fine using 026 and if 027, use the latest :).

comment:4 in reply to:  3 ; Changed 4 years ago by karsten

Replying to dgoulet:

Replying to karsten:

Ah, oh! Looks like that's indeed already implemented. Would we want to use tor-0.2.7.3-rc or later that contain your d06af95, or can we safely use an older tor version?

Latest change in the NEWNYM function is from 7bb51fdd8 which is tor-0.2.4.12-alpha so you should be fine using 026 and if 027, use the latest :).

I meant the change to rend_client_purge_state which was last changed in d06af95 and which now also removes all entries from the failure cache using rend_cache_failure_purge. This seems important for making measurements independent, unless I'm misunderstanding what happens there. What do you think?

comment:5 in reply to:  4 Changed 4 years ago by dgoulet

Resolution: invalid
Status: needs_informationclosed

Replying to karsten:

Replying to dgoulet:

Replying to karsten:

Ah, oh! Looks like that's indeed already implemented. Would we want to use tor-0.2.7.3-rc or later that contain your d06af95, or can we safely use an older tor version?

Latest change in the NEWNYM function is from 7bb51fdd8 which is tor-0.2.4.12-alpha so you should be fine using 026 and if 027, use the latest :).

I meant the change to rend_client_purge_state which was last changed in d06af95 and which now also removes all entries from the failure cache using rend_cache_failure_purge. This seems important for making measurements independent, unless I'm misunderstanding what happens there. What do you think?

The client failure cache was introduced in 027 so using rend_cache_purge() in any case will do the work. Just talked with karsten, we agree on closing the ticket.

Note: See TracTickets for help on using tickets.