[tor-dev] Testing Network Node Availability

[Xiaofan Li]

Hi,
We'll be looking into the configurations soon. Thanks for the advice!

Today we handed in our project report on QUIC + TOR, which concluded our
semester-long project as well as our journey as undergrads here at CMU. I
just want to thank everyone who helped us during this time, since I've
asked many questions and not all of them made sense. Special thanks to Tim
for his knowledge and patience! With your help, we were able to accomplish
a lot in the short few months.

After graduating next week, Kevin (my project partner) and I will both move
to California for our first job! I'll still keep an eye on Tor and
contribute if opportunity allows. As for this project, we will release all
the code in a few months after publication submissions. Meanwhile, I will
still work, although less frequently, on the project for possible
improvements. We hope you'll take a look at our ideas once it becomes
available!

Thanks again!
Li.

On Sun, May 8, 2016 at 8:42 AM, Tim Wilson-Brown - teor <teor2345 at gmail.com>
wrote:

>
> > 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
>
>
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160509/16e86f33/attachment.html>