Custom Query (26254 matches)

Apr 01 09:45:39.145 [info] dirserv_add_descriptor(): Added descriptor from 'fluxe3' (source: 78.47.18.110): Valid server updated. Apr 01 18:52:28.976 [info] dirserv_add_descriptor(): Not replacing descriptor from 'fluxe3' (source: 78.47.18.110); differences are cosmetic.

shahn> I also reloaded it at 22:52 on April 1st

what exactly did you change?

shahn> RelayBandwidthRate 150 KBytes (was at 10000 or something insanely high) shahn> and RelayBandwidthBurst 200 KBytes (was at 15000)

see options_transition_affects_descriptor() in config.c If

• you changed your bandwidthrate but maxadvertisedbandwidth still
• trumps, no need to republish.

as part of an XXX then compare to router_differences_are_cosmetic() any differences between these two functions will cause bugs like yours. in the latter, it does

/* Did bandwidth change a lot? */

if ((r1->bandwidthcapacity < r2->bandwidthcapacity/2)

(r2->bandwidthcapacity < r1->bandwidthcapacity/2))

return 0;

in the former, it says "did they change at all"

what the relay should do is make a new descriptor, and then call router-differences-are-cosmetic on it, and revert if cosmetic. that way we're using the same function, rather than trying to keep the checks the same in both cases.

[Automatically added by flyspray2trac: Operating System: All]

hm. I published my descriptor before doing DNS tests. Also, I'm rejecting all exit

traffic, and still do DNS tests. Isn't that supposed to be different? <armadev> i've had a todo item for nick to not do dns tests if reject *:*. he didn't want to put it in, though. <armadev> i think that you would need to remember whether you did them, and if not launch them, if exit policy changes from reject * to something else

Can't we just redo them every time exit policy changes from reject to something?

<armadev> fine by me. open a flyspray, due 0.2.2.x?

(in theory, we should probably redo them when the IP changes. This could mean

Laptop user in a new environment)

[Automatically added by flyspray2trac: Operating System: All]

Under certain circumstances a single directory authority in a private Tor network does not manage to publish a consensus. For some reason the directory adds itself to the list of trusted directory authorities *twice*. The result is that it thinks there are 2 directories and that a single vote is not enough to publish a consensus.

The directory triggers the following warning:

Index: src/or/routerlist.c =================================================================== --- src/or/routerlist.c (revision 19258) +++ src/or/routerlist.c (working copy) @@ -3706,6 +3706,18 @@

hostname = tor_strdup(address);

}

+ SMARTLIST_FOREACH(trusted_dir_servers, trusted_dir_server_t *, ent, { + if (ent->v3_identity_digest && + !memcmp(v3_auth_digest, ent->v3_identity_digest, DIGEST_LEN)) + log_warn(LD_CONFIG, "We already have a directory with the same " + "v3 identity digest %s, address %s, OR port %d, and Dir port %d. " + "Now we try to add one with address %s, OR port %d, and Dir port %d. " + "Something is wrong here!", + hex_str(ent->v3_identity_digest, DIGEST_LEN), + ent->address, ent->or_port, ent->dir_port, + hostname, or_port, dir_port); + }); +

ent = tor_malloc_zero(sizeof(trusted_dir_server_t)); ent->nickname = nickname ? tor_strdup(nickname) : NULL; ent->address = hostname;

A workaround is to add a return statement to that loop. But it would be better to find out why the directory adds itself to the list twice.

[Automatically added by flyspray2trac: Operating System: All]