<div dir="ltr"><div>Hi, </div>We'll be looking into the configurations soon. Thanks for the advice! <div><br></div><div>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. </div><div><br></div><div>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! </div><div><br></div><div>Thanks again!</div><div>Li. </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 8, 2016 at 8:42 AM, Tim Wilson-Brown - teor <span dir="ltr"><<a href="mailto:teor2345@gmail.com" target="_blank">teor2345@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 8 May 2016, at 02:46, Roger Dingledine <<a href="mailto:arma@mit.edu">arma@mit.edu</a>> wrote:<br>
><br>
> On Sun, May 08, 2016 at 02:04:23AM -0400, Tim Wilson-Brown - teor wrote:<br>
>>>     ??? 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.<br>
><br>
> Are all your relays on just a few IP addresses? If so, see the<br>
> AuthDirMaxServersPerAddr config option.<br>
<br>
</span>You might also need to change AuthDirMaxServersPerAuthAddr.<br>
<br>
If you've set TestingTorNetwork, it should set AuthDirMaxServersPerAddr and AuthDirMaxServersPerAuthAddr to 0 (unlimited).<br>
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.<br>
<span class=""><br>
> If that doesn't do it, I'd suggest looking at more detailed logs at<br>
> the authorities. Do they receive the relay descriptors from all the<br>
> relays? How do their reachability tests go for each relay?<br>
<br>
</span>Similarly, TestingTorNetwork sets AssumeReachable 1, which skips reachability self-checks on relays, and relay reachability checks on authorities.<br>
<br>
Otherwise, relays self-check their ORPort and DirPort before uploading a descriptor.<br>
In 0.2.7.6 and 0.2.8.1-alpha, there's a bug where relays sometimes submit an 0 DirPort.<br>
See <a href="https://trac.torproject.org/projects/tor/ticket/18050" rel="noreferrer" target="_blank">https://trac.torproject.org/projects/tor/ticket/18050</a><br>
<br>
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.<br>
This is a frequent source of relay operator confusion.<br>
See <a href="https://trac.torproject.org/projects/tor/ticket/13953" rel="noreferrer" target="_blank">https://trac.torproject.org/projects/tor/ticket/13953</a><br>
<br>
If they can't reach their own ORPort and DirPort when they check it, relays won't post a descriptor.<br>
<br>
These are just guesses.<br>
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.<br>
<span class=""><br>
>>>     ??? 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).<br>
><br>
> If you try to extend to a relay that isn't in the consensus, then<br>
> it's not surprising that the circuit will fail.<br>
><br>
> Speaking of which, you might be happier using the stem library and the<br>
> "extendcircuit" controller command, rather than hacking the Tor code<br>
> yourself. Once you explained that you had modified your Tor code in<br>
> unspecified ways, the number of possible explanations for what's going<br>
> wrong for you has become very large. :)<br>
<br>
</span>I am also quite concerned about the extra hardcoded path code you're using.<br>
It is so easy to modify tor code in ways that are subtly wrong.<br>
I have done it many times.<br>
<br>
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.<br>
<span class="im HOEnZb"><br>
>> But it's far more likely that some of the relays are configured with<br>
>> the wrong addresses and ports (either in the torrc or in the OS), or<br>
>> aren't actually connected to your network properly at lower layers,<br>
>> such as TCP or IP or ethernet.<br>
><br>
> Yep -- this is certainly worth exploring too.<br>
><br>
> --Roger<br>
<br>
</span><div class="HOEnZb"><div class="h5">Tim Wilson-Brown (teor)<br>
<br>
teor2345 at gmail dot com<br>
PGP 968F094B<br>
ricochet:ekmygaiu4rzgsk6n<br>
<br>
<br>
<br>
</div></div><br>_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br></blockquote></div><br></div>