dawuud <daw...@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 _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
