Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:22Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/648No available nodes after network outage2020-06-27T14:10:22ZTracNo available nodes after network outageActually, it's 23-rc, but the version dropdown box doesn't have the option!
After the dial-up network has gone down for any appreciable time, when it is brought back up I lose the Tor network
and my log file gets filled with:
Tor[4292...Actually, it's 23-rc, but the version dropdown box doesn't have the option!
After the dial-up network has gone down for any appreciable time, when it is brought back up I lose the Tor network
and my log file gets filled with:
Tor[4292]: Failed to find node for hop 0 of our path. Discarding this circuit.
Tor[4292]: No available nodes when trying to choose node. Failing.
It can only be remedied by restarting Tor, whereupon it creates circuits just fine.
I'm wondering if it's because the external IP address has changed but Tor hasn't noticed? If so, can Tor try to
figure out if the external IP address has changed when it encounters this error and reconfigure itself?
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: jasemandude0.2.0.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/tpo/core/tor/-/issues/649When installing the Tor Bundle on OS X, Torbutton will not be installed into ...2020-06-27T14:10:21ZSebastian HahnWhen installing the Tor Bundle on OS X, Torbutton will not be installed into FirefoxI downloaded https://www.torproject.org/dist/vidalia-bundles/vidalia-bundle-0.2.0.23-rc-0.1.2-tiger.dmg and installed onto a clean OS X and Firefox install. Torbutton will not install, but its files are placed into /Library/Torbutton.
I...I downloaded https://www.torproject.org/dist/vidalia-bundles/vidalia-bundle-0.2.0.23-rc-0.1.2-tiger.dmg and installed onto a clean OS X and Firefox install. Torbutton will not install, but its files are placed into /Library/Torbutton.
Is it possible this has been introduced by r14238?
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/651assert in refetching v2 rend desc2020-06-27T14:10:21ZRoger Dingledineassert in refetching v2 rend descReported by nwf on irc:
650 DEBUG conn_read_callback(): socket 7 wants to read.
650 DEBUG connection_handle_listener_read(): Connection accepted on socket 10 (child of fd 7).
650 DEBUG connection_add(): new conn type Socks, socket 10, n...Reported by nwf on irc:
650 DEBUG conn_read_callback(): socket 7 wants to read.
650 DEBUG connection_handle_listener_read(): Connection accepted on socket 10 (child of fd 7).
650 DEBUG connection_add(): new conn type Socks, socket 10, n_conns 6.
650 DEBUG conn_read_callback(): socket 10 wants to read.
650 DEBUG read_to_chunk(): Read 41 bytes. 41 on inbuf.
650 DEBUG connection_ap_handshake_process_socks(): entered.
650 DEBUG fetch_from_buf_socks(): socks4: Everything is here. Success.
650 STREAM 2 NEW 0 eqt5g4fuenphqinx.onion:80 SOURCE_ADDR=127.0.0.1:34547
650 DEBUG connection_ap_handshake_rewrite_and_attach(): Client asked for eqt5g4fuenphqinx.onion:80
650 INFO connection_ap_handshake_rewrite_and_attach(): Got a hidden service request for ID 'eqt5g4fuenphqinx'
650 INFO connection_ap_handshake_rewrite_and_attach(): Unknown descriptor eqt5g4fuenphqinx. Fetching.
650 DEBUG rend_client_refetch_v2_renddesc(): Fetching v2 rendezvous descriptor for service eqt5g4fuenphqinx
650 DEBUG directory_initiate_command(): anonymized 1, use_begindir 1.
650 DEBUG directory_initiate_command(): Initiating hidden-service v2 descriptor fetch
650 INFO connection_ap_make_link(): Making internal anonymized tunnel to 192.251.226.205:443 ...
650 DEBUG connection_add(): new conn type Socks, socket -1, n_conns 7.
650 STREAM 3 NEW 0 192.251.226.205.$5C3EC3DC1CD0E64016BA7C6ED308C98379645967.exit:443 SOURCE_ADDR=(Tor_internal):0
650 WARN Requested exit point '$5C3EC3DC1CD0E64016BA7C6ED308C98379645967' is not known. Closing.
650 STREAM 3 FAILED 0 192.251.226.205.$5C3EC3DC1CD0E64016BA7C6ED308C98379645967.exit:443 REASON=CANT_ATTACH
650 WARN Making tunnel to dirserver failed.
650 INFO directory_get_from_hs_dir(): Sending fetch request for v2 descriptor for service 'eqt5g4fuenphqinx' with descriptor ID 'pejeujtytbl2uiuya6ixtcgmii5qgv46' to hidden service directory 'blutmagie' on port 80.
650 INFO rend_client_refetch_renddesc(): Fetching rendezvous descriptor for service "eqt5g4fuenphqinx"
650 DEBUG directory_initiate_command(): anonymized 1, use_begindir 1.
650 DEBUG directory_initiate_command(): Initiating hidden-service descriptor fetch
650 INFO connection_ap_make_link(): Making internal anonymized tunnel to 86.59.21.38:443 ...
650 DEBUG connection_add(): new conn type Socks, socket -1, n_conns 8.
650 STREAM 4 NEW 0 86.59.21.38.$847B1F850344D7876491A54892F904934E4EB85D.exit:443 SOURCE_ADDR=(Tor_internal):0
650 WARN Requested exit point '$847B1F850344D7876491A54892F904934E4EB85D' is not known. Closing.
650 STREAM 4 FAILED 0 86.59.21.38.$847B1F850344D7876491A54892F904934E4EB85D.exit:443 REASON=CANT_ATTACH
650 WARN Making tunnel to dirserver failed.
650 INFO connection_edge_process_inbuf(): data from edge while in 'waiting for rendezvous desc' state. Leaving it on buffer.
650 DEBUG conn_close_if_marked(): Cleaning up connection (fd -1).
650 STREAM 3 CLOSED 0 192.251.226.205.$5C3EC3DC1CD0E64016BA7C6ED308C98379645967.exit:443 REASON=CANT_ATTACH
650 DEBUG connection_remove(): removing socket -1 (type Socks), n_conns now 8
650 INFO _connection_free(): Freeing linked Socks connection [waiting for circuit] with 0 bytes on inbuf, 0 on outbuf.
650+NS
r tor26 hHsfhQNE14dkkaVIkvkEk05OuF0 K9cFUCJz2k01fxgI9/CgaOzaID0 2008-04-01 23:36:04 86.59.21.38 443 80
s Authority Fast Named Stable V2Dir Valid
.
650 OK
650 DEBUG conn_close_if_marked(): Cleaning up connection (fd -1).
650 STREAM 4 CLOSED 0 86.59.21.38.$847B1F850344D7876491A54892F904934E4EB85D.exit:443 REASON=CANT_ATTACH
650 DEBUG connection_remove(): removing socket -1 (type Socks), n_conns now 7
650 INFO _connection_free(): Freeing linked Socks connection [waiting for circuit] with 0 bytes on inbuf, 0 on outbuf.
650+NS
r blutmagie XD7D3BzQ5kAWunxu0wjJg3lkWWc IKLuwxRgB/abDds0UHeo0MSZQIk 2008-04-02 10:40:23 192.251.226.205 443 80
s Exit Fast Guard HSDir Stable Unnamed V2Dir Valid
.
650 OK
650 ERR Bug: rendclient.c:426: rend_client_refetch_v2_renddesc: Assertion strlen(query) == REND_SERVICE_ID_LEN_BASE32 failed; aborting.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/656Tor server crash in SSL_free with DH crypto error in logs2020-06-27T14:10:21ZMike PerryTor server crash in SSL_free with DH crypto error in logsJust got a crash in r14173. Have a warn in the log right before:
Apr 12 12:30:19.323 [warn] crypto error while generating DH key: BN lib (in Diff
ie-Hellman routines:GENERATE_KEY).
Here is the backtrace of the thread that caused the cr...Just got a crash in r14173. Have a warn in the log right before:
Apr 12 12:30:19.323 [warn] crypto error while generating DH key: BN lib (in Diff
ie-Hellman routines:GENERATE_KEY).
Here is the backtrace of the thread that caused the crash:
#0 0x4cef366c in EVP_CIPHER_CTX_cleanup () from /lib/libcrypto.so.6
#1 0x4cfc4f35 in ssl_clear_cipher_ctx () from /lib/libssl.so.6
legacy/trac#2 0x4cfc6ab5 in SSL_free () from /lib/libssl.so.6
legacy/trac#3 0x080f335c in tor_tls_free (tls=0x40df1ac0) at tortls.c:831
legacy/trac#4 0x0806d2eb in _connection_free (conn=0x46229f00) at connection.c:328
legacy/trac#5 0x080a363c in connection_unlink (conn=0x46229f00) at main.c:212
legacy/trac#6 0x080a390e in close_closeable_connections () at main.c:603
legacy/trac#7 0x4cfe4125 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#8 0x4cfe4349 in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#9 0x080a5149 in do_main_loop () at main.c:1446
legacy/trac#10 0x080a52fb in tor_main (argc=3, argv=0x59c9d5c4) at main.c:1986
legacy/trac#11 0x080d9ee2 in main (argc=Cannot access memory at address 0x0
The cpuworker thread was in the process of spitting out another
(or perhaps just finished the original?) warn:
#0 0x4cffe402 in __kernel_vsyscall ()
#1 0x4cdcbf7b in write () from /lib/libc.so.6
legacy/trac#2 0x4cd6d884 in _IO_new_file_write () from /lib/libc.so.6
legacy/trac#3 0x4cd6d545 in new_do_write () from /lib/libc.so.6
legacy/trac#4 0x4cd6d82f in _IO_new_do_write () from /lib/libc.so.6
legacy/trac#5 0x4cd6e006 in _IO_new_file_sync () from /lib/libc.so.6
legacy/trac#6 0x4cd62c3c in fflush () from /lib/libc.so.6
legacy/trac#7 0x080daaa7 in logv (severity=4, domain=2, funcname=0x0,
format=0x8124004 "crypto error while %s: %s (in %s:%s)",
ap=0x4aaa6eec "°<\022\baáõLÄßõL>ÀõLàV¾4\200") at log.c:295
legacy/trac#8 0x080dad0e in _log (severity=4, domain=2,
format=0x8124004 "crypto error while %s: %s (in %s:%s)") at log.c:314
legacy/trac#9 0x080eb1a7 in crypto_log_errors (severity=4,
doing=0x8123cb0 "generating DH key") at crypto.c:146
legacy/trac#10 0x080ec104 in crypto_dh_generate_public (dh=0x34be56e0) at crypto.c:1467
legacy/trac#11 0x080ec31b in crypto_dh_get_public (scrubbed) at crypto.c:1492
legacy/trac#12 0x080a9e7e in onion_skin_server_handshake (scrubbed)
at onion.c:267
legacy/trac#13 0x08083a70 in cpuworker_main (data=0x4c2f2090) at cpuworker.c:284
legacy/trac#14 0x080e11ed in tor_pthread_helper_fn (_data=0x4c2f20a0) at compat.c:1482
legacy/trac#15 0x4ce5745b in start_thread () from /lib/libpthread.so.0
legacy/trac#16 0x4cddb24e in clone () from /lib/libc.so.6
Unfortunately the logs were at notice. The node had just started, not much else was present.
I'm rerunning it at info.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/663netinfo clock skew warn too loud2020-06-27T14:10:20ZRoger Dingledinenetinfo clock skew warn too loudkeb> ok i got another of these with Tor 0.2.0.23-rc (running as client only)
: Apr 17 12:52:19.184 [Warning] Received NETINFO cell with skewed time from
server at 195.24.77.135:80. It seems that our clock is ahead by 2 hours, 15
minutes...keb> ok i got another of these with Tor 0.2.0.23-rc (running as client only)
: Apr 17 12:52:19.184 [Warning] Received NETINFO cell with skewed time from
server at 195.24.77.135:80. It seems that our clock is ahead by 2 hours, 15
minutes, or that theirs is behind. Tor requires an accurate clock to work:
please check your time and date settings.
We only complain about skew for directory requests when
int trusted = router_digest_is_trusted_dir(conn->identity_digest);
Perhaps we should do something similar for clients looking at netinfo cells?
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/669Clients don't realize that a server has a different identity than stated in c...2020-06-27T14:10:20ZKarsten LoesingClients don't realize that a server has a different identity than stated in consensusThis problem came up when trying to access a hidden service on a "recent"
trunk version (0.2.1.0-alpha-dev, exact revision number unknown). Log by
killerchicken (times manually changed to GMT):
Apr 20 20:33:04.853 [Warning] Received NET...This problem came up when trying to access a hidden service on a "recent"
trunk version (0.2.1.0-alpha-dev, exact revision number unknown). Log by
killerchicken (times manually changed to GMT):
Apr 20 20:33:04.853 [Warning] Received NETINFO cell with skewed time from
server at 195.24.77.135:80. It seems that our clock is ahead by 1 hours,
42 minutes, or that theirs is behind. Tor requires an accurate clock to
work: please check your time and date settings.
Apr 20 20:33:29.545 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:33:34.959 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:33:40.914 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:33:40.967 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:33:40.984 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
...
Apr 20 20:34:57.817 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:35:03.500 [Warning] Tried connecting to router at
91.89.159.76:9001, but identity key was not as expected: wanted
CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 but got
FDD88040C0C98EE9EB573041A2C8824E9EFC4CE4.
Apr 20 20:35:16.144 [Notice] Rend stream is 120 seconds late. Giving up on
address '[scrubbed].onion'.
Apr 20 20:37:16.783 [Notice] Rend stream is 120 seconds late. Giving up on
address '[scrubbed].onion'.
The server with identity CCFDBED5463B7F308C0EF909F00B25889F6A7EF8 is
HALLIGonALB which has changed identity keys just before the consensus was
created. At 19:18:44 the server indeed had the identity CCFDBED5..., but
it changed to FDD88040... at 19:50:57:
router HALLIGonALB 91.89.159.76 9001 0 0
platform Tor 0.2.0.23-rc (r14173) on Linux i686
opt protocols Link 1 Circuit 1
published 2008-04-20 19:18:44
opt fingerprint CCFD BED5 463B 7F30 8C0E F909 F00B 2588 9F6A 7EF8
router HALLIGonALB 91.89.159.76 9001 0 9030
platform Tor 0.2.0.23-rc (r14173) on Linux i686
opt protocols Link 1 Circuit 1
published 2008-04-20 19:50:57
opt fingerprint FDD8 8040 C0C9 8EE9 EB57 3041 A2C8 824E 9EFC 4CE4
The server is listed in the consensus as:
r HALLIGonALB zP2+1UY7fzCMDvkJ8AsliJ9qfvg UcgjQHY3+4ftvO7CXn4DJ9v9TkY
2008-04-20 19:21:44 91.89.159.76 9001 9030
The bug here is that clients should stop creating connections to nodes that
have "lied" about their identity before. The warning message comes from
connection_or.c:789 in connection_or_check_valid_tls_handshake().
Attempts to reproduce this error by (1) always failing the condition in
connection_or.c:782 or (2) failing after 2 attempts by introducing a static
counter (rationale: the third connection attempt will be the first when
actually trying to access a hidden service) failed. In all cases the
"failing" nodes were correctly removed from the entry guards list and
marked as down.
When this bug will be spotted again, an info-level or even debug-level log
might help in understanding what happens in detail.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/671tor 0.2.0.24-rc: mutex initialization problem?2020-06-27T14:10:20ZTractor 0.2.0.24-rc: mutex initialization problem?This bug report actually applies only to 0.2.0.24-rc (the field was not
available yet in the Version entry above.) This version of tor cannot now
be built on FreeBSD 7-STABLE i386 with multithreading support. The resulting
binary du...This bug report actually applies only to 0.2.0.24-rc (the field was not
available yet in the Version entry above.) This version of tor cannot now
be built on FreeBSD 7-STABLE i386 with multithreading support. The resulting
binary dumps core. I believe the error is related to problems with the
initialization of the recursive mutexes introduced for logging in the new
version of tor. Pthreads in this version of FreeBSD are handled in libthr,
and the pertinent libraries are supposed to be POSIX compliant. (See
http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/libthr .) A backtrace of crashes
of the test program run during "make check" and of the tor binary:
#0 0x2838129b in pthread_mutexattr_init () from /lib/libthr.so.3
#1 0x2838141b in pthread_mutex_init () from /lib/libthr.so.3
legacy/trac#2 0x0810f835 in tor_mutex_new () at compat.c:1756
legacy/trac#3 0x08108b84 in init_logging () at log.c:498
legacy/trac#4 0x0810f4b0 in main (c=1 v=Cannot access memory at address 0x4
) at test.c:3564
#0 0x2835029b in pthread_mutexattr_init () from /lib/libthr.so.3
#1 0x2835041b in pthread_mutex_init () from /lib/libthr.so.3
legacy/trac#2 0x080e9f45 in tor_mutex_new () at compat.c:1756
legacy/trac#3 0x080e3294 in init_logging () at log.c:498
legacy/trac#4 0x080aae7c in tor_main (argc=1 argv=0xbfbfeaa4) at min.c:1968
legacy/trac#5 0x080e2982 in main (argc=Cannot access memory at address 0x0
) at tor_main.c:29
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: jmurphy0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/672[warn] Still had some address policies cached at shutdown.2020-06-27T14:10:19ZRoger Dingledine[warn] Still had some address policies cached at shutdown.Apr 23 14:40:08.135 [notice] Clean shutdown finished. Exiting.
Apr 23 14:40:08.765 [warn] Still had some address policies cached at shutdown.
This happens consistently on moria1 (running 0.2.0.24-rc) and moria2 (running
0.2.1.0-alpha...Apr 23 14:40:08.135 [notice] Clean shutdown finished. Exiting.
Apr 23 14:40:08.765 [warn] Still had some address policies cached at shutdown.
This happens consistently on moria1 (running 0.2.0.24-rc) and moria2 (running
0.2.1.0-alpha-dev (r14424)).
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/678man page entries for RejectPlaintextPorts and WarnPlaintextPorts2020-06-27T14:10:19ZRoger Dingledineman page entries for RejectPlaintextPorts and WarnPlaintextPortswe're missing man page entries for those two config options.
[Automatically added by flyspray2trac: Operating System: All]we're missing man page entries for those two config options.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/681encrypted dir conns confuse LeaveStreamsUnattached2020-06-27T14:10:19ZRoger Dingledineencrypted dir conns confuse LeaveStreamsUnattached(This is Mikeperry's bug)
When we launch an encrypted dir conn in directory.c via
connection_ap_make_link(), it'll put the stream in state
AP_CONN_STATE_CIRCUIT_WAIT. This means that even controllers
that set LeaveStreamsUnattached won'...(This is Mikeperry's bug)
When we launch an encrypted dir conn in directory.c via
connection_ap_make_link(), it'll put the stream in state
AP_CONN_STATE_CIRCUIT_WAIT. This means that even controllers
that set LeaveStreamsUnattached won't need to handle it,
since it's already being handled.
Bug #1: controllers don't know this, and can't distinguish
streams that are already being handled. Mike had a patch to
put an extra flag on the stream status line.
Bug legacy/trac#2: then if the stream causes a circuit to get created, and gets
attached to that circuit, but the circuit times out or otherwise
fails to fulfill the request, the stream will be handled by
connection_ap_detach_retriable() which will set it to state
AP_CONN_STATE_CONTROLLER_WAIT. And the controller doesn't realize
that this time it's supposed to handle it (and it probably shouldn't
need to handle it)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewson