On Sun, May 08, 2016 at 02:04:23AM -0400, Tim Wilson-Brown - teor wrote:
??? Each client will have a cache-microdesc-consensus file with 4 relays in it. relay 0, 1 and 2 will always be there and the last one changes each time I start the network.
Are all your relays on just a few IP addresses? If so, see the AuthDirMaxServersPerAddr config option.
If that doesn't do it, I'd suggest looking at more detailed logs at the authorities. Do they receive the relay descriptors from all the relays? How do their reachability tests go for each relay?
??? When one of the node is not on the consensus, the bootstrap will be stuck and never reach 100%. Depending on which node of the path is not included in the consensus, the error message varies. In the above example, if R3 is not in the consensus, we will fail to connect to hop 1 (assume 0-based logging).
If you try to extend to a relay that isn't in the consensus, then it's not surprising that the circuit will fail.
Speaking of which, you might be happier using the stem library and the "extendcircuit" controller command, rather than hacking the Tor code yourself. Once you explained that you had modified your Tor code in unspecified ways, the number of possible explanations for what's going wrong for you has become very large. :)
But it's far more likely that some of the relays are configured with the wrong addresses and ports (either in the torrc or in the OS), or aren't actually connected to your network properly at lower layers, such as TCP or IP or ethernet.
Yep -- this is certainly worth exploring too.
--Roger