[tor-talk] How to update the consensus in client as soon as the configuration of relay nodes changed

Aiminyoung aiminyoung at gmail.com
Wed Feb 26 03:04:55 UTC 2014


Hi Karsten,

On the directory server side, I've modified the definition of
"MIN_VOTE_INTERVAL" in src/or/dirvote.h to 10 (down from 300) to make Tor
accept a smaller V3 voting interval.
(NOTE: The Tor version is 0.2.5.2-alpha)

*****************************************************************************
--- /root/Downloads/tor-0.2.5.2-alpha/src/or/dirvote.h  2014-02-12
17:03:56.000000000 +0800
+++ tor-0.2.5.2-alpha/src/or/dirvote.h   2014-02-26 09:44:06.760053692 +0800
@@ -19,7 +19,7 @@
 /** Lowest allowable value for DistSeconds. */
 #define MIN_DIST_SECONDS 2
 /** Smallest allowable voting interval. */
-#define MIN_VOTE_INTERVAL 300
+#define MIN_VOTE_INTERVAL 10

 /** The highest consensus method that we currently support. */
 #define MAX_SUPPORTED_CONSENSUS_METHOD 17
*****************************************************************************

The torrc file is here:

*****************************************************************************
Address 192.168.1.120

ControlPort 9051
ControlListenAddress 127.0.0.1

SocksPort 9050
SocksListenAddress 127.0.0.1

ORPort 9001
Nickname HeroD

ContactInfo zhening<at>gm.com
DirPort 9030
TestingTorNetwork 1
ServerDNSDetectHijacking 0

ExitPolicy reject *:*
ExitNodes Relay1

DirServer PIPDS1 v3ident=5E13138346AB0E851827A8148806E6D918004227
192.168.1.120:9030 1FF7 6EC5 6A18 8823 3E46 2507 F473 35E0 2EB6 4B86

AuthoritativeDirectory 1
V3AuthoritativeDirectory 1
V2AuthoritativeDirectory 1

V3AuthVotingInterval 20 seconds
V3AuthVoteDelay 2 seconds
V3AuthDistDelay 2 seconds

DNSListenAddress 127.0.0.1
DNSPort auto

TestingServerDownloadSchedule 35, 35, 35, 35, 35, 35, 35, 35, 35, 35, 60

DataDirectory /opt/tor

Log debug file /opt/tor/debug.log
*****************************************************************************

On the client side, in addition to removing 180 seconds from
"if_modified_since" evaluation in src/or/directory.c as mentioned, I've
also commented out 4 if-statements filtering too short interval in
src/or/routerparse.c to avoid downloaded consensus from falling into
unparsed.

*****************************************************************************
--- /root/Downloads/tor-0.2.5.2-alpha/src/or/directory.c        2014-02-12
17:03:56.000000000 +0800
+++ tor-0.2.5.2-alpha/src/or/directory.c 2014-02-26 09:57:04.436032299 +0800
@@ -442,7 +442,9 @@
        * if-modified-time based on it. */
       v = networkstatus_get_latest_consensus_by_flavor(flav);
       if (v)
-        if_modified_since = v->valid_after + 180;
+//        if_modified_since = v->valid_after + 180;
+        if_modified_since = v->valid_after;
+        log_debug(LD_GENERAL, "compute if_modified_since");
     } else {
       /* Otherwise it might be a consensus we don't parse, but which we
        * do cache.  Look at the cached copy, perhaps. */
*****************************************************************************
--- root/Downloads/tor-0.2.5.2-alpha/src/or/routerparse.c      2014-02-12
17:03:56.000000000 +0800
+++ tor-0.2.5.2-alpha/src/or/routerparse.c       2014-02-26
09:58:45.380029522 +0800
@@ -2586,6 +2586,7 @@
     (int) tor_parse_long(tok->args[1], 10, 0, INT_MAX, &ok, NULL);
   if (!ok)
     goto err;
+/*
   if (ns->valid_after + MIN_VOTE_INTERVAL > ns->fresh_until) {
     log_warn(LD_DIR, "Vote/consensus freshness interval is too short");
     goto err;
@@ -2602,7 +2603,7 @@
     log_warn(LD_DIR, "Dist seconds is too short");
     goto err;
   }
-
+*/
   if ((tok = find_opt_by_keyword(tokens, K_CLIENT_VERSIONS))) {
     ns->client_versions = tor_strdup(tok->args[0]);
   }
*****************************************************************************

The torrc file in client:

*****************************************************************************
Address 192.168.1.123
ContactInfo Client<at>gm.com
ControlListenAddress 127.0.0.1
ControlPort 9051
DataDirectory /opt/tor
DirReqStatistics 0
DirServer PIPDS1 v3ident=5E13138346AB0E851827A8148806E6D918004227
192.168.1.120:9030 1FF7 6EC5 6A18 8823 3E46 2507 F473 35E0 2EB6 4B86
ExitPolicy reject *:*
Log notice stdout
Nickname Client
TestingTorNetwork 1
ServerDNSDetectHijacking 0
SocksListenAddress 127.0.0.1
SocksPort 9050

TestingClientDownloadSchedule 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 60

Log debug file /opt/tor/debug.log
*****************************************************************************

Best Regards,
Aiminyoung


2014-02-26 5:25 GMT+08:00 Karsten Loesing <karsten at torproject.org>:

> On 24/02/14 10:54, Aiminyoung wrote:
> > I've found some new settings from Chutney torrc template,
> > TestingServerDownloadSchedule and TestingClientDownloadSchedule.
> > Then I upgrade my tor to 0.2.5.2 since the new settings are available in
> > 0.2.5.x and gave small values to the settings, but no help.
> > So I went back to source code and found that in directory.c the directory
> > request parameter "if_modified_since" came from "valid_after" plus a
> > constant 180. Though I'm not sure about the reason this number written in
> > numeric instead of a constant definition, I removed it and now the
> > consensus file in client can be updated in a period of
> > TestingClientDownloadSchedule!
>
> Hmm, the 180 seconds indeed look wrong for test networks.
>
> I created a ticket for this possible issue here:
>
> https://trac.torproject.org/projects/tor/ticket/11072
>
> Do you mind adding more details what changes you made to the code
> (ideally by attaching a diff) and what configurations you used?  Thanks!
>
> All the best,
> Karsten
>
> --
> tor-talk mailing list - tor-talk at lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>


More information about the tor-talk mailing list