July 2023 - tor-dev - lists.torproject.org

What happens to my hidden service?
by Liste 29 Dec '25

29 Dec '25

Hidden service is unavailable, but tor is running. Tor's log: Dec 12 18:10:27.000 [notice] Your Guard SECxFreeBSD64 ($D7DB8E82604F806766FC3F80213CF719A0481D0B) is failing more circuits than usual. Most likely this means the Tor network is overloaded. Success counts are 199/285. Use counts are 101/101. 253 circuits completed, 0 were unusable, 54 collapsed, and 15 timed out. For reference, your timeout cutoff is 60 seconds. is failing a very large amount of circuits. Most likely this means the Tor network is overloaded, but it could also mean an attack against you or potentially the guard itself. Dec 12 18:15:53.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service xxxxxxxxxxxxxxx. Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a connection, but we already have 32 general-purpose client circuits pending. Waiting until some finish. [268 similar message(s) suppressed in last 600 seconds] Dec 11 13:43:12.000 [warn] onion_skin_client_handshake failed. Dec 11 13:43:12.000 [warn] circuit_finish_handshake failed. Dec 11 13:43:12.000 [warn] connection_edge_process_relay_cell (at origin) failed. Dec 11 00:34:57.000 [warn] Giving up launching first hop of circuit to rendezvous point [scrubbed] for service .... Dec 10 10:09:01.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:03.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 10:09:04.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t. Dec 10 12:42:19.000 [warn] rend_service_introduce(): Bug: Internal error: Got an INTRODUCE2 cell on an intro circ (for service "...") with no corresponding rend_intro_point_t.

3 2

Calling Tor Volunteers and Developers! Help Shape the Future of Tor Relay Updates!
by Ravi Kumar 25 Jul '23

25 Jul '23

Dear Tor Volunteers and Developers, We are reaching out to you today to seek your invaluable expertise and insights in shaping the future of Tor relay updates. As part of an MSc Dissertation, a comprehensive study is underway to gain a deeper understanding of the significance of Tor relay updates from the unique perspective of developers like yourself. Your participation is pivotal to the success of this research, as we seek to explore your thoughts and opinions on a proposed automatic update mechanism for the relay. By lending your expertise, you will play a key role in advancing the health of the Tor network and enhancing the overall experience for millions of users around the globe. Rest assured that all your responses will be treated with the utmost care and confidentiality. To safeguard your data, the survey has been thoughtfully designed on an end-to-end encrypted platform, aligning with our commitment to ethical principles. We genuinely value your privacy and will handle your contributions with utmost respect and protection. We acknowledge the value of your time and effort, and we assure you that your input, which requires only 10 minutes, will wield a significant influence on the advancement of the Tor network. Don't miss out on this chance to contribute; the survey will remain open until August 5th. We invite you to join us today in shaping transformative research for Tor's bright future. Should you have any questions or require further information, please don't hesitate to contact us at S2450888(a)ed.ac.uk. We wholeheartedly welcome your feedback and queries, and your cooperation is genuinely appreciated. Together, we can make a meaningful difference and construct a stronger, more secure online world for everyone. Participate now and be an integral part of shaping the future of Tor relay updates through this link: https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-Jxc… [https://cryptpad.fr/customize/images/opengraph_preview/og-form.png]<https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-Jxc…> Encrypted Form<https://cryptpad.fr/form/#/2/form/view/pb7wKm8zl0D62PsW93fz4wiW73i9nzDM-Jxc…> CryptPad: end-to-end encrypted collaboration suite cryptpad.fr Thank you for your essential role in this important journey. Best regards, Ravi Kumar S2450888(a)ed.ac.uk The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th' ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

1 0

Network Health team and analysis work
by Georg Koppen 06 Jul '23

06 Jul '23

Hello everyone! The Network Health team is best known for its work in the bad-relays area and being concerned with providing metrics + keeping an eye on the health of the Tor network. While that involves doing analyses to answer our own questions it was not clear so far what we should do with questions about the network or available data which got raised by other teams (i.e. you). Should we do those analyses as well or should we just provide the necessary data and each team then tries to answer their questions by themselves? This got raised a bunch of times in the past[1][2] and I am happy to announce that the Network Health team is stepping up and helping you with your analyses, if desired. The idea would be that we'd do the analysis work in those cases, alone or together, and accumulate/improve a set of scripts and tools over time at a single place, so that both we and other interested parties can do those analyses faster and better in the long(er) run. The tools should be open so that other folks can help improving and shaping them according to their needs. We have a dedicated analysis project[3] where we track all analysis related issues and which contains tools and documentation about how to use them for our work. If there is any analysis work you would like us to get done, please file a ticket in that project. If you did a similar analysis in the past by yourself we'd love to hear about it as it might speed up our work and we could build documentation out of it and add available code to the analysis project. Additionally, please assume we are no experts in your area of work, but don't hesitate to file tickets because of that. We'll ask if things are unclear. :) To get your analysis questions answered in a timely manner it would greatly help if they were attached to some sponsored work as that makes it usually easier to justify picking them up among all the other things on our plate. Additionally, emergencies (like new blocking events in country X) should be easily justifiable as well, in particular as we have a "surprise 'anomaly analysis' on the network as needed"-item on our roadmap throughout the year. I plan to make sure that we have sufficient spare cycles available for that work should it be needed. If your desired analysis does not fall into either of those categories don't despair, we'll try to find a way to get it done nonetheless. Thanks, Georg P.S.: If you are not part of any of our teams but want to do an analysis by yourself or just note an analysis idea somewhere, feel free to start by filing a ticket in the analysis project as well. Others might just jump on it and get it done because they might be curious about the answers themselves. :) [1] https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/iss… [2] https://gitlab.torproject.org/tpo/network-health/team/-/issues/250#note_286… [3] https://gitlab.torproject.org/tpo/network-health/analysis

1 0

[Update] Network Status APIs
by Mattia Righetti 06 Jul '23

06 Jul '23

Greetings Tor devs, During the last two weeks there has been an improvement in the Network Status APIs[0]. Network Status APIs is going to replace Onionoo web protocol as the Network Health Team moves most of the current bridges and relays data from files stored on disk to Postgres and VictoriaMetrics. We now have an initial working version of the `/summary` and `/bandwidth` endpoint. The first endpoint already has some working filters, while the latter does not yet. In the upcoming weeks we plan to stabilize and test these endpoints while we continue the development of others. The project initially started and was setup to look like a Onionoo copy to prevent most clients from breaking and for a smoother transition to the new protocol. We are now in the process of redefining some responses as the Onionoo implementation introduces some limitations. In particular, changes will affect responses that contain timeseries data stored on VictoriaMetrics as we thought it made more sense to just return a direct ref to VictoriaMetrics[1] for those requests, this way a client can decide to fetch referenced data or not based on its needs. Please do reach out to me, hiro or GeKo if you have any ideas or feedback you'd like to share with us. Cheers, Matt [0]: https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/ [1]: https://gitlab.torproject.org/tpo/network-health/metrics/networkstatusapi/-…

1 0