[tor-dev] connectivity failure for top 100 relays

[meejah]

dawuud <dawuud at riseup.net> writes:

> Yes I am sure it failed. It would be cool if txtorcon can expose the
> 'reason' but I think that it cannot. I suppose it will show up in the
> tor log file if I set it to debug logging.

txtorcon does expose both the 'reason' and the 'remote_reason' flags
returned by the failure messages. In fact, it returns all flags that Tor
sent during stream or circuit failures.

The **kwargs in stream_closed, circuit_closed or circuit_failed
notifications should all include "REASON" and many times will also
include "REMOTE_REASON" (e.g. if the "other" relay closed the
connection). For convenience, txtorcon also includes lower-cased
versions of all the flags.

>> (C) We should find a link that is failing between two relays that we
>> both control, and look at each one more closely to see if there are any
>> hints. For example, is there anything in the logs? If we turn up the
>> logging, do we get any hints then?

> Sounds good. I would certainly be willing to collaborate with Teor or anyone
> else who might like to help with this.

I'm +1 here too. I'd like to better understand the failures I see in my
scanner as well.

>> (E) I wonder if there's a correlation between the failed links and
>> whether a TLS connection is already established on that link. That
>> is, when there is no connection already, there are many more steps
>> that need to be taken to extend the circuit, and those steps could
>> lead to increased failure rates, either due to the extra time that is
>> needed, or because part of tor's link handshake (NETINFO, etc) is
>> going wrong.

> Ah yes this is another good question for which I currently do not have
> an answer.

Would it be better, then, to pick one first hop and scan (sequentially)
every second-hop using that first hop? (And maybe have say 5 or 10 such
things going on at once?)

-- 
meejah