This is the bug-tracker for Tor. There is a guide for reporting bugs. Tor is a connection-based low-latency anonymous communication system that protects TCP streams: web browsing, instant messaging, irc, ssh, etc. See https://www.torproject.org/ for more information. To report bugs in the Torbutton Firefox browser extension, select the Torbutton project on this tracker. To report bugs in the Vidalia front-end program, go to http://trac.vidalia-project.net/wiki/ReportingBugs . Thanks for your help!
Task #767 — Rendezvous Descriptor Upload Failures
Attached to Project— Tor
Opened by Karsten Loesing (karsten) - Friday, 11 Jul 2008, 10:15pm
| Bug Report | |
| Tor client | |
| Closed | |
| No-one | |
| All |
| Low | |
| Normal | |
| 0.2.1.2-alpha | |
| Undecided | |
 |
Roger Dingledine wrote on June 20, 2008: > It looks like hid_serv_get_responsible_directories() looks at > routerstatus entries, but ignores whether we actually have descriptors. > So if I don't have the descriptor it chooses, I end up with this in my > logs: > > Jun 19 19:21:22.045 [warn] Requested exit point > '$68333D0761BCF397A587A0C0B963E4A9E99EC4D3' is not known. Closing. > Jun 19 19:21:22.045 [warn] Making tunnel to dirserver failed. Right, that's the same bug that is described in the NLnet mid-June report: "Descriptor Upload Failures: The current logic to upload rendezvous service descriptors does not handle failures in a reasonable way. In case of a failure, Tor waits for a solid hour before making the next attempt. There should either be a smaller timeout or an individual handling of failures per directory." In the mid-June measurements and when using v0 rendezvous descriptors this bug affected 481 of 3270 cases (14.7 %); only in very few cases it affected all three hidden service authorities and became visible, because clients couldn't access the hidden service. In my yesterday evaluations with v2 rendezvous descriptors, this bug occurred in 1298 out of 9460 attempts (13.7 %). This means we really need to fix this bug to increase reliability. The fix you suggested above only avoids those nasty warnings and unnecessary upload attempts, but it doesn't help to maintain rendezvous descriptor availability. My first idea was to put all upload attempts that cannot be performed due to missing router descriptors in a queue. As soon as new router descriptors arrive, this queue should be checked, and rendezvous descriptors be uploaded. However, this idea does not work. Tor doesn't seem to make any attempts to download missing router descriptors when it thinks it has enough (I'm not so sure about its behavior, could you confirm?). In one test case a Tor providing a hidden service failed to upload v0 rendezvous descriptors to the three hidden service authorities for more than two hours. So, my second idea was to request router descriptors as soon as we realize that we need them and implement the queuing idea, so that a second attempt will be performed as soon as router descriptors have arrived. |
This task depends upon
This task blocks these from closing
Comments (1) | Attachments (0) | Related Tasks (0/0) | Notifications (2) | Reminders (0) | History |
Comment by Karsten Loesing - Monday, 8 Sep 2008, 1:10am
Some progress on the fix of this nasty bug. We already knew that when uploading or fetching a rendezvous service descriptor, Tor requires the router descriptor of the hidden service directory to extend a circuit to. Last month Nick told me that Tor downloads *all* router descriptors that it thinks are useful, so that my second idea to download router descriptors on demand makes no sense any more. There must be a bug that prevents Tor from downloading specific router descriptors, as they are apparently not available (even after an hour or more). Today I tracked this bug down! When Tor fails to extend a circuit to a router for which it has *not* yet downloaded the router descriptor, it marks the router as down in the local network status. The effect is that no attempt will be made to download the router descriptor in the future (probably unless the next consensus is downloaded that marks the router as up again). The fix to this bug is to refrain from marking a router as down when an extend operation fails due to absence of the router descriptor. (My first idea of queueing failed upload attempts becomes valid again and should be implemented, too, in addition to fixing this bug.)