dawuud dawuud@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?)