[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



On 26/02/14 04:04, Aiminyoung wrote:
> 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.

Oh!  A vote interval of 10 seconds is crazy.  What's wrong with 300 seconds?

If the problem with the 180 seconds constant doesn't apply to test
networks with a vote interval of 300 seconds, I'm going to close the
ticket as "won't fix".

All the best,
Karsten


> (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@xxxxxxxxxxxxxx>:
> 
>> 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@xxxxxxxxxxxxxxxxxxxx
>> To unsubscribe or change other settings go to
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk