[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