The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:10:22Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/643tor shouldn't load the config file with --hash-password2020-06-27T14:10:22ZTractor shouldn't load the config file with --hash-passwordI noticed that tor uses the config file /etc/tor/torrc when I use --hash-password too: if I run
"tor --hash-password ..." from a unprivileged user I expect to simply receive the hashed password
but actually tor reads the system wide co...I noticed that tor uses the config file /etc/tor/torrc when I use --hash-password too: if I run
"tor --hash-password ..." from a unprivileged user I expect to simply receive the hashed password
but actually tor reads the system wide config file and fails because of user/group settings.
A simple workaround is to create a 'empty' config file and pass it to tor using the '-f' option.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: mrfreehttps://gitlab.torproject.org/tpo/core/tor/-/issues/646miscellaneous stream event bugs for DNS requests2020-06-27T14:10:22ZRobert Hoganmiscellaneous stream event bugs for DNS requestsThe response to a reverse lookup from the controller looks like:
650 ADDRMAP REVERSE[64.4.33.7] lc2.bay0.hotmail.com "2008-03-29 21:59:05" EXPIRES="2008-03-29 21:59:05"
Except when the result is already cached. Then it looks like:
650...The response to a reverse lookup from the controller looks like:
650 ADDRMAP REVERSE[64.4.33.7] lc2.bay0.hotmail.com "2008-03-29 21:59:05" EXPIRES="2008-03-29 21:59:05"
Except when the result is already cached. Then it looks like:
650 ADDRMAP 64.4.33.7 lc2.bay0.hotmail.com "2008-03-29 21:59:05" EXPIRES="2008-03-29 21:59:05"
The 'REVERSE' is missing. Not sure which way is the 'correct' way - assume it's the non-cached response.
Also,
- There's currently no 'NEW' stream event for DNS requests. Add one.
- Cached reverse DNS requests get a 'CLOSE' event but no 'NEW' event. Just drop the 'CLOSE' event, since no conn is created.
Index: src/or/connection_edge.c
===================================================================
--- src/or/connection_edge.c (revision 14233)
+++ src/or/connection_edge.c (working copy)
@@ -1348,13 +1348,16 @@
&map_expires)) {
char *result = tor_strdup(socks->address);
/* remember _what_ is supposed to have been resolved. */
- strlcpy(socks->address, orig_address, sizeof(socks->address));
+ tor_snprintf(socks->address, sizeof(socks->address), "REVERSE[%s]",
+ orig_address);
connection_ap_handshake_socks_resolved(conn, RESOLVED_TYPE_HOSTNAME,
strlen(result), result, -1,
map_expires);
+ strlcpy(socks->address, orig_address, sizeof(socks->address));
connection_mark_unattached_ap(conn,
- END_STREAM_REASON_DONE |
- END_STREAM_REASON_FLAG_ALREADY_SOCKS_REPLIED);
+ END_STREAM_REASON_DONE |
+ END_STREAM_REASON_FLAG_ALREADY_SOCKS_REPLIED |
+ END_STREAM_REASON_FLAG_ALREADY_SENT_CLOSED);
return 0;
}
if (options->ClientDNSRejectInternalAddresses) {
@@ -2084,9 +2087,11 @@
string_addr, payload_len) < 0)
return -1; /* circuit is closed, don't continue */
+ ap_conn->_base.address = tor_strdup("(Tor_internal)");
ap_conn->_base.state = AP_CONN_STATE_RESOLVE_WAIT;
log_info(LD_APP,"Address sent for resolve, ap socket %d, n_circ_id %d",
ap_conn->_base.s, circ->_base.n_circ_id);
+ control_event_stream_status(ap_conn, STREAM_EVENT_NEW, 0);
control_event_stream_status(ap_conn, STREAM_EVENT_SENT_RESOLVE, 0);
return 0;
}
[Automatically added by flyspray2trac: Operating System: All]https://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/650Using the .exit notation does not work with trunk (currently r14296)2020-06-27T14:10:21ZSebastian HahnUsing the .exit notation does not work with trunk (currently r14296)I suspect r14281 to be the culprit.
What happens is the following: No matter which exit node I choose via the .exit-notation,
I get a message in a log that the destination could not be reached using that exit. To double-check, I
downg...I suspect r14281 to be the culprit.
What happens is the following: No matter which exit node I choose via the .exit-notation,
I get a message in a log that the destination could not be reached using that exit. To double-check, I
downgraded to 0.2.0.23-rc and used the exact same URL - and it worked as expected (except for using yourself as exit node, of course).
[Automatically added by flyspray2trac: Operating System: All]https://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/652Tor doesn't detect when the world cannot reach it anymore2020-06-27T14:10:21ZSebastian HahnTor doesn't detect when the world cannot reach it anymoreThis is Tor r14297. When my internet connection dies (as it does every 24 hours),
and I come back up with a different IP address, Tor doesn't seem to notice that
the world cannot connect to it anymore. This used to be different in the p...This is Tor r14297. When my internet connection dies (as it does every 24 hours),
and I come back up with a different IP address, Tor doesn't seem to notice that
the world cannot connect to it anymore. This used to be different in the pre-RC
versions, I haven't checked the previous RCs for that behaviour. Even after 6 hours,
Tor has nothing in the Notice-level log.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/tpo/core/tor/-/issues/653geoip_remove_old_clients() never gets called?2020-06-27T14:10:21ZRoger Dingledinegeoip_remove_old_clients() never gets called?We never call geoip_remove_old_clients(). This means bridge relays
just grow a larger and larger pile of client geoip entries.
I would fix suggest to fix it in the same way we clean up other
items:
=====================================...We never call geoip_remove_old_clients(). This means bridge relays
just grow a larger and larger pile of client geoip entries.
I would fix suggest to fix it in the same way we clean up other
items:
===================================================================
--- main.c (revision 14322)
+++ main.c (working copy)
@@ -988,6 +988,7 @@
/* Remove old information from rephist and the rend cache. */
if (time_to_clean_caches < now) {
rep_history_clean(now - options->RephistTrackTime);
+ geoip_remove_old_clients(now - options->RephistTrackTime);
rend_cache_clean();
rend_cache_clean_v2_descs_as_dir();
#define CLEAN_CACHES_INTERVAL (30*60)
===================================================================
--- geoip.c (revision 14322)
+++ geoip.c (working copy)
@@ -326,6 +326,7 @@
char *result = NULL;
if (!geoip_is_loaded())
return NULL;
+ geoip_remove_old_clients(now - get_options()->RephistTrackTime);
if (client_history_starts < (now - 12*60*60)) {
char buf[32];
smartlist_t *chunks = NULL;
But there's a problem. If we publish a descriptor very often, then the
difference between "the past 24 hours at point x" and "the past 24 hours
at point x+\delta" will give away what happened a day ago, to whatever
granularity we happen to have between the two descriptor updates.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/tpo/core/tor/-/issues/654Don't re-use entry point for testing circuits2020-06-27T14:10:21ZNick MathewsonDon't re-use entry point for testing circuitsMoving from TODO into a bug report, since this is a bug:
- we try to build 4 test circuits to break them over different
servers. but sometimes our entry node is the same for multiple
test circuits. this defeats the point.
[A...Moving from TODO into a bug report, since this is a bug:
- we try to build 4 test circuits to break them over different
servers. but sometimes our entry node is the same for multiple
test circuits. this defeats the point.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/tpo/core/tor/-/issues/655using all free CPU time in router_get_by_nickname2020-06-27T14:10:21ZTracusing all free CPU time in router_get_by_nicknameThis has happened with both Tor v0.2.1.0-alpha-dev r14297 and r14259.
Quite seldom, tor starts eating all CPU time, with nothing interesting logged with "Log debug stderr"
(debug output looks(?! ;) ) the same as when tor is not hogging a...This has happened with both Tor v0.2.1.0-alpha-dev r14297 and r14259.
Quite seldom, tor starts eating all CPU time, with nothing interesting logged with "Log debug stderr"
(debug output looks(?! ;) ) the same as when tor is not hogging all CPU).
I for now "worked around" this by using only hex digests in ExcludeNodes.
Thread 1 (Thread 0x2b5b3a251700 (LWP 17463)):
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#1 0x00005555555dd68f in router_get_by_nickname () from /proc/17463/exe
legacy/trac#2 0x00005555555de5e2 in add_nickname_list_to_smartlist ()
legacy/trac#3 0x00005555555e00ce in router_choose_random_node () from /proc/17463/exe
legacy/trac#4 0x000055555556aff7 in circuit_establish_circuit () from /proc/17463/exe
legacy/trac#5 0x0000555555572033 in circuit_get_open_circ_or_launch ()
legacy/trac#6 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
legacy/trac#7 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
legacy/trac#8 0x00005555555692e8 in circuit_send_next_onion_skin () from /proc/17463/exe
legacy/trac#9 0x00005555555c44b1 in connection_edge_process_relay_cell ()
legacy/trac#10 0x00005555555c5869 in circuit_receive_relay_cell () from /proc/17463/exe
legacy/trac#11 0x0000555555573e92 in command_process_cell () from /proc/17463/exe
legacy/trac#12 0x000055555558e16d in connection_or_process_cells_from_inbuf ()
legacy/trac#13 0x000055555558f4ec in connection_or_process_inbuf () from /proc/17463/exe
legacy/trac#14 0x000055555558567b in connection_handle_read () from /proc/17463/exe
legacy/trac#15 0x00005555555ba013 in conn_read_callback () from /proc/17463/exe
legacy/trac#16 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
legacy/trac#17 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
legacy/trac#18 0x00005555555b9e1d in tor_main () from /proc/17463/exe
legacy/trac#19 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
legacy/trac#20 0x0000555555561209 in _start () from /proc/17463/exe
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
Thread 1 (Thread 0x2b5b3a251700 (LWP 17463)):
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#1 0x00005555555dd68f in router_get_by_nickname () from /proc/17463/exe
legacy/trac#2 0x00005555555de5e2 in add_nickname_list_to_smartlist ()
legacy/trac#3 0x00005555555e00ce in router_choose_random_node () from /proc/17463/exe
legacy/trac#4 0x000055555556aff7 in circuit_establish_circuit () from /proc/17463/exe
legacy/trac#5 0x0000555555572033 in circuit_get_open_circ_or_launch ()
legacy/trac#6 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
legacy/trac#7 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
legacy/trac#8 0x000055555557332d in circuit_build_needed_circs () from /proc/17463/exe
legacy/trac#9 0x00005555555b9706 in second_elapsed_callback () from /proc/17463/exe
legacy/trac#10 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
legacy/trac#11 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
legacy/trac#12 0x00005555555b9e1d in tor_main () from /proc/17463/exe
legacy/trac#13 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
legacy/trac#14 0x0000555555561209 in _start () from /proc/17463/exe
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#1 0x00005555555dd68f in router_get_by_nickname () from /proc/17463/exe
legacy/trac#2 0x00005555555de5e2 in add_nickname_list_to_smartlist ()
legacy/trac#3 0x000055555556b340 in circuit_establish_circuit () from /proc/17463/exe
legacy/trac#4 0x0000555555572033 in circuit_get_open_circ_or_launch ()
legacy/trac#5 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
legacy/trac#6 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
legacy/trac#7 0x00005555555692e8 in circuit_send_next_onion_skin () from /proc/17463/exe
legacy/trac#8 0x00005555555c44b1 in connection_edge_process_relay_cell ()
legacy/trac#9 0x00005555555c5869 in circuit_receive_relay_cell () from /proc/17463/exe
legacy/trac#10 0x0000555555573e92 in command_process_cell () from /proc/17463/exe
legacy/trac#11 0x000055555558e16d in connection_or_process_cells_from_inbuf ()
legacy/trac#12 0x000055555558f4ec in connection_or_process_inbuf () from /proc/17463/exe
legacy/trac#13 0x000055555558567b in connection_handle_read () from /proc/17463/exe
legacy/trac#14 0x00005555555ba013 in conn_read_callback () from /proc/17463/exe
legacy/trac#15 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
legacy/trac#16 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
legacy/trac#17 0x00005555555b9e1d in tor_main () from /proc/17463/exe
legacy/trac#18 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
legacy/trac#19 0x0000555555561209 in _start () from /proc/17463/exe
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
#1 0x00005555555bb921 in router_get_consensus_status_by_nickname ()
legacy/trac#2 0x00005555555de685 in add_nickname_list_to_smartlist ()
legacy/trac#3 0x000055555556b340 in circuit_establish_circuit () from /proc/17463/exe
legacy/trac#4 0x0000555555572033 in circuit_get_open_circ_or_launch ()
legacy/trac#5 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
legacy/trac#6 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
legacy/trac#7 0x00005555555692e8 in circuit_send_next_onion_skin () from /proc/17463/exe
legacy/trac#8 0x00005555555c44b1 in connection_edge_process_relay_cell ()
legacy/trac#9 0x00005555555c5869 in circuit_receive_relay_cell () from /proc/17463/exe
legacy/trac#10 0x0000555555573e92 in command_process_cell () from /proc/17463/exe
legacy/trac#11 0x000055555558e16d in connection_or_process_cells_from_inbuf ()
legacy/trac#12 0x000055555558f4ec in connection_or_process_inbuf () from /proc/17463/exe
legacy/trac#13 0x000055555558567b in connection_handle_read () from /proc/17463/exe
legacy/trac#14 0x00005555555ba013 in conn_read_callback () from /proc/17463/exe
legacy/trac#15 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
legacy/trac#16 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
legacy/trac#17 0x00005555555b9e1d in tor_main () from /proc/17463/exe
legacy/trac#18 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
legacy/trac#19 0x0000555555561209 in _start () from /proc/17463/exe
#0 0x00002b5b3992b265 in strcasecmp () from /lib64/libc.so.6
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: Safarihttps://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/658Tor breaks DNS on Linksys router.2020-06-27T14:10:21ZTracTor breaks DNS on Linksys router.I tried Tor 0.1.2.19 for the first time to run it as a relay, but had to stop using it because I found that on 2
occasions TOR would cause my Linksys router to stop returning DNS requests for that machine. All DNS requests on
the machin...I tried Tor 0.1.2.19 for the first time to run it as a relay, but had to stop using it because I found that on 2
occasions TOR would cause my Linksys router to stop returning DNS requests for that machine. All DNS requests on
the machine failed even after a cold boot and my only option was to reset the router by cycling the power.
I tried to set the bandwidth settings to something less demanding, but I could never confirm if they were set
as intended because the controls reset back to "Cable/DSL" instead of the manual settings I specified, and yes
I saved the config after makign the changes.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Yonahhttps://gitlab.torproject.org/tpo/core/tor/-/issues/659When configuring OR/Dir Ports, Tor always processes OR Port change first2020-06-27T14:10:20ZTracWhen configuring OR/Dir Ports, Tor always processes OR Port change firstI wasn't exactly sure how to phrase the subject, so feel free to rename it.
Basically, when you change the OR or Directory Port Settings in Vidalia, Tor
will always try to configure the OR Port first.
This creates a problem if the user...I wasn't exactly sure how to phrase the subject, so feel free to rename it.
Basically, when you change the OR or Directory Port Settings in Vidalia, Tor
will always try to configure the OR Port first.
This creates a problem if the user tries to switch the OR Port and the Dir Port
(or just change the OR Port to the current Dir Port, and change the Dir Port to
anything else). In short, in such a scenario, Tor blocks itself.
For example:
Say a Tor Server was configured to use Dir Port 443 and OR Port 8080.
If the user tried to change it to use Dir Port 80 and OR Port 443, the following
error message would be presented:
[Warning] Could not bind to 0.0.0.0:443: Address already in use [WSAEADDRINUSE ].
Is Tor already running?
This error message would be presented because Tor first closes the OR Port, 8080.
It then tries to open Port 443, but it is already using Port 443 as the Dir Port.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: HANtwisterTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/660swapped params in call to rep_hist_note_used_port2020-06-27T14:10:20ZTracswapped params in call to rep_hist_note_used_portversion: tor-0.2.0.23-rc
[tor/src/or/directory.c:directory_initiate_command:~722]
/* If it's an anonymized connection, remember the fact that we
* wanted it for later: maybe we'll want it again soon. */
if (anonymized_conn...version: tor-0.2.0.23-rc
[tor/src/or/directory.c:directory_initiate_command:~722]
/* If it's an anonymized connection, remember the fact that we
* wanted it for later: maybe we'll want it again soon. */
if (anonymized_connection && use_begindir)
rep_hist_note_used_internal(time(NULL), 0, 1);
else if (anonymized_connection && !use_begindir)
[ The parameters in the following call are swapped compared to the function declaration and
definintion. ]
rep_hist_note_used_port(time(NULL), conn->_base.port);
[tor/src/or.h:~3581]
void rep_hist_note_used_port(uint16_t port, time_t now);
[tor/src/or/rephist.c:~1426]
void
rep_hist_note_used_port(uint16_t port, time_t now)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: aakovahttps://gitlab.torproject.org/tpo/core/tor/-/issues/661tor returns localized web pages2020-06-27T14:10:20ZTractor returns localized web pagesWhen Tors' action results in a 'foreign' IP address, Google (for example) returns the appropriately localized page!
Not a huge problem for Google, I suppose, but
http://www.torproject.org/download.html.de is a challenge for an English s...When Tors' action results in a 'foreign' IP address, Google (for example) returns the appropriately localized page!
Not a huge problem for Google, I suppose, but
http://www.torproject.org/download.html.de is a challenge for an English speaker.
Feature request: would it be possible to perform a reverse-localization lookup in order to stay within the language domain of the originating user?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: pinkylbh3https://gitlab.torproject.org/tpo/core/tor/-/issues/662wrong size for allocation2020-06-27T14:10:20ZTracwrong size for allocation[tor/src/or/dirvote.c:networkstatus_compute_consensus: ~644]
int *named_flag; /* Index of the flag "Named" for votes[j] */
int *unnamed_flag; /* Index of the flag "Unnamed" for votes[j] */
[...]
named_flag = tor_mallo...[tor/src/or/dirvote.c:networkstatus_compute_consensus: ~644]
int *named_flag; /* Index of the flag "Named" for votes[j] */
int *unnamed_flag; /* Index of the flag "Unnamed" for votes[j] */
[...]
named_flag = tor_malloc_zero(sizeof(int*) * smartlist_len(votes));
!^
|
[ This looks wrong, probably we should be using 'sizeof(int)' in the allocation. Probably only affects 64-bit systems. ]
[ Same problem on the next line too: ]
unnamed_flag = tor_malloc_zero(sizeof(int*) * smartlist_len(votes));
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: aakovahttps://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/670Tor Server unable to create a circuit2020-06-27T14:10:20ZTracTor Server unable to create a circuitGreetings:
I've been off my machine for a few days; and when I logged on, I was unable to get Tor to generate a circuit.
I'm on a Fedora Core 9 machine. The following's the thread - thanks for your help.
Apr 22 04:55:06.695 [notice] ...Greetings:
I've been off my machine for a few days; and when I logged on, I was unable to get Tor to generate a circuit.
I'm on a Fedora Core 9 machine. The following's the thread - thanks for your help.
Apr 22 04:55:06.695 [notice] Tor v0.1.2.19. This is experimental software. Do not rely on it for strong anonymity.
Apr 22 04:55:06.701 [notice] Initialized libevent version 1.3e using method epoll. Good.
Apr 22 04:55:06.702 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 22 04:55:08.408 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:08.595 [warn] Unable to mmap new descriptor file at '/var/lib/tor/.tor/cached-routers'.
Apr 22 04:55:08.598 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:09.095 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:09.419 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:09.806 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:09.829 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:55:19.815 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:56:25.758 [notice] I learned some more directory information, but not enough to build a circuit.
Apr 22 04:57:41.703 [notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Apr 22 04:58:27.336 [notice] I learned some more directory information, but not enough to build a circuit.
and so on...
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: robertgray86https://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 Mathewson