[tor-dev] Testing Network Node Availability

[Tim Wilson-Brown - teor]

> On 8 May 2016, at 02:46, Roger Dingledine <arma at mit.edu> wrote:
> 
> 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.

You might also need to change AuthDirMaxServersPerAuthAddr.

If you've set TestingTorNetwork, it should set AuthDirMaxServersPerAddr and AuthDirMaxServersPerAuthAddr to 0 (unlimited).
If you think you've set TestingTorNetwork, but you still only have 2 servers per IP, that's a clue that your settings aren't being applied to the Tor instances you're running.

> 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?

Similarly, TestingTorNetwork sets AssumeReachable 1, which skips reachability self-checks on relays, and relay reachability checks on authorities.

Otherwise, relays self-check their ORPort and DirPort before uploading a descriptor.
In 0.2.7.6 and 0.2.8.1-alpha, there's a bug where relays sometimes submit an 0 DirPort.
See https://trac.torproject.org/projects/tor/ticket/18050

Relays check the ORPort and DirPort ports, on the torrc option Address (or an automatically guessed address), and not on their listen addresses. However, the listen addresses must be listening on, or redirected from, the configured Address.
This is a frequent source of relay operator confusion.
See https://trac.torproject.org/projects/tor/ticket/13953

If they can't reach their own ORPort and DirPort when they check it, relays won't post a descriptor.

These are just guesses.
We could help you more with this if you posted the relevant lines from relays and authorities that say what happens to the missing descriptors.

>>> 	??? 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. :)

I am also quite concerned about the extra hardcoded path code you're using.
It is so easy to modify tor code in ways that are subtly wrong.
I have done it many times.

While we could help by reviewing this extra code, I'd encourage you to follow Roger's suggestion that you use the tested stem / tor controller code for building set paths. You'll likely write fewer lines of code this way, too.

>> 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

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B
ricochet:ekmygaiu4rzgsk6n



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160508/2b17c86b/attachment.sig>