Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:59:17Zhttps://gitlab.torproject.org/legacy/trac/-/issues/602Add ability to ExcludeNodes by IP.2020-06-13T13:59:17ZNick MathewsonAdd ability to ExcludeNodes by IP.Some people would like to be able to reject Tor nodes by IP or subnet rather than by fingerprint or nickname.
[Automatically added by flyspray2trac: Operating System: All]Some people would like to be able to reject Tor nodes by IP or subnet rather than by fingerprint or nickname.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/603option to specify minimal eligible speed for nodes used2020-06-13T13:59:17ZTracoption to specify minimal eligible speed for nodes usedI think it would be nice if I could set a bandwidth limit and/or average ping limit for my tor client.
For example I could ensure that all nodes to be used has 1Mbit or greater bandwidth. Its really slow to
have a 50Kbit node in the midd...I think it would be nice if I could set a bandwidth limit and/or average ping limit for my tor client.
For example I could ensure that all nodes to be used has 1Mbit or greater bandwidth. Its really slow to
have a 50Kbit node in the middle of two 4Mbit nodes...
Thanks,
András
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: iarpost 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/604Tor 0.1.2.19 server crash on Solaris Sparc2020-06-13T13:59:19ZTracTor 0.1.2.19 server crash on Solaris SparcDear Developpers,
I have successfully compiled and run openssl 0.9.8g, libevent 1.3e and tor 0.1.2.19 with gcc-4.2.2 in a Solaris 10 Sparc Zone as a Tor client.
As soon as I uncomment ORPort in torrc to enable the server it starts initi...Dear Developpers,
I have successfully compiled and run openssl 0.9.8g, libevent 1.3e and tor 0.1.2.19 with gcc-4.2.2 in a Solaris 10 Sparc Zone as a Tor client.
As soon as I uncomment ORPort in torrc to enable the server it starts initializing and crashes with a "Bus Error" while checking reachability and bandwidth.
When I block port 9001 on the firewall it does not crash, but obviously not work also. :)
Trace of the startup included below, with level info and level debug at the final stage.
I do not get a core dumped.
#ulimit -a
core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
open files (-n) 256
pipe size (512 bytes, -p) 10
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 14117
virtual memory (kbytes, -v) unlimited
Tried to increase open files to 1024 with no difference.
Any help is greatly appreciated.
Thanks,
Jan
Feb 09 11:24:46.399 [notice] Tor v0.1.2.19. This is experimental software. Do not rely on it for strong anonymity.
Feb 09 11:24:46.404 [warn] You specified a public address '0.0.0.0' for a SOCKS proxy. Other people on the Internet might find your computer and use it as an open SOCKS proxy. Please don't allow this unless you have a good reason.
Feb 09 11:24:46.405 [notice] Choosing default nickname 'tor'
Feb 09 11:24:46.406 [notice] Your ContactInfo config option is not set. Please consider setting it, so we can contact you if your server is misconfigured or something else goes wrong.
Feb 09 11:24:46.410 [notice] Initialized libevent version 1.3e using method event ports. Good.
Feb 09 11:24:46.412 [notice] Opening OR listener on 0.0.0.0:9001
Feb 09 11:24:46.413 [notice] Opening Socks listener on 0.0.0.0:9050
Feb 09 11:24:46.413 [notice] Opening Control listener on 0.0.0.0:9051
Feb 09 11:24:46.418 [info] or_state_load(): Loaded state from "/usr/local/tor/var/state"
Feb 09 11:24:46.437 [info] crypto_seed_rng(): Seeding RNG from "/dev/urandom"
Feb 09 11:24:46.439 [info] configure_nameservers(): Parsing resolver configuration in '/etc/resolv.conf'
Feb 09 11:24:46.439 [info] eventdns: Parsing resolv.conf file /etc/resolv.conf
Feb 09 11:24:46.441 [info] eventdns: Added nameserver xxxxxxx
Feb 09 11:24:46.442 [info] eventdns: Added nameserver xxxxxxx
Feb 09 11:24:46.442 [info] eventdns: Setting maximum allowed timeouts to 3
Feb 09 11:24:46.443 [info] eventdns: Setting timeout to 5
Feb 09 11:24:46.444 [info] init_keys(): Reading/making identity key "/usr/local/tor/var/keys/secret_id_key"...
Feb 09 11:24:46.620 [info] init_keys(): Reading/making onion key "/usr/local/tor/var/keys/secret_onion_key"...
platform Tor 0.1.2.19 on SunOS sun4u
published 2008-02-09 10:24:50
opt fingerprint xxxx xxxx xxxx xxxx
uptime 0
bandwidth 3145728 6291456 0
onion-key
-----BEGIN RSA PUBLIC KEY-----
[...]
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
[...]
-----END RSA PUBLIC KEY-----
opt write-history 2008-02-09 10:24:46 (900 s)
opt read-history 2008-02-09 10:24:46 (900 s)
[...]
Feb 09 11:24:50.620 [info] init_keys(): Dumping fingerprint to "/usr/local/tor/var/fingerprint"...
Feb 09 11:24:50.622 [notice] Your Tor server's identity key fingerprint is 'xxxx xxxx xxxx'
Feb 09 11:24:55.294 [info] router_load_routers_from_string(): 1690 elements to add
Feb 09 11:24:56.435 [info] router_load_routers_from_string(): 365 elements to add
[...]
Feb 09 11:24:56.806 [info] router_set_networkstatus(): Setting networkstatus cached from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-08 16:14:02)
Feb 09 11:24:56.806 [info] networkstatus_list_update_recent(): Networkstatus from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-08 16:14:02) is now "recent"
Feb 09 11:24:57.017 [debug] check_directory_signature(): Signed directory hash starts 4529A66E
Feb 09 11:24:57.021 [info] router_set_networkstatus(): Setting networkstatus cached from directory server "tor26" at 86.59.21.38:80 (published 2008-02-08 21:44:01)
Feb 09 11:24:57.021 [info] networkstatus_list_update_recent(): Networkstatus from directory server "tor26" at 86.59.21.38:80 (published 2008-02-08 21:44:01) is now "recent"
Feb 09 11:24:57.244 [debug] check_directory_signature(): Signed directory hash starts DE69E0AF
Feb 09 11:24:57.247 [info] router_set_networkstatus(): Setting networkstatus cached from directory server "dizum" at 194.109.206.212:80 (published 2008-02-08 22:35:27)
Feb 09 11:24:57.248 [info] networkstatus_list_update_recent(): Networkstatus from directory server "dizum" at 194.109.206.212:80 (published 2008-02-08 22:35:27) is now "recent"
Feb 09 11:24:57.458 [debug] check_directory_signature(): Signed directory hash starts FFF46957
Feb 09 11:24:57.462 [info] router_set_networkstatus(): Setting networkstatus cached from directory server "moria2" at 128.31.0.34:9032 (published 2008-02-08 16:34:41)
Feb 09 11:24:57.462 [info] networkstatus_list_update_recent(): Networkstatus from directory server "moria2" at 128.31.0.34:9032 (published 2008-02-08 16:34:41) is now "recent"
Feb 09 11:24:57.463 [info] networkstatus_list_update_recent(): Networkstatus from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-08 16:14:02) is no longer "recent"
Feb 09 11:24:57.669 [debug] check_directory_signature(): Signed directory hash starts BB7A2DAC
Feb 09 11:24:57.672 [info] router_set_networkstatus(): Setting networkstatus cached from directory server "lefkada" at 140.247.60.64:80 (published 2008-02-08 22:09:03)
Feb 09 11:24:57.673 [info] networkstatus_list_update_recent(): Networkstatus from directory server "lefkada" at 140.247.60.64:80 (published 2008-02-08 22:09:03) is now "recent"
Feb 09 11:24:57.673 [info] networkstatus_list_update_recent(): Networkstatus from directory server "moria2" at 128.31.0.34:9032 (published 2008-02-08 16:34:41) is no longer "recent"
Feb 09 11:24:57.674 [info] routerstatus_list_update_from_networkstatus(): Rebuilding router status list.
Feb 09 11:24:57.692 [info] routerstatus_list_update_from_networkstatus(): Naming authorities disagree about which key goes with joestorserver. ($86D83F4F853EDFEEAD1EF3B17CE2034F8397A8F6 vs $0731DD94CD90068DAFE31DBC449F1BA36C6DF277)
[...]
Feb 09 11:24:58.637 [debug] routerstatus_list_update_from_networkstatus(): Router 'FightFascism' is listed by 5/5 directories, named by 2/3, validated by 5/5, and 3/3 recent directories think it's running.
Feb 09 11:24:58.638 [warn] Naming authorities disagree about nicknames for $C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB ("PoderosoTorII" vs "PoderosoTorIII")
[...]
Feb 09 11:24:59.353 [info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another exit circ.
Feb 09 11:24:59.358 [info] choose_good_exit_server_general(): Found 628 servers that might support 0/0 pending connections.
Feb 09 11:24:59.363 [info] choose_good_exit_server_general(): Chose exit server 'superbad'
[...]
Feb 09 11:24:59.670 [info] connection_dir_client_reached_eof(): Received server info (size 3265) from server '87.106.188.238:80'
Feb 09 11:24:59.674 [info] router_load_routers_from_string(): 1 elements to add
Feb 09 11:24:59.736 [info] connection_dir_client_reached_eof(): Received 1/1 routers requested from 87.106.188.238:80
[...]
Feb 09 11:24:59.846 [info] connection_dir_client_reached_eof(): Received networkstatus objects (size 382650) from server '91.121.7.211:80'
Feb 09 11:25:00.063 [info] router_set_networkstatus(): Setting networkstatus downloaded from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-09 09:58:14)
Feb 09 11:25:00.079 [info] networkstatus_list_update_recent(): Networkstatus from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-09 09:58:14) is now "recent"
Feb 09 11:25:00.080 [info] networkstatus_list_update_recent(): Networkstatus from directory server "tor26" at 86.59.21.38:80 (published 2008-02-08 21:44:01) is no longer "recent"
Feb 09 11:25:00.081 [info] routerstatus_list_update_from_networkstatus(): Rebuilding router status list.
Feb 09 11:25:00.108 [info] routerstatus_list_update_from_networkstatus(): Naming authorities disagree about which key goes with JoesTorServer. ($0731DD94CD90068DAFE31DBC449F1BA36C6DF277 vs $86D83F4F853EDFEEAD1EF3B17CE2034F8397A8F6)
[...]
Feb 09 11:25:01.589 [info] entry_guards_compute_status(): Summary: Entry 'rfc1149' is reachable, usable and live.
Feb 09 11:25:01.589 [info] entry_guards_compute_status(): Summary: Entry 'Bellum' is reachable, unusable and not live.
Feb 09 11:25:01.590 [info] entry_guards_compute_status(): Summary: Entry 'SuperDuperLative' is reachable, usable and live.
Feb 09 11:25:01.590 [info] entry_guards_compute_status(): Summary: Entry 'lolnode' is reachable, usable and live.
Feb 09 11:25:01.590 [debug] tor_version_is_obsolete(): Checking whether version '0.1.2.19' is in '0.1.2.19,0.2.0.11-alpha,0.2.0.12-alpha,0.2.0.15-alpha,0.2.0.18-alpha'
Feb 09 11:25:01.590 [debug] tor_version_is_obsolete(): Checking whether version '0.1.2.19' is in '0.1.2.17,0.1.2.18,0.1.2.19,0.2.0.6-alpha,0.2.0.7-alpha,0.2.0.8-alpha,0.2.0.9-alpha,0.2.0.10-alpha,0.2.0.11-alpha,0.2.0.12-alpha,0.2.0.13-alpha,0.2.0.14-alpha,0.2.0.15-alpha,0.2.0.16-alpha,0.2.0.17-alpha,0.2.0.18-alpha'
Feb 09 11:25:01.590 [debug] tor_version_is_obsolete(): Checking whether version '0.1.2.19' is in '0.1.2.19,0.2.0.11-alpha,0.2.0.12-alpha,0.2.0.15-alpha,0.2.0.18-alpha'
Feb 09 11:25:01.591 [info] routers_update_all_from_networkstatus(): 3/3 statements from version-listing directory authorities say my version is ok.
Feb 09 11:25:01.643 [debug] conn_close_if_marked(): Cleaning up connection (fd 14).
Feb 09 11:25:01.643 [debug] connection_remove(): removing socket 14 (type Directory), n_conns now 5
Feb 09 11:25:01.644 [debug] _connection_free(): closing fd 14.
Feb 09 11:25:01.644 [debug] conn_read_callback(): socket 16 wants to read.
Feb 09 11:25:01.891 [debug] connection_tls_continue_handshake(): wanted read
Feb 09 11:25:01.892 [debug] global_read_bucket now 6291456.
Feb 09 11:25:01.892 [debug] global_write_bucket now 6291456.
Feb 09 11:25:01.893 [debug] circuit_remove_handled_ports(): Port 80 is not handled.
Feb 09 11:25:01.893 [info] circuit_predict_and_launch_new(): Have 1 clean circs (0 internal), need another exit circ.
Feb 09 11:25:01.894 [debug] new_route_len(): Chosen route length 3 (1813 routers available).
Feb 09 11:25:01.898 [info] choose_good_exit_server_general(): Found 616 servers that might support 0/0 pending connections.
Feb 09 11:25:01.899 [debug] circuit_remove_handled_ports(): Port 80 is not handled.
Feb 09 11:25:01.902 [info] choose_good_exit_server_general(): Chose exit server 'almostunknown'
Feb 09 11:25:02.319 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'SuperDuperLative'
Feb 09 11:25:02.362 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'rfc1149'
Feb 09 11:25:02.473 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:02.473 [info] exit circ (length 3, exit almostunknown): rfc1149(open) keinezensurde(closed) almostunknown(closed)
Feb 09 11:25:02.474 [debug] command_process_created_cell(): Moving to next skin.
Feb 09 11:25:02.474 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:02.509 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:02.510 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:02.510 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:02.511 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:02.511 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:02.512 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:02.513 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:02.513 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:02.596 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:02.597 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:02.597 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:02.597 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:02.598 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:02.599 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:02.599 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:02.600 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:02.600 [debug] connection_edge_process_relay_cell(): Now seen 1 relay cells here.
Feb 09 11:25:02.601 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:02.633 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:02.634 [info] exit circ (length 3, exit almostunknown): rfc1149(open) keinezensurde(open) almostunknown(closed)
Feb 09 11:25:02.634 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:02.669 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:02.670 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:02.670 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:02.671 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:02.671 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:02.672 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:02.672 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:02.673 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:02.673 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:02.920 [debug] global_read_bucket now 6291456.
Feb 09 11:25:02.920 [debug] global_write_bucket now 6291456.
Feb 09 11:25:02.971 [info] circuit_predict_and_launch_new(): Have 2 clean circs (0 uptime-internal, 0 internal), need another hidserv circ.
Feb 09 11:25:02.972 [debug] new_route_len(): Chosen route length 3 (1813 routers available).
Feb 09 11:25:02.974 [debug] onion_extend_cpath(): Path is 0 long; we want 3
Feb 09 11:25:02.975 [debug] onion_extend_cpath(): Chose router rfc1149 for hop 1 (exit is aim1loxal1net)
Feb 09 11:25:02.975 [debug] onion_extend_cpath(): Path is 1 long; we want 3
Feb 09 11:25:02.976 [debug] choose_good_middle_server(): Contemplating intermediate hop: random choice.
Feb 09 11:25:02.979 [debug] onion_extend_cpath(): Chose router petspaper for hop 2 (exit is aim1loxal1net)
Feb 09 11:25:02.979 [debug] onion_extend_cpath(): Path is 2 long; we want 3
Feb 09 11:25:02.980 [debug] onion_extend_cpath(): Chose router aim1loxal1net for hop 3 (exit is aim1loxal1net)
Feb 09 11:25:02.980 [debug] onion_extend_cpath(): Path is complete: 3 steps long
Feb 09 11:25:02.981 [debug] circuit_handle_first_hop(): Looking for firsthop '88.191.14.223:9001'
Feb 09 11:25:02.981 [debug] circuit_handle_first_hop(): Conn open. Delivering first onion skin.
Feb 09 11:25:02.982 [debug] circuit_send_next_onion_skin(): First skin; sending create cell.
Feb 09 11:25:03.018 [debug] circuit_deliver_create_cell(): Chosen circID 23586.
Feb 09 11:25:03.019 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:03.019 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'rfc1149'
Feb 09 11:25:03.020 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:03.022 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:03.022 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:03.086 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:03.086 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:03.087 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:03.087 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:03.088 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:03.088 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:03.089 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:03.089 [debug] command_process_created_cell(): at OP. Finishing handshake.
Feb 09 11:25:03.122 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:03.122 [info] internal (high-uptime) circ (length 3, exit aim1loxal1net): rfc1149(open) petspaper(closed) aim1loxal1net(closed)
Feb 09 11:25:03.123 [debug] command_process_created_cell(): Moving to next skin.
Feb 09 11:25:03.123 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:03.158 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:03.159 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:03.159 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:03.160 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:03.160 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:03.161 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:03.161 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:03.162 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:03.346 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:03.346 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:03.347 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:03.347 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:03.348 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:03.348 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:03.349 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:03.349 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:03.350 [debug] connection_edge_process_relay_cell(): Now seen 2 relay cells here.
Feb 09 11:25:03.350 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:03.383 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:03.384 [info] internal (high-uptime) circ (length 3, exit aim1loxal1net): rfc1149(open) petspaper(open) aim1loxal1net(closed)
Feb 09 11:25:03.384 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:03.419 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:03.419 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:03.420 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:03.421 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:03.421 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:03.421 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:03.422 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:03.423 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:03.423 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.020 [debug] global_read_bucket now 6291456.
Feb 09 11:25:04.021 [debug] global_write_bucket now 6291456.
Feb 09 11:25:04.021 [info] circuit_predict_and_launch_new(): Have 3 clean circs (1 uptime-internal, 1 internal), need another hidserv circ.
Feb 09 11:25:04.022 [debug] new_route_len(): Chosen route length 3 (1813 routers available).
Feb 09 11:25:04.023 [debug] onion_extend_cpath(): Path is 0 long; we want 3
Feb 09 11:25:04.024 [debug] onion_extend_cpath(): Chose router rfc1149 for hop 1 (exit is ArnoldBros1905)
Feb 09 11:25:04.025 [debug] onion_extend_cpath(): Path is 1 long; we want 3
Feb 09 11:25:04.025 [debug] choose_good_middle_server(): Contemplating intermediate hop: random choice.
Feb 09 11:25:04.028 [debug] onion_extend_cpath(): Chose router wiredwings for hop 2 (exit is ArnoldBros1905)
Feb 09 11:25:04.029 [debug] onion_extend_cpath(): Path is 2 long; we want 3
Feb 09 11:25:04.029 [debug] onion_extend_cpath(): Chose router ArnoldBros1905 for hop 3 (exit is ArnoldBros1905)
Feb 09 11:25:04.030 [debug] onion_extend_cpath(): Path is complete: 3 steps long
Feb 09 11:25:04.030 [debug] circuit_handle_first_hop(): Looking for firsthop '88.191.14.223:9001'
Feb 09 11:25:04.031 [debug] circuit_handle_first_hop(): Conn open. Delivering first onion skin.
Feb 09 11:25:04.031 [debug] circuit_send_next_onion_skin(): First skin; sending create cell.
Feb 09 11:25:04.066 [debug] circuit_deliver_create_cell(): Chosen circID 23587.
Feb 09 11:25:04.066 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.067 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'rfc1149'
Feb 09 11:25:04.067 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:04.068 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.069 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.146 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:04.147 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:04.147 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.147 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.148 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:04.149 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:04.149 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:04.149 [debug] command_process_created_cell(): at OP. Finishing handshake.
Feb 09 11:25:04.183 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:04.184 [info] internal (high-uptime) circ (length 3, exit ArnoldBros1905): rfc1149(open) wiredwings(closed) ArnoldBros1905(closed)
Feb 09 11:25:04.184 [debug] command_process_created_cell(): Moving to next skin.
Feb 09 11:25:04.184 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:04.219 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:04.220 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:04.220 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:04.224 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.225 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:04.225 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:04.226 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.227 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.301 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:04.302 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:04.302 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.302 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.303 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:04.304 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:04.304 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:04.304 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:04.305 [debug] connection_edge_process_relay_cell(): Now seen 3 relay cells here.
Feb 09 11:25:04.305 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:04.340 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:04.341 [info] internal (high-uptime) circ (length 3, exit ArnoldBros1905): rfc1149(open) wiredwings(open) ArnoldBros1905(closed)
Feb 09 11:25:04.341 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:04.376 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:04.377 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:04.377 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:04.378 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:04.378 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.380 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:04.381 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:04.382 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.382 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.544 [debug] conn_read_callback(): socket 16 wants to read.
Feb 09 11:25:04.545 [debug] connection_read_to_buf(): 16: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:04.545 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.546 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.546 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:04.547 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:04.547 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:04.548 [debug] command_process_created_cell(): at OP. Finishing handshake.
Feb 09 11:25:04.580 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:04.581 [info] exit circ (length 3, exit superbad): SuperDuperLative(open) DrazziBTorNode(closed) superbad(closed)
Feb 09 11:25:04.582 [debug] command_process_created_cell(): Moving to next skin.
Feb 09 11:25:04.582 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:04.617 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:04.617 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:04.618 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:04.618 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.619 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:04.619 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:04.620 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:04.620 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.621 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.621 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:04.622 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:04.622 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:04.623 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:04.623 [debug] connection_edge_process_relay_cell(): Now seen 4 relay cells here.
Feb 09 11:25:04.624 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:04.656 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:04.657 [info] internal (high-uptime) circ (length 3, exit ArnoldBros1905): rfc1149(open) wiredwings(open) ArnoldBros1905(open)
Feb 09 11:25:04.657 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:04.657 [info] circuit_send_next_onion_skin(): circuit built!
Feb 09 11:25:04.658 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Feb 09 11:25:04.659 [notice] Now checking whether ORPort x.x.x.x:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Feb 09 11:25:04.661 [info] consider_testing_reachability(): Testing reachability of my ORPort: x.x.x.x:9001.
Feb 09 11:25:04.661 [debug] new_route_len(): Chosen route length 3 (1813 routers available).
Feb 09 11:25:04.662 [info] onion_pick_cpath_exit(): Using requested exit node 'tor'
Feb 09 11:25:04.663 [debug] onion_extend_cpath(): Path is 0 long; we want 3
Feb 09 11:25:04.664 [debug] onion_extend_cpath(): Chose router rfc1149 for hop 1 (exit is tor)
Feb 09 11:25:04.664 [debug] onion_extend_cpath(): Path is 1 long; we want 3
Feb 09 11:25:04.664 [debug] choose_good_middle_server(): Contemplating intermediate hop: random choice.
Feb 09 11:25:04.683 [info] compute_preferred_testing_list(): Looking for middle server that doesn't have the reachability bug, and chose 'Gollum'. Great.
Feb 09 11:25:04.684 [debug] onion_extend_cpath(): Chose router Gollum for hop 2 (exit is tor)
Feb 09 11:25:04.685 [debug] onion_extend_cpath(): Path is 2 long; we want 3
Feb 09 11:25:04.685 [debug] onion_extend_cpath(): Chose router tor for hop 3 (exit is tor)
Feb 09 11:25:04.685 [debug] onion_extend_cpath(): Path is complete: 3 steps long
Feb 09 11:25:04.686 [debug] circuit_handle_first_hop(): Looking for firsthop '88.191.14.223:9001'
Feb 09 11:25:04.686 [debug] circuit_handle_first_hop(): Conn open. Delivering first onion skin.
Feb 09 11:25:04.687 [debug] circuit_send_next_onion_skin(): First skin; sending create cell.
Feb 09 11:25:04.722 [debug] circuit_deliver_create_cell(): Chosen circID 23588.
Feb 09 11:25:04.722 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.723 [info] circuit_send_next_onion_skin(): First hop: finished sending CREATE cell to 'rfc1149'
Feb 09 11:25:04.723 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:04.724 [debug] conn_write_callback(): socket 16 wants to write.
Feb 09 11:25:04.725 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.725 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.726 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:04.726 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.727 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:04.795 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:04.796 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:04.796 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.797 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:04.797 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:04.798 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:04.798 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:04.799 [debug] command_process_created_cell(): at OP. Finishing handshake.
Feb 09 11:25:04.831 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:04.832 [info] internal circ (length 3, exit tor): rfc1149(open) $BF39AFADE1ECAB0373459236D31C6A0E3B59CB82(closed) $795EC4D74109C3B4CD7ECB2B652AEF51F99CA5FB(closed)
Feb 09 11:25:04.833 [debug] command_process_created_cell(): Moving to next skin.
Feb 09 11:25:04.833 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:04.868 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:04.868 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:04.869 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:04.869 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:04.870 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:04.870 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:04.871 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:04.872 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:05.070 [debug] global_read_bucket now 6291456.
Feb 09 11:25:05.071 [debug] global_write_bucket now 6291456.
Feb 09 11:25:05.738 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:05.738 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:05.739 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:05.739 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:05.740 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:05.740 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:05.741 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:05.741 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:05.742 [debug] connection_edge_process_relay_cell(): Now seen 5 relay cells here.
Feb 09 11:25:05.742 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:05.775 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:05.775 [info] exit circ (length 3, exit almostunknown): rfc1149(open) keinezensurde(open) almostunknown(open)
Feb 09 11:25:05.776 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:05.776 [info] circuit_send_next_onion_skin(): circuit built!
Feb 09 11:25:05.776 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:06.080 [debug] global_read_bucket now 6291456.
Feb 09 11:25:06.452 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:06.452 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:06.452 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.452 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.453 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:06.453 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:06.453 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:06.453 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:06.453 [debug] connection_edge_process_relay_cell(): Now seen 6 relay cells here.
Feb 09 11:25:06.453 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:06.486 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:06.487 [info] internal (high-uptime) circ (length 3, exit aim1loxal1net): rfc1149(open) petspaper(open) aim1loxal1net(open)
Feb 09 11:25:06.487 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:06.488 [info] circuit_send_next_onion_skin(): circuit built!
Feb 09 11:25:06.488 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:06.553 [debug] conn_read_callback(): socket 16 wants to read.
Feb 09 11:25:06.554 [debug] connection_read_to_buf(): 16: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:06.554 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.554 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.555 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:06.556 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:06.556 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:06.557 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:06.557 [debug] connection_edge_process_relay_cell(): Now seen 7 relay cells here.
Feb 09 11:25:06.557 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:06.590 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:06.590 [info] exit circ (length 3, exit superbad): SuperDuperLative(open) DrazziBTorNode(open) superbad(closed)
Feb 09 11:25:06.591 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:06.628 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:06.629 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:06.629 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:06.630 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:06.630 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:06.631 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:06.631 [debug] conn_write_callback(): socket 16 wants to write.
Feb 09 11:25:06.632 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:06.632 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:06.685 [debug] conn_read_callback(): socket 11 wants to read.
Feb 09 11:25:06.686 [debug] connection_read_to_buf(): 11: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:06.686 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.687 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:06.688 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:06.688 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:06.688 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:06.689 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:06.689 [debug] connection_edge_process_relay_cell(): Now seen 8 relay cells here.
Feb 09 11:25:06.690 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:06.723 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:06.723 [info] internal circ (length 3, exit tor): rfc1149(open) $BF39AFADE1ECAB0373459236D31C6A0E3B59CB82(open) $795EC4D74109C3B4CD7ECB2B652AEF51F99CA5FB(closed)
Feb 09 11:25:06.724 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:06.759 [debug] circuit_send_next_onion_skin(): Sending extend relay cell.
Feb 09 11:25:06.759 [debug] relay_send_command_from_edge(): delivering 6 cell forward.
Feb 09 11:25:06.760 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:06.760 [debug] circuit_package_relay_cell(): crypting a layer of the relay cell.
Feb 09 11:25:06.761 [debug] write_to_buf(): added 512 bytes to buf (now 512 total).
Feb 09 11:25:06.761 [debug] connection_or_process_cells_from_inbuf(): 11: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:06.762 [debug] conn_write_callback(): socket 11 wants to write.
Feb 09 11:25:06.763 [debug] flush_buf_tls_impl(): flushed 512 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:06.763 [debug] connection_handle_write(): After TLS write of 512: 0 read, 586 written
Feb 09 11:25:07.091 [debug] global_read_bucket now 6291456.
Feb 09 11:25:07.092 [debug] global_write_bucket now 6291456.
Feb 09 11:25:07.719 [debug] conn_read_callback(): socket 5 wants to read.
Feb 09 11:25:07.720 [debug] connection_handle_listener_read(): Connection accepted on socket 14 (child of fd 5).
Feb 09 11:25:07.721 [debug] connection_add(): new conn type OR, socket 14, n_conns 7.
Feb 09 11:25:07.721 [debug] connection_tls_start_handshake(): starting TLS handshake on fd 14
Feb 09 11:25:07.722 [debug] connection_tls_continue_handshake(): wanted read
Feb 09 11:25:07.732 [debug] conn_read_callback(): socket 14 wants to read.
Feb 09 11:25:07.798 [debug] connection_tls_continue_handshake(): wanted read
Feb 09 11:25:08.033 [debug] conn_read_callback(): socket 14 wants to read.
Feb 09 11:25:08.076 [debug] connection_tls_finish_handshake(): tls handshake done. verifying.
Feb 09 11:25:08.078 [debug] connection_or_check_valid_handshake(): The certificate seems to be valid on incoming connection with [scrubbed]:6169
Feb 09 11:25:08.079 [debug] circuit_n_conn_done(): or_conn to Gollum, status=1
Feb 09 11:25:08.080 [debug] connection_or_process_cells_from_inbuf(): 14: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:08.541 [debug] conn_read_callback(): socket 14 wants to read.
Feb 09 11:25:08.542 [debug] connection_read_to_buf(): 14: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:08.543 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:08.543 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:08.544 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:08.544 [debug] connection_read_to_buf(): After TLS read of 512: 1908 read, 1450 written
Feb 09 11:25:08.544 [debug] connection_or_process_cells_from_inbuf(): 14: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:08.545 [debug] write_to_buf(): added 1 bytes to buf (now 1 total).
Feb 09 11:25:08.545 [debug] write_to_buf(): added 8 bytes to buf (now 9 total).
Feb 09 11:25:08.546 [debug] write_to_buf(): added 186 bytes to buf (now 195 total).
Feb 09 11:25:08.546 [debug] command_process_create_cell(): success: handed off onionskin.
Feb 09 11:25:08.546 [debug] connection_or_process_cells_from_inbuf(): 14: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:08.547 [debug] conn_write_callback(): socket 15 wants to write.
Feb 09 11:25:08.570 [debug] flush_buf(): 15: flushed 195 bytes, 0 ready to flush, 0 remain.
Feb 09 11:25:08.571 [debug] conn_read_callback(): socket 16 wants to read.
Feb 09 11:25:08.572 [debug] connection_read_to_buf(): 16: starting, inbuf_datalen 0 (0 pending in tls object). at_most 4096.
Feb 09 11:25:08.572 [debug] read_to_buf_tls(): start: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:08.572 [debug] read_to_buf_tls_impl(): before: 0 on buf, 0 pending, at_most 4096.
Feb 09 11:25:08.573 [debug] read_to_buf_tls_impl(): Read 512 bytes. 512 on inbuf; 0 pending
Feb 09 11:25:08.573 [debug] connection_read_to_buf(): After TLS read of 512: 586 read, 0 written
Feb 09 11:25:08.574 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 512 (0 pending in tls object).
Feb 09 11:25:08.574 [debug] circuit_receive_relay_cell(): Sending to origin.
Feb 09 11:25:08.575 [debug] connection_edge_process_relay_cell(): Now seen 9 relay cells here.
Feb 09 11:25:08.575 [debug] connection_edge_process_relay_cell(): Got an extended cell! Yay.
Feb 09 11:25:08.648 [info] circuit_finish_handshake(): Finished building circuit hop:
Feb 09 11:25:08.648 [info] exit circ (length 3, exit superbad): SuperDuperLative(open) DrazziBTorNode(open) superbad(open)
Feb 09 11:25:08.649 [debug] circuit_send_next_onion_skin(): starting to send subsequent skin.
Feb 09 11:25:08.649 [info] circuit_send_next_onion_skin(): circuit built!
Feb 09 11:25:08.650 [debug] connection_or_process_cells_from_inbuf(): 16: starting, inbuf_datalen 0 (0 pending in tls object).
Feb 09 11:25:08.692 [debug] cpuworker_main(): onion_skin_server_handshake succeeded.
Feb 09 11:25:08.693 [debug] cpuworker_main(): finished writing response.
Feb 09 11:25:08.694 [debug] conn_read_callback(): socket 15 wants to read.
Feb 09 11:25:08.694 [debug] read_to_buf_impl(): Read 229 bytes. 229 on inbuf.
Bus Error
# Feb 09 11:25:08.712 [info] cpuworker_main(): CPU worker exiting because Tor process closed connection (either rotated keys or died).
[Automatically added by flyspray2trac: Operating System: Solaris]
**Trac**:
**Username**: jabahttps://gitlab.torproject.org/legacy/trac/-/issues/605unit tests problem on open/net bsd2020-06-13T13:59:20ZRoger Dingledineunit tests problem on open/net bsdRunning Tor unit tests on OpenBSD i386
============================== buffers
.................................................................................................................................................................Running Tor unit tests on OpenBSD i386
============================== buffers
..................................................................................................................................................................................................................................................................................................................................................................................................................................
============================== crypto
.................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
============================== util
.........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
============================== onion_handshake
.....
============================== dir_format
.....................................test: (0xcf7f7c2c)
test in free(): error: ifree: junk pointer, too high to make sense
Abort trap (core dumped)
(gdb) bt
#0 0x0ca54a25 in kill () from /usr/lib/libc.so.39.3
#1 0x0ca8d353 in abort () at /usr/src/lib/libc/stdlib/abort.c:65
#2 0x0ca746d9 in wrterror (p=0x2ca23400 "ifree: junk pointer, too high to make sense")
at /usr/src/lib/libc/stdlib/malloc.c:434
#3 0x0ca7479b in wrtwarning (p=0x2ca23400 "ifree: junk pointer, too high to make sense")
at /usr/src/lib/libc/stdlib/malloc.c:444
#4 0x0ca7572e in ifree (ptr=0xcf7f7c2c) at /usr/src/lib/libc/stdlib/malloc.c:1750
#5 0x0ca75961 in free (ptr=0xcf7f7c2c) at /usr/src/lib/libc/stdlib/malloc.c:1838
#6 0x1c055781 in addr_policy_free (p=0xcf7f7c2c) at policies.c:899
#7 0x1c0556be in addr_policy_list_free (lst=0x83c385f0) at policies.c:881
#8 0x1c06b0d7 in routerinfo_free (router=0x80cfd300) at routerlist.c:2145
#9 0x1c08f85b in test_dir_format () at test.c:2358
#10 0x1c097ed7 in main (c=1006961088, v=0xcf7fbe7c) at test.c:3599
This is why r13450 is there. We should fix it better, sometime, too.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/606v3 authorities forgetting certs at restart2020-06-13T13:59:21ZRoger Dingledinev3 authorities forgetting certs at restartmoria1 (running r13476) forgets all its certs every time it restarts.
-rw------- 1 tord tord 9804 2008-02-11 23:45 cached-certs
...
Feb 12 15:27:55.253 [info] init_keys(): adding my own v3 cert
Feb 12 15:27:55.253 [info] trusted_di...moria1 (running r13476) forgets all its certs every time it restarts.
-rw------- 1 tord tord 9804 2008-02-11 23:45 cached-certs
...
Feb 12 15:27:55.253 [info] init_keys(): adding my own v3 cert
Feb 12 15:27:55.253 [info] trusted_dirs_load_certs_from_string(): Adding downloa
ded certificate for directory authority moria1 with signing key CCB7170F6B270B44
301712DD7BC04BF9515AF374
Feb 12 15:27:55.254 [debug] mp_pool_new(): Capacity is 992, item size is 528, al
loc size is 523776
Feb 12 15:27:55.254 [debug] authority_cert_parse_from_string(): We already check
ed the signature on this certificate; no need to do so again.
Feb 12 15:27:55.254 [info] trusted_dirs_load_certs_from_string(): Skipping cache
d certificate for moria1 that we already have.
Feb 12 15:27:55.288 [info] router_set_networkstatus_v2(): Setting networkstatus
cached from directory server "moria1" at 128.31.0.34:9031 (published 2008-02-12
20:26:30)
Feb 12 15:27:55.398 [info] router_set_networkstatus_v2(): Setting networkstatus
cached from directory server "tor26" at 86.59.21.38:80 (published 2008-02-12 20:
20:21)
Feb 12 15:27:55.482 [info] router_set_networkstatus_v2(): Setting networkstatus
cached from directory server "moria2" at 128.31.0.34:9032 (published 2008-02-12
20:20:08)
Feb 12 15:27:55.568 [info] router_set_networkstatus_v2(): Setting networkstatus
cached from directory server "dizum" at 194.109.206.212:80 (published 2008-02-12
20:20:01)
Feb 12 15:27:55.653 [info] router_set_networkstatus_v2(): Setting networkstatus
cached from directory server "lefkada" at 140.247.60.64:80 (published 2008-02-12
20:22:06)
Feb 12 15:27:55.741 [info] networkstatus_check_consensus_signature(): Looks like
we need to download a new certificate from authority 'lefkada' at 140.247.60.64
:80 (contact 1024D/0E606699 Geoff Goodell <goodell@eecs.harvard.edu>; identity 0
D95B91896E6089AB9A3C6CB56E724CAF898C43F)
Feb 12 15:27:55.741 [info] networkstatus_check_consensus_signature(): Looks like
we need to download a new certificate from authority 'ides' at 216.224.124.114:
9030 (contact Mike Perry <mikeperryTAfsckedTODorg>; identity 27B6B5996C426270A5C
95488AA5BCEB6BCC86956)
Feb 12 15:27:55.741 [info] networkstatus_check_consensus_signature(): Looks like
we need to download a new certificate from authority 'dannenberg' at dannenberg
.ccc.de:80 (contact J. Random Hacker <anonymizer@ccc.de>; identity 585769C78764D
58426B8B52B6651A5A71137189A)
Feb 12 15:27:55.741 [info] networkstatus_check_consensus_signature(): Looks like
we need to download a new certificate from authority 'tor26' at 86.59.21.38:80
(contact Peter Palfrader <peter@palfrader.org> (PGP Key: 0x94C09C7F; Key fingerp
rint: 5B00 C96D 5D54 AEE1 206B AF84 DE7A AF6E 94C0 9C7F); identity A9AC67E64B20
0BBF2FA26DF194AC0469E2A948C6)
Feb 12 15:27:55.741 [info] networkstatus_check_consensus_signature(): Looks like
we need to download a new certificate from authority 'gabelmoo' at 88.198.7.215
:80 (contact 1024D/F7C11265 Karsten Loesing <karsten dot loesing AT gmx dot net>
; identity EAA879B5C75032E462CB018630D2D0DF46EBA606)
Feb 12 15:27:55.742 [warn] 0 unknown, 5 missing key, 1 good, 0 bad, 0 no signatu
re, 4 required
Feb 12 15:27:55.742 [notice] Not enough certificates to check networkstatus cons
ensus
Feb 12 15:27:55.742 [info] read_file_to_str(): Could not open "moria1/unverified
-consensus": No such file or directory
Feb 12 15:27:55.743 [info] read_file_to_str(): Could not open "/usr/local/share/
tor/fallback-consensus": No such file or directory
Feb 12 15:27:55.743 [notice] We're missing a certificate from authority with sig
ning key 783A368067E26CDD64205EFCF1C5066B5F55EDCB: launching request.
Feb 12 15:27:55.743 [notice] We're missing a certificate from authority with sig
ning key 250A21E163A25851BB574E80DC4E41AE86F60C89: launching request.
Feb 12 15:27:55.743 [notice] We're missing a certificate from authority with sig
ning key F0A23AD304A0CFF4C27B3D0AE23468FBDD4E88F0: launching request.
Feb 12 15:27:55.743 [notice] We're missing a certificate from authority with sig
ning key DAB9DC29E8CFEEEAF8F47F1DE144E2A2F89C4128: launching request.
Feb 12 15:27:55.743 [notice] We're missing a certificate from authority with sig
ning key 2A9EABF158D0D4BFFA6C4A8EDC84A4F6487FCE9B: launching request.
Feb 12 15:27:55.743 [info] router_pick_directory_server(): No reachable router e
ntries for dirservers. Trying them all again.
...
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/607INFO logging is a bit noisy.2020-06-13T13:59:21ZNick MathewsonINFO logging is a bit noisy.Tor logs certain messages a lot more than others. Here are the top ten offenders on peacetime:
1099 info] update_consensus_router_descriptor_downloads(): %d router descriptors downloadable. %d delayed; %d present (%d of those were i...Tor logs certain messages a lot more than others. Here are the top ten offenders on peacetime:
1099 info] update_consensus_router_descriptor_downloads(): %d router descriptors downloadable. %d delayed; %d present (%d of those were in old_routers); %d would_reject; %d wouldnt_use, %d in progress.
1102 info] routerlist_remove_old_routers(): We have %d live routers and %d old router descriptors. At most %d must be retained because of networkstatuses.
1318 info] update_extrainfo_downloads(): Extrainfo download status: %d router with no ei, %d with present ei, %d delaying, %d pending, %d downloadable.
1691 info] connection_close_immediate(): fd %d, type %s, state %s, %d bytes on outbuf.
1787 info] run_connection_housekeeping(): Expiring non-used OR connection to fd %d (%s:%d) [Not in clique mode].
2103 info] directory_handle_command_get(): Client asked for network status lists, but we've been writing too many bytes lately. Sending 503 Dir busy.
5037 info] entry_guards_compute_status(): Summary: Entry '%s' is %s, %s%s, and %s.
10352 info] directory_handle_command_get(): Client asked for server descriptors, but we've been writing too many bytes lately. Sending 503 Dir busy.
12993 info] circuit_extend(): Next router (%s:%d) not connected. Connecting.
15849 info] connection_read_to_buf(): tls error [%s]. breaking (nickname %s, address %s).
This is out of around 60k messages of severity INFO or higher; the top 4 account for 3/4 of all log messages.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/608Clients flip out when two routers use the same identity key2020-06-13T13:59:22ZNick MathewsonClients flip out when two routers use the same identity keyIf two routers are set up to use the same identity key, the authorities will sometimes list both. This confuses
clients. Instead, authorities should only allow one server per key.
[Automatically added by flyspray2trac: Operating Syste...If two routers are set up to use the same identity key, the authorities will sometimes list both. This confuses
clients. Instead, authorities should only allow one server per key.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/609Servers no longer learn IP from authorities2020-06-13T13:59:22ZNick MathewsonServers no longer learn IP from authoritiesAccording to arma, the new code that keeps non-cache serves from using the authorities to download directory information
means that many hosts won't talk to the authorities, and therefore won't learn their IP addresses from the
X-Your-IP...According to arma, the new code that keeps non-cache serves from using the authorities to download directory information
means that many hosts won't talk to the authorities, and therefore won't learn their IP addresses from the
X-Your-IP-Is header.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rchttps://gitlab.torproject.org/legacy/trac/-/issues/610automake complains on debian etch2020-06-13T13:59:22ZRoger Dingledineautomake complains on debian etcharma@last-request:~/torsvn/trunk$ automake --add-missing --copy
src/common/Makefile.am:6: libor_a_SOURCES was already defined in condition TRUE, which implies condition USE_OPENBSD_MALLOC_TRUE
#CFLAGS = -Wall -Wpointer-arith -...arma@last-request:~/torsvn/trunk$ automake --add-missing --copy
src/common/Makefile.am:6: libor_a_SOURCES was already defined in condition TRUE, which implies condition USE_OPENBSD_MALLOC_TRUE
#CFLAGS = -Wall -Wpointer-arith -O2
libor_a_SOURCES (User, where = src/common/Makefile.am:6) +=
{
TRUE => log.c util.c compat.c container.c mempool.c
}
src/common/Makefile.am:6: warning: automake does not support conditional definition of libor_a_SOURCES in libor_a_SOURCES
Use of uninitialized value in concatenation (.) or string at /usr/bin/automake line 8450.
: am_libor_a_OBJECTS was already defined in condition TRUE, which implies condition USE_OPENBSD_MALLOC_TRUE
am_libor_a_OBJECTS (Automake, where = undefined) =
{
TRUE => log.$(OBJEXT) util.$(OBJEXT) compat.$(OBJEXT) container.$(OBJEXT) mempool.$(OBJEXT)
}
It looks like it worked anyway -- I can still build. But this is probably
something we should fix.
$ automake --version
automake (GNU automake) 1.6.3
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/611Apparently, we can use more than 15000 connections2020-06-13T13:59:23ZNick MathewsonApparently, we can use more than 15000 connectionsOn or-talk, Olaf Selke reports:
debugging the "[warn] Error creating network socket: Too
many open files" messages I just found the max number of
file descriptors apparently being ha...On or-talk, Olaf Selke reports:
debugging the "[warn] Error creating network socket: Too
many open files" messages I just found the max number of
file descriptors apparently being hard coded in or.h to a
value of 15.000. Raising the number using ulimit -n thus
shows no effect.
The 15000 cap once made sense when we had a static array of connections, but now that the list is unlimited, there
is no need to have it be an upper bound. Let's change it from an upper bound into a default.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rchttps://gitlab.torproject.org/legacy/trac/-/issues/612tor needs to perform a dir request whenever starting as a server?2020-06-13T13:59:23ZRobert Hogantor needs to perform a dir request whenever starting as a server?[11:54] <mwenge> tor can no longer guess my ip address, so it never builds a desc_routerinfo - which causes all kinds of havoc
[11:56] <mwenge> i'm using trunk
[12:01] <mwenge> it's failing to guess mine completely: tries to figure it ou...[11:54] <mwenge> tor can no longer guess my ip address, so it never builds a desc_routerinfo - which causes all kinds of havoc
[11:56] <mwenge> i'm using trunk
[12:01] <mwenge> it's failing to guess mine completely: tries to figure it out from hostname, then finds the internal address, then says neither of those will do and gives up
[12:02] <mwenge> because it gets nothing from router_pick_published_address it doesn't get past go in router_rebuild_descriptor
[12:02] <mwenge> this results in it failing to assign desc_routerinfo
[12:02] <mwenge> so if i then do a getinfo dir/server/fp/ on my own server fingerprint - I get a segfault
[12:03] <mwenge> because desc_routerinfo doesn't exist and tor's assuming one exists
[12:03] <mwenge> this solves the segfault: http://pastebin.ca/914977
[12:04] <mwenge> but the real problem is failing to guess the ip
[12:05] <mwenge> it can only have been introduced recently because i generally use trunk
[12:10] <mwenge> the real problem is probably in router_guess_address_from_dir_headers somewhere
[12:16] <karsten> mwenge: sry, looking at the commit statements did not reveal (to me) which one changed that behavior.
[12:17] <mwenge> karsten: same here. i think i see the problem. if tor starts and has relatively fresh server info cached it doesn't get an ip from the dir servers until the next time it requests something
[12:17] <mwenge> so last_guessed_ip remains 0. and if you run a server your address remains undetermined
[12:20] <mwenge> so it looks as if tor needs to perform a dir request when starting at all times
[12:20] <mwenge> or else cache x-your-address on file - which seems a bad idea
[12:22] <mwenge> yup. rm -rf cache- and restarting tor gets last_guessed_ip populated again
[12:22] <mwenge> just restarting tor with clearing the cache results it in remaining 0
sorry for the straight paste - i'm lazy
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/613TorButtun 1.1.14: Ubuntu firefox window resize problems2008-02-26T09:26:36ZTracTorButtun 1.1.14: Ubuntu firefox window resize problemsWith the newer release of TorButton I've noticed an interesting new "feature": closing torified tabs made the main firefox window resize, even if it was previously set to fullscreen.
Firefox version is the up to date ubuntu gutsy one (2....With the newer release of TorButton I've noticed an interesting new "feature": closing torified tabs made the main firefox window resize, even if it was previously set to fullscreen.
Firefox version is the up to date ubuntu gutsy one (2.0.0.12+2nobinonly+2-0ubuntu0.7.10).
IIRC I haven't any tabs management extension, however I'll check this problem with an new empty profile and report asap.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: sid77https://gitlab.torproject.org/legacy/trac/-/issues/614Tor crash on 0.2.20-rc2020-06-13T13:59:24ZTracTor crash on 0.2.20-rcHere is the logs :
Feb 25 21:28:23.074 [warn] TLS error while renegotiating handshake with [scrubbed]: sslv3 alert handshake failure (in SSL routines:SSL3_READ_BYTES)
Feb 26 05:40:15.124 [warn] TLS error while renegotiating handshake wi...Here is the logs :
Feb 25 21:28:23.074 [warn] TLS error while renegotiating handshake with [scrubbed]: sslv3 alert handshake failure (in SSL routines:SSL3_READ_BYTES)
Feb 26 05:40:15.124 [warn] TLS error while renegotiating handshake with [scrubbed]: sslv3 alert handshake failure (in SSL routines:SSL3_READ_BYTES)
Feb 26 07:51:54.217 [warn] No ciphers on session
Feb 26 07:51:54.221 [err] Bug: connection.c:1580: connection_buckets_decrement: Assertion num_written < INT_MAX failed; aborting.
Sorry, I don't have a core file.
I've relaunch the same version to see if it happen again.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: Fredzupy0.2.0.22-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/615PROTOCOLINFO returns incorrect auth methods when HashedControlPassword is use...2020-06-13T13:59:24ZedmanmPROTOCOLINFO returns incorrect auth methods when HashedControlPassword is used on command lineTor 0.2.0.20-rc's response to a PROCOLINFO command fails to include the HASHEDPASSWORD method when a
HashedControlPassword is used on the command line. This can be reproduced by starting Tor with the following
command:
tor ControlPo...Tor 0.2.0.20-rc's response to a PROCOLINFO command fails to include the HASHEDPASSWORD method when a
HashedControlPassword is used on the command line. This can be reproduced by starting Tor with the following
command:
tor ControlPort 9051 HashedControlPassword 16:09724E2AACEF0B4C60BD49793E3B2F84912034369B6528CCE2815BBE70
The PROTOCOLINFO command then returns the following results:
edmanm@lysithea:~$ telnet localhost 9051
Trying 127.0.0.1...
Connected to localhost.
Escape character is '!^]'.
protocolinfo
250-PROTOCOLINFO 1
250-AUTH METHODS=NULL
250-VERSION Tor="0.2.0.20-rc"
250 OK
Note that the PROTOCOLINFO response claims Tor does not require any authentication, even though the
HASHEDPASSWORD method should be included in the AUTH METHODS list.
The following patch fixes the problem:
Index: src/or/control.c
===================================================================
--- src/or/control.c (revision 13776)
+++ src/or/control.c (working copy)
@@ -2541,7 +2541,8 @@
char *esc_cfile = esc_for_log(cfile);
char *methods;
{
- int passwd = (options->HashedControlPassword != NULL);
+ int passwd = (options->HashedControlPassword != NULL ||
+ options->HashedControlSessionPassword != NULL);
smartlist_t *mlist = smartlist_create();
if (cookies)
smartlist_add(mlist, (char*)"COOKIE");
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/6160.2.1.0-alpha-dev does not compile on Dapper amd642020-06-13T13:59:24ZKarsten Loesing0.2.1.0-alpha-dev does not compile on Dapper amd64Compiling 0.2.1.0-alpha-dev (r13786) exits with the following error:
tortls.c: In function ‘tor_tls_new’:
tortls.c:738: error: ‘TLS1_TXT_ECDHE_ECDSA_WITH_AES_256_CBC_SHA’ undeclared (first use in this function)
This happens only on Dap...Compiling 0.2.1.0-alpha-dev (r13786) exits with the following error:
tortls.c: In function ‘tor_tls_new’:
tortls.c:738: error: ‘TLS1_TXT_ECDHE_ECDSA_WITH_AES_256_CBC_SHA’ undeclared (first use in this function)
This happens only on Dapper amd64 while compiling on Dapper x86 and Gutsy x86 works fine.
On both machines, openssl version and ciphers are as follows:
/usr/local/ssl/bin/openssl version
OpenSSL 0.9.8g 19 Oct 2007
/usr/local/ssl/bin/openssl ciphers (manually inserted line breaks)
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:
EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:
DHE-DSS-AES128-SHA:AES128-SHA:IDEA-CBC-SHA:IDEA-CBC-MD5:RC2-CBC-MD5:
RC4-SHA:RC4-MD5:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:
DES-CBC-SHA:DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:
EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC4-MD5
The libevent version is in both cases 1.3e.
Configuration is done with:
./configure --with-libevent-dir=/usr/local/lib/ --with-openssl-dir=/usr/local/ssl/lib/
After commenting out the following ciphers from CLIENT_CIPHER_LIST in tortls.c, compilation works again:
TLS1_TXT_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS1_TXT_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS1_TXT_ECDHE_ECDSA_WITH_RC4_128_SHA
TLS1_TXT_ECDHE_RSA_WITH_RC4_128_SHA
TLS1_TXT_ECDHE_ECDSA_WITH_DES_192_CBC3_SHA
TLS1_TXT_ECDHE_RSA_WITH_DES_192_CBC3_SHA
[Automatically added by flyspray2trac: Operating System: Other Linux]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/617DNS bug: duplicate call to connection_mark_for_close at connection_edge.c2020-06-13T13:59:25ZTracDNS bug: duplicate call to connection_mark_for_close at connection_edge.cActually, I'm running 0.2.0.21-rc, not 0.2.0.20-rc
This occurs when tor is running and the modem connects to the ISP
In order to ensure dns requests aren't leaked, my resolv.conf is just
127.0.0.1
127.0.0.1
127.0.0.1
and named is set...Actually, I'm running 0.2.0.21-rc, not 0.2.0.20-rc
This occurs when tor is running and the modem connects to the ISP
In order to ensure dns requests aren't leaked, my resolv.conf is just
127.0.0.1
127.0.0.1
127.0.0.1
and named is set to forward any non-cached queries to port 9999, which tor is listening on for DNS queries.
Here's the debug output:
Mar 05 22:15:01.887 [info] evdns_server_callback(): Got a new DNS request!
Mar 05 22:15:01.887 [debug] connection_add(): new conn type Socks, socket -1, n_conns 23.
Mar 05 22:15:01.887 [info] evdns_server_callback(): Passing request for [scrubbed] to rewrite_and_attach.
Mar 05 22:15:01.887 [debug] connection_ap_handshake_rewrite_and_attach(): Client asked for [scrubbed]:0
Mar 05 22:15:01.887 [warn] Malformed IP "lb._dns-sd._udp.0.0.0.10.in-addr.arpa" in address pattern; rejecting.
Mar 05 22:15:01.887 [debug] connection_ap_handshake_attach_circuit(): Attaching apconn to circ 32257 (stream 0 sec old).
Mar 05 22:15:01.887 [info] exit (high-uptime) circ (length 3): GuyMontag(open) $4539E403341C5B7D7A7494127C12F7DFAEEB5952(open) croeso(open)
Mar 05 22:15:01.887 [debug] link_apconn_to_circ(): attaching new conn to circ. n_circ_id 32257.
Mar 05 22:15:01.887 [warn] Bug: Duplicate call to connection_mark_for_close at connection_edge.c:1504 (first at connection_edge.c:2015)
Mar 05 22:15:01.887 [info] evdns_server_callback(): Passed request for [scrubbed] to rewrite_and_attach.
Mar 05 22:15:01.887 [debug] conn_write_callback(): socket 18 wants to write.
Mar 05 22:15:01.887 [debug] conn_close_if_marked(): Cleaning up connection (fd -1).
Mar 05 22:15:01.887 [debug] connection_remove(): removing socket -1 (type Socks), n_conns now 23
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: jasemandude0.2.0.22-rchttps://gitlab.torproject.org/legacy/trac/-/issues/618disable_referer still active when tor is off2008-04-10T08:08:14ZTracdisable_referer still active when tor is offTorbutton has an option so that "referers aren't sent during Tor usage" (in Torbutton > Options > Security settings > headers)
This option is disabled by defaut.
If I enable it, (don't send referers during Tor usage), referers aren't se...Torbutton has an option so that "referers aren't sent during Tor usage" (in Torbutton > Options > Security settings > headers)
This option is disabled by defaut.
If I enable it, (don't send referers during Tor usage), referers aren't sent even when Tor is not active, i.e. during normal non-Tor browsing.
This breaks some sites, e.g Google Analytics, where CSS and images don't load.
about:config
extension.torbutton.disable_referer true
If I disable the option back, referers work normally again during normal, non-tor browsing.
Tested settings:
1)Debian GNU Linux "lenny"
Iceweasel 2.0.0.12 Mozilla/5.0 (X11; U; Linux i686; it; rv:1.8.1.12) Gecko/20080129 Iceweasel/2.0.0.12 (Debian-2.0.0.12-1)
Tor 0.1.2.19
Torbutton 1.1.16-alpha
2)Windows XP
Firefox 2.0.0.12 Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12
Tor 0.1.2.19
Torbutton 1.1.16-alpha
3) Mac OSX 10.4
Firefox 2.0.0.12
Tor 0.1.2.19
Torbutton 1.1.16-alpha
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: janhttps://gitlab.torproject.org/legacy/trac/-/issues/619exit-policy-reject-star relays should refuse dns?2020-06-13T13:59:25ZRoger Dingledineexit-policy-reject-star relays should refuse dns?lodger points out that non-exit relays could reject dns and reverse dns
attempts. (Currently clients try not to ask them any questions, but the
relays don't enforce it. Non-exit relays might be surprised at the dns
requests they are forc...lodger points out that non-exit relays could reject dns and reverse dns
attempts. (Currently clients try not to ask them any questions, but the
relays don't enforce it. Non-exit relays might be surprised at the dns
requests they are forced to do. "also permit reverse resolve for private
addresses, which could lead to leaks of names, in normal circumstances,
only available locally."
Here's his patch:
--- dns.c Tue Feb 26 19:56:28 2008
+++ dns.c Sat Mar 8 12:11:34 2008
@@ -550,7 +550,12 @@
char *hostname = NULL;
is_resolve = exitconn->_base.purpose == EXIT_PURPOSE_RESOLVE;
- r = dns_resolve_impl(exitconn, is_resolve, oncirc, &hostname);
+ routerinfo_t *me = router_get_my_routerinfo();
+ if (is_resolve && me &&
+ policy_is_reject_star(me->exit_policy)) /* non-exit */
+ r = -1;
+ else
+ r = dns_resolve_impl(exitconn, is_resolve, oncirc, &hostname);
switch (r) {
case 1:
/* We got an answer without a lookup -- either the answer was
@@ -659,9 +664,12 @@
* .in-addr.arpa address but this isn't a resolve request, kill the
* connection.
*/
- if ((r = parse_inaddr_arpa_address(exitconn->_base.address, NULL)) != 0) {
- if (r == 1)
+ if ((r = parse_inaddr_arpa_address(exitconn->_base.address, &in)) != 0) {
+ if (r == 1) {
is_reverse = 1;
+ if (is_internal_IP(ntohl(in.s_addr), 0)) /* internal address */
+ return -1;
+ }
if (!is_reverse || !is_resolve) {
if (!is_reverse)
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/620Enable/disable site list2010-05-27T07:56:49ZTracEnable/disable site listIt would be nice if there was a area in preferences for it where you could do a list of sites to ALWAYS
(or ALWAYS not) use tor for, that would override "tor enabled"/"tor disabled".
[Automatically added by flyspray2trac: Operating Sys...It would be nice if there was a area in preferences for it where you could do a list of sites to ALWAYS
(or ALWAYS not) use tor for, that would override "tor enabled"/"tor disabled".
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: paulmerhttps://gitlab.torproject.org/legacy/trac/-/issues/621Authentical/Password Request Bug - Vidalia Startup2020-06-13T13:59:26ZTracAuthentical/Password Request Bug - Vidalia StartupRandomly, upon startup, Vidalia will ask for a control password when none has been intentionally set by myself.
Everything will work fine for the first couple start-ups and then I will be hit with the control password request when Vidal...Randomly, upon startup, Vidalia will ask for a control password when none has been intentionally set by myself.
Everything will work fine for the first couple start-ups and then I will be hit with the control password request when Vidalia attempts to load.
I have "Googled" and tried various suggested workarounds to no avail. The only resolution is uninstalling/reinstalling the bundle each time.
I am using the current stable version 0.1.2.19. The unstable version will not run at all as Vidalia will cause an error in an SSL dll.
Thanks
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: MikeDChttps://gitlab.torproject.org/legacy/trac/-/issues/622Tor 0.2.1.0-alpha-dev (r13924): 100% CPU usage: conn_read_callback(): socket ...2020-06-13T13:59:27ZTracTor 0.2.1.0-alpha-dev (r13924): 100% CPU usage: conn_read_callback(): socket 340 wants to read.I run 0.2.1.0-alpha-dev (r13924) with Linux 2.6.24.3 x86_64, libevent-1.3d + epoll, openssl latest cvs.
I have not noticed this problem with v0.1.* tor.
I noticed 100% CPU usage (for one CPU out of two :) ) and enabled debug:
[debug] co...I run 0.2.1.0-alpha-dev (r13924) with Linux 2.6.24.3 x86_64, libevent-1.3d + epoll, openssl latest cvs.
I have not noticed this problem with v0.1.* tor.
I noticed 100% CPU usage (for one CPU out of two :) ) and enabled debug:
[debug] conn_read_callback(): socket 34 wants to read.
Around 21000 of these per second.
This lasted for several minutes.
Tor started hahaving OK all by itself before I had time to do much, except for oprofile,
but this would probably be obvious also from the debug line.
CPU: P4 / Xeon, speed 2797.2 MHz (estimated)
Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 240000
Counted MACHINE_CLEAR events (cycles with entire machine pipeline cleared) with a unit mask of 0x01 (count a portion of cycles the machine is cleared for any cause) count 12000
Counted FSB_DATA_ACTIVITY events (DRDY or DBSY events on the front side bus) with a unit mask of 0x03 (multiple flags) count 60000
Counted RETIRED_BRANCH_TYPE events (retired branches, selected by type) with a unit mask of 0x1f (multiple flags) count 180000
Counted RETIRED_MISPRED_BRANCH_TYPE events (retired mispredicted branched, selected by type) with a unit mask of 0x1f (multiple flags) count 6000
samples % samples % samples % samples % samples % image name symbol name
18142 10.9848 194 11.7150 40 2.1882 3891 11.3477 4608 24.4158 tor-0.2.1.0-r13924 connection_handle_read
18020 10.9109 164 9.9034 26 1.4223 4022 11.7297 3166 16.7753 tor-0.2.1.0-r13924 conn_read_callback
17185 10.4053 180 10.8696 38 2.0788 6272 18.2916 123 0.6517 tor-0.2.1.0-r13924 assert_connection_ok
12498 7.5674 95 5.7367 9 0.4923 1734 5.0570 72 0.3815 tor-0.2.1.0-r13924 tor_tls_get_error
11508 6.9680 94 5.6763 48 2.6258 3249 9.4753 46 0.2437 tor-0.2.1.0-r13924 assert_buf_ok
10444 6.3237 106 6.4010 23 1.2582 2296 6.6960 551 2.9195 tor-0.2.1.0-r13924 _openssl_locking_cb
9895 5.9913 83 5.0121 11 0.6018 1535 4.4767 38 0.2013 tor-0.2.1.0-r13924 connection_bucket_round_robin
9292 5.6262 89 5.3744 3 0.1641 1694 4.9404 3047 16.1448 tor-0.2.1.0-r13924 tor_tls_renegotiate
8628 5.2242 99 5.9783 17 0.9300 879 2.5635 166 0.8796 [vdso] (tgid:19150 range:0x7fffe7ffe000-0x7fffe8000000) (no symbols)
6003 3.6347 60 3.6232 16 0.8753 184 0.5366 6 0.0318 tor-0.2.1.0-r13924 buf_datalen
4633 2.8052 64 3.8647 751 41.0832 330 0.9624 27 0.1431 tor-0.2.1.0-r13924 router_get_by_nickname
4375 2.6490 41 2.4758 3 0.1641 775 2.2602 8 0.0424 tor-0.2.1.0-r13924 tor_mutex_acquire
4128 2.4995 39 2.3551 3 0.1641 267 0.7787 8 0.0424 tor-0.2.1.0-r13924 tor_mutex_release
4103 2.4843 40 2.4155 0 0 771 2.2485 4500 23.8436 tor-0.2.1.0-r13924 connection_tls_continue_handshake
2698 1.6336 33 1.9928 8 0.4376 511 1.4903 11 0.0583 tor-0.2.1.0-r13924 connection_process_inbuf
2303 1.3944 38 2.2947 7 0.3829 1113 3.2459 15 0.0795 tor-0.2.1.0-r13924 tor_addr_is_internal
2068 1.2521 18 1.0870 4 0.2188 484 1.4115 12 0.0636 tor-0.2.1.0-r13924 connection_is_listener
1699 1.0287 16 0.9662 48 2.6258 102 0.2975 65 0.3444 tor-0.2.1.0-r13924 rijndaelEncrypt
1618 0.9797 14 0.8454 8 0.4376 598 1.7440 6 0.0318 tor-0.2.1.0-r13924 connection_counts_as_relayed_traffic
1615 0.9779 15 0.9058 5 0.2735 151 0.4404 82 0.4345 tor-0.2.1.0-r13924 logv
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: Safari0.2.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/623Torbutton breaks Firefox3b4 bookmarks2008-04-12T06:40:45ZTracTorbutton breaks Firefox3b4 bookmarksI had installed FireFox 3 beta 4. After using FF3 for a little while
with out torbutton. Upon installing torbutton 1.1.16 and restarting
firefox the bookmarks promptly disappeared. Uninstalling TorButton
resolves the issue.
When torb...I had installed FireFox 3 beta 4. After using FF3 for a little while
with out torbutton. Upon installing torbutton 1.1.16 and restarting
firefox the bookmarks promptly disappeared. Uninstalling TorButton
resolves the issue.
When torbutton is installed it appear that all writes to the Bookmarks
are blocked, importing or creating new bookmarks are not possible.
Os: Mac OS X 10.4.11 (PPC)
Browser: Firefox 3 beta 4
Torbutton: 1.1.16
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: torberthttps://gitlab.torproject.org/legacy/trac/-/issues/624Update 1.0 branch for FF 3.x2008-04-12T05:18:16ZTracUpdate 1.0 branch for FF 3.xI know this probably wont be a high priority but would it be possible to get the 1.0 branch updated for FireFox 3.
I have a need for using torbutton on certain occasions and the 1.1.x torbutton branch is a bit of overkill.
[Automatica...I know this probably wont be a high priority but would it be possible to get the 1.0 branch updated for FireFox 3.
I have a need for using torbutton on certain occasions and the 1.1.x torbutton branch is a bit of overkill.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: torberthttps://gitlab.torproject.org/legacy/trac/-/issues/625'SIZE_MAX' undeclared2020-06-13T13:59:27Zweasel (Peter Palfrader)'SIZE_MAX' undeclaredOpenBSD_malloc_Linux.c: In function 'calloc':
OpenBSD_malloc_Linux.c:1941: error: 'SIZE_MAX' undeclared (first use in this function)
OpenBSD_malloc_Linux.c:1941: error: (Each undeclared identifier is reported only once
OpenBSD_malloc_Lin...OpenBSD_malloc_Linux.c: In function 'calloc':
OpenBSD_malloc_Linux.c:1941: error: 'SIZE_MAX' undeclared (first use in this function)
OpenBSD_malloc_Linux.c:1941: error: (Each undeclared identifier is reported only once
OpenBSD_malloc_Linux.c:1941: error: for each function it appears in.)
[on alpha]
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/626Tor v0.2.1.0-alpha-dev r13924, r14010 SIGUSR2+SIGHUP results into invalid free()2020-06-13T13:59:30ZTracTor v0.2.1.0-alpha-dev r13924, r14010 SIGUSR2+SIGHUP results into invalid free()This happens with at least r13924 and r14010.
Linux 2.6.24.3 x86_64, libevent-1.3d + epoll, openssl latest cvs.
SIGUSR2 does not print anything into logs. After I give SIGHUP after SIGUSR2, I get abort() from glibc.
I config file I have:...This happens with at least r13924 and r14010.
Linux 2.6.24.3 x86_64, libevent-1.3d + epoll, openssl latest cvs.
SIGUSR2 does not print anything into logs. After I give SIGHUP after SIGUSR2, I get abort() from glibc.
I config file I have:
Log notice stderr
2008-03-13 23:03:55.563861070 [notice] Received reload signal (hup). Reloading config.
2008-03-13 23:03:55.569223290 *** glibc detected *** /usr/bin/tor: free(): invalid next size (fast): 0x00005555571dcf60 ***
2008-03-13 23:03:55.569225572 ======= Backtrace: =========
2008-03-13 23:03:55.569226102 /lib64/libc.so.6[0x2af1432a7748]
2008-03-13 23:03:55.569226645 /lib64/libc.so.6(cfree+0x76)[0x2af1432a9d86]
2008-03-13 23:03:55.569227269 /usr/bin/tor[0x5555555edec2]
2008-03-13 23:03:55.569227712 /usr/bin/tor[0x5555555ee6a7]
2008-03-13 23:03:55.569228142 /usr/bin/tor[0x55555557bba1]
2008-03-13 23:03:55.569228582 /usr/bin/tor[0x55555557c07a]
2008-03-13 23:03:55.569243287 /usr/bin/tor[0x55555557d3af]
2008-03-13 23:03:55.569243891 /usr/bin/tor[0x55555557d782]
2008-03-13 23:03:55.569244346 /usr/bin/tor[0x5555555b622e]
2008-03-13 23:03:55.569244791 /usr/lib64/libevent-1.3d.so.1(event_base_loop+0x229)[0x2af1423ec659]
2008-03-13 23:03:55.569245497 /usr/bin/tor[0x5555555b96be]
2008-03-13 23:03:55.569245938 /usr/bin/tor[0x5555555b991d]
2008-03-13 23:03:55.569246378 /lib64/libc.so.6(__libc_start_main+0xfa)[0x2af14324c36a]
2008-03-13 23:03:55.569247011 /usr/bin/tor[0x555555561169]
2008-03-13 23:03:55.569251150 ======= Memory map: ========
2008-03-13 23:03:55.569251729 40000000-40001000 ---p 40000000 00:00 0
2008-03-13 23:03:55.569252257 40001000-40801000 rw-p 40001000 00:00 0
2008-03-13 23:03:55.569252770 40801000-40802000 ---p 40801000 00:00 0
2008-03-13 23:03:55.569253305 40802000-41002000 rw-p 40802000 00:00 0
2008-03-13 23:03:55.569253826 3000000000-300001f000 r-xp 00000000 08:06 101888531 /lib64/ld-2.7.90.so
2008-03-13 23:03:55.569254692 300021e000-300021f000 r--p 0001e000 08:06 101888531 /lib64/ld-2.7.90.so
2008-03-13 23:03:55.569259036 300021f000-3000220000 rw-p 0001f000 08:06 101888531 /lib64/ld-2.7.90.so
2008-03-13 23:03:55.569268961 2aaaaab0b000-2aaaaab21000 r-xp 00000000 08:06 103129858 /lib64/libgcc_s-4.3.0-20080229.so.1
2008-03-13 23:03:55.569269977 2aaaaab21000-2aaaaad20000 ---p 00016000 08:06 103129858 /lib64/libgcc_s-4.3.0-20080229.so.1
2008-03-13 23:03:55.569270953 2aaaaad20000-2aaaaad21000 rw-p 00015000 08:06 103129858 /lib64/libgcc_s-4.3.0-20080229.so.1
2008-03-13 23:03:55.569296484 2aaaac000000-2aaaac021000 rw-p 2aaaac000000 00:00 0
2008-03-13 23:03:55.569297338 2aaaac021000-2aaab0000000 ---p 2aaaac021000 00:00 0
2008-03-13 23:03:55.569297996 2af142174000-2af142198000 rw-p 2af142174000 00:00 0
2008-03-13 23:03:55.569298689 2af1421d2000-2af1421e6000 r-xp 00000000 08:06 103433724 /lib64/libz.so.1.2.3
2008-03-13 23:03:55.569299557 2af1421e6000-2af1423e5000 ---p 00014000 08:06 103433724 /lib64/libz.so.1.2.3
2008-03-13 23:03:55.569304663 2af1423e5000-2af1423e6000 rw-p 00013000 08:06 103433724 /lib64/libz.so.1.2.3
2008-03-13 23:03:55.569305639 2af1423e6000-2af1423fc000 r-xp 00000000 08:08 39577920 /usr/lib64/libevent-1.3d.so.1.0.3
2008-03-13 23:03:55.569306609 2af1423fc000-2af1425fc000 ---p 00016000 08:08 39577920 /usr/lib64/libevent-1.3d.so.1.0.3
2008-03-13 23:03:55.569316445 2af1425fc000-2af1425fd000 rw-p 00016000 08:08 39577920 /usr/lib64/libevent-1.3d.so.1.0.3
2008-03-13 23:03:55.569317688 2af1425fd000-2af1425ff000 rw-p 2af1425fd000 00:00 0
2008-03-13 23:03:55.569318376 2af1425ff000-2af14264a000 r-xp 00000000 08:06 107246525 /lib64/libssl.so.0.9.9
2008-03-13 23:03:55.569319413 2af14264a000-2af142849000 ---p 0004b000 08:06 107246525 /lib64/libssl.so.0.9.9
2008-03-13 23:03:55.569324170 2af142849000-2af142851000 rw-p 0004a000 08:06 107246525 /lib64/libssl.so.0.9.9
2008-03-13 23:03:55.569325309 2af142851000-2af142852000 rw-p 2af142851000 00:00 0
2008-03-13 23:03:55.569326014 2af142852000-2af1429e3000 r-xp 00000000 08:06 107246526 /lib64/libcrypto.so.0.9.9
2008-03-13 23:03:55.569327080 2af1429e3000-2af142be3000 ---p 00191000 08:06 107246526 /lib64/libcrypto.so.0.9.9
2008-03-13 23:03:55.569331570 2af142be3000-2af142c06000 rw-p 00191000 08:06 107246526 /lib64/libcrypto.so.0.9.9
2008-03-13 23:03:55.569332704 2af142c06000-2af142c0a000 rw-p 2af142c06000 00:00 0
2008-03-13 23:03:55.569333409 2af142c0a000-2af142c0d000 r-xp 00000000 08:06 104315727 /lib64/libcap.so.1.10
2008-03-13 23:03:55.569334433 2af142c0d000-2af142e0c000 ---p 00003000 08:06 104315727 /lib64/libcap.so.1.10
2008-03-13 23:03:55.569344033 2af142e0c000-2af142e0d000 rw-p 00002000 08:06 104315727 /lib64/libcap.so.1.10
2008-03-13 23:03:55.569344961 2af142e0d000-2af142e24000 r-xp 00000000 08:06 101739635 /lib64/libpthread-2.7.90.so
2008-03-13 23:03:55.569345872 2af142e24000-2af143023000 ---p 00017000 08:06 101739635 /lib64/libpthread-2.7.90.so
2008-03-13 23:03:55.569346803 2af143023000-2af143024000 r--p 00016000 08:06 101739635 /lib64/libpthread-2.7.90.so
2008-03-13 23:03:55.569351250 2af143024000-2af143025000 rw-p 00017000 08:06 101739635 /lib64/libpthread-2.7.90.so
2008-03-13 23:03:55.569352261 2af143025000-2af14302a000 rw-p 2af143025000 00:00 0
2008-03-13 23:03:55.569352869 2af14302a000-2af14302c000 r-xp 00000000 08:06 101739637 /lib64/libdl-2.7.90.so
2008-03-13 23:03:55.569353763 2af14302c000-2af14322c000 ---p 00002000 08:06 101739637 /lib64/libdl-2.7.90.so
2008-03-13 23:03:55.569358212 2af14322c000-2af14322d000 r--p 00002000 08:06 101739637 /lib64/libdl-2.7.90.so
2008-03-13 23:03:55.569359156 2af14322d000-2af14322e000 rw-p 00003000 08:06 101739637 /lib64/libdl-2.7.90.so
2008-03-13 23:03:55.569360079 2af14322e000-2af143395000 r-xp 00000000 08:06 101739636 /lib64/libc-2.7.90.so
2008-03-13 23:03:55.569368855 2af143395000-2af143594000 ---p 00167000 08:06 101739636 /lib64/libc-2.7.90.so
2008-03-13 23:03:55.569369839 2af143594000-2af143598000 r--p 00166000 08:06 101739636 /lib64/libc-2.7.90.so
2008-03-13 23:03:55.569370710 2af143598000-2af143599000 rw-p 0016a000 08:06 101739636 /lib64/libc-2.7.90.so
2008-03-13 23:03:55.569371588 2af143599000-2af14359e000 rw-p 2af143599000 00:00 0
2008-03-13 23:03:55.569384967 2af14359e000-2af1435a6000 r-xp 00000000 08:06 101739639 /lib64/librt-2.7.90.so
2008-03-13 23:03:55.569386236 2af1435a6000-2af1437a5000 ---p 00008000 08:06 101739639 /lib64/librt-2.7.90.so
2008-03-13 23:03:55.569387114 2af1437a5000-2af1437a6000 r--p 00007000 08:06 101739639 /lib64/librt-2.7.90.so
2008-03-13 23:03:55.569388032 2af1437a6000-2af1437a7000 rw-p 00008000 08:06 101739639 /lib64/librt-2.7.90.so
2008-03-13 23:03:55.569393073 2af1437a7000-2af1437a8000 rw-p 2af1437a7000 00:00 0
2008-03-13 23:03:55.569393741 2af1437a8000-2af1437ba000 r-xp 00000000 08:06 101889822 /lib64/libresolv-2.7.90.so
2008-03-13 23:03:55.569394672 2af1437ba000-2af1439b9000 ---p 00012000 08:06 101889822 /lib64/libresolv-2.7.90.so
2008-03-13 23:03:55.569395590 2af1439b9000-2af1439ba000 r--p 00011000 08:06 101889822 /lib64/libresolv-2.7.90.so
2008-03-13 23:03:55.569405152 2af1439ba000-2af1439bb000 rw-p 00012000 08:06 101889822 /lib64/libresolv-2.7.90.so
2008-03-13 23:03:55.569406186 2af1439bb000-2af1439bf000 rw-p 2af1439bb000 00:00 0
2008-03-13 23:03:55.569406782 2af143a1b000-2af143a26000 r-xp 00000000 08:06 101889810 /lib64/libnss_files-2.7.90.so
2008-03-13 23:03:55.569407715 2af143a26000-2af143c25000 ---p 0000b000 08:06 101889810 /lib64/libnss_files-2.7.90.so
2008-03-13 23:03:55.569412290 2af143c25000-2af143c26000 r--p 0000a000 08:06 101889810 /lib64/libnss_files-2.7.90.so
2008-03-13 23:03:55.569413351 2af143c26000-2af143c27000 rw-p 0000b000 08:06 101889810 /lib64/libnss_files-2.7.90.so
2008-03-13 23:03:55.569414292 2af143c27000-2af143c29000 r-xp 00000000 08:06 105432255 /lib64/libnss_mdns4_minimal.so.2
2008-03-13 23:03:55.569418426 2af143c29000-2af143e28000 ---p 00002000 08:06 105432255 /lib64/libnss_mdns4_minimal.so.2
2008-03-13 23:03:55.569419444 2af143e28000-2af143e29000 rw-p 00001000 08:06 105432255 /lib64/libnss_mdns4_minimal.so.2
2008-03-13 23:03:55.569420393 2af143e29000-2af143e2d000 r-xp 00000000 08:06 101889808 /lib64/libnss_dns-2.7.90.so
2008-03-13 23:03:55.569429222 2af143e2d000-2af14402d000 ---p 00004000 08:06 101889808 /lib64/libnss_dns-2.7.90.so
2008-03-13 23:03:55.569430178 2af14402d000-2af14402e000 r--p 00004000 08:06 101889808 /lib64/libnss_dns-2.7.90.so
2008-03-13 23:03:55.569431096 2af14402e000-2af14402f000 rw-p 00005000 08:06 101889808 /lib64/libnss_dns-2.7.90.so
2008-03-13 23:03:55.569432027 2af1440b3000-2af1462b4000 r--p 00000000 08:07 8601139 /var/lib/tor/cached-descriptors
2008-03-13 23:03:55.569436254 2af146915000-2af146976000 rw-p 2af146915000 00:00 0
2008-03-13 23:03:55.569436932 555555554000-55555564b000 r-xp 00000000 08:08 137853895 /usr/bin/tor-0.2.1.0-r14010
2008-03-13 23:03:55.569445856 55555584a000-555555851000 rw-p 000f6000 08:08 137853895 /usr/bin/tor-0.2.1.0-r14010
2008-03-13 23:03:55.569447013 555555851000-555555852000 rw-p 555555851000 00:00 0
2008-03-13 23:03:55.569452180 5555571da000-555559d19000 rw-p 5555571da000 00:00 0 [heap]
2008-03-13 23:03:55.569453021 7fff63cab000-7fff63cc0000 rw-p 7ffffffea000 00:00 0 [stack]
2008-03-13 23:03:55.569453800 7fff63dfe000-7fff63e00000 r-xp 7fff63dfe000 00:00 0 [vdso]
2008-03-13 23:03:55.569454588 ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Safarihttps://gitlab.torproject.org/legacy/trac/-/issues/627Firefox 3 issue tor-toggle2008-03-14T06:28:03ZTracFirefox 3 issue tor-toggleWhen I try and toggle torbutton on/off the status does not change, and when you have torbutton installed it deletes bookmark
tab and removed booksmarks and history. Btw I love tor button keep up the good work!
I'll be excited when the f...When I try and toggle torbutton on/off the status does not change, and when you have torbutton installed it deletes bookmark
tab and removed booksmarks and history. Btw I love tor button keep up the good work!
I'll be excited when the ff3 bugs are fixed :)
defcon
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: defconhttps://gitlab.torproject.org/legacy/trac/-/issues/628Language cloaking doesn't hide character set2020-06-13T00:00:29ZSteven MurdochLanguage cloaking doesn't hide character setTor Button spoofs US English in the "Accept-Language" HTTP, if configured. This is helpful in increasing
the size of the anonymity set. However, the "Accept-Charset" header is not spoofed, which leaks language
information. For example, t...Tor Button spoofs US English in the "Accept-Language" HTTP, if configured. This is helpful in increasing
the size of the anonymity set. However, the "Accept-Charset" header is not spoofed, which leaks language
information. For example, the Simplified Chinese version of the Tor Browser Bundle includes gb2312 in the
accepted character sets, indicating Chinese. Is there any reason not to spoof this header too?
[Automatically added by flyspray2trac: Operating System: All]TorBrowserBundle 2.3.x-stablehttps://gitlab.torproject.org/legacy/trac/-/issues/629Allow diretory mirror only.2020-06-13T13:59:30ZTracAllow diretory mirror only.Currently, in order to mirror the directory, you must relay traffic. Please enable the server to mirror the
directory without having to relay traffic. Sometimes we have more upload than download available, tihs will
ensure we can co...Currently, in order to mirror the directory, you must relay traffic. Please enable the server to mirror the
directory without having to relay traffic. Sometimes we have more upload than download available, tihs will
ensure we can contribute also. Thank you.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: screampost 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/630windows compile warning2020-06-13T13:59:31ZRoger Dingledinewindows compile warningphobos> windows says
phobos> compat.c: In function `set_max_file_descriptors':
phobos> compat.c:781: warning: long unsigned int format, int arg (arg 5)
I can only assume the cygwin, iphone, etc lines will have similar issues.
I'm not su...phobos> windows says
phobos> compat.c: In function `set_max_file_descriptors':
phobos> compat.c:781: warning: long unsigned int format, int arg (arg 5)
I can only assume the cygwin, iphone, etc lines will have similar issues.
I'm not sure if it's better to change the %lu to a %d, or cast the literal
(ugh), or what.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.22-rchttps://gitlab.torproject.org/legacy/trac/-/issues/6310.2.0.x svn fails two unit tests2020-06-13T13:59:31ZRoger Dingledine0.2.0.x svn fails two unit testsTry running src/or/test
File test.c: line 2280 (test_dir_format): assertion failed: (router_dump_router_to_string(buf, 2048, r1, pk2)>0)
(we make a test descriptor without any policy lines in it)
File test.c: line 3000 (test_policies):...Try running src/or/test
File test.c: line 2280 (test_dir_format): assertion failed: (router_dump_router_to_string(buf, 2048, r1, pk2)>0)
(we make a test descriptor without any policy lines in it)
File test.c: line 3000 (test_policies): assertion failed: (ADDR_POLICY_REJECTED == compare_addr_to_addr_policy(0x01020304u, 2, NULL))
[Automatically added by flyspray2trac: Operating System: All]0.2.0.22-rchttps://gitlab.torproject.org/legacy/trac/-/issues/632Tor v0.2.1.0-alpha-dev (r14101): eventdns(?): Assertion conn->read_event failed2020-06-13T13:59:32ZTracTor v0.2.1.0-alpha-dev (r14101): eventdns(?): Assertion conn->read_event failedWith high concurrency, tor eventdns barfs up.
Trying to resolve 100 IP addresses with concurrency of 100+100 (for PTR->A and A->PTR) with command:
random-ip 100 64|DNSCACHEIP=127.0.0.69 dnsfilter -c 100 | DNSCACHEIP=127.0.0.69 dnsfilter ...With high concurrency, tor eventdns barfs up.
Trying to resolve 100 IP addresses with concurrency of 100+100 (for PTR->A and A->PTR) with command:
random-ip 100 64|DNSCACHEIP=127.0.0.69 dnsfilter -c 100 | DNSCACHEIP=127.0.0.69 dnsfilter -c 100 -p
Takes less than a minute till abort().
2008-03-18 19:14:58.980894879 [debug] connection_remove(): removing socket -1 (type Socks), n_conns now 897
2008-03-18 19:14:59.301429897 [debug] conn_write_callback(): socket 24 wants to write.
2008-03-18 19:14:59.301432330 [debug] flush_chunk_tls(): flushed 3901 bytes, 12483 ready to flush, 12483 remain.
2008-03-18 19:14:59.301433263 [debug] flush_chunk_tls(): flushed 4057 bytes, 8426 ready to flush, 8426 remain.
2008-03-18 19:14:59.301434092 [debug] flush_chunk_tls(): flushed 4057 bytes, 4369 ready to flush, 4369 remain.
2008-03-18 19:14:59.301434943 [debug] flush_chunk_tls(): flushed 4057 bytes, 312 ready to flush, 312 remain.
2008-03-18 19:14:59.301435738 [debug] flush_chunk_tls(): flushed 312 bytes, 0 ready to flush, 0 remain.
2008-03-18 19:14:59.301455409 [debug] connection_handle_write(): After TLS write of 16384: 0 read, 16722 written
2008-03-18 19:14:59.301456530 [err] Bug: main.c:300: connection_start_reading: Assertion conn->read_event failed; aborting.
2008-03-18 19:14:59.301457413 main.c:300 connection_start_reading: Assertion conn->read_event failed; aborting.
2008-03-18 19:15:00.340741083 [notice] Tor v0.2.1.0-alpha-dev (r14101). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux x86_64)
I have a big log file, but this should be easily reproducable.
Other notes about eventdns: (maybe this should go in a different bugreport)
- O(N) lookup for transactions IDs (this may or may not show up in the profiles, but is nevertheless not a very clever tactic)
- using malloc+memset instead of calloc
- ad-hoc handling of lists (e.g., would look more readable if you made static inline function list_add instead of doing
ns->next = server_head->next; ns->prev = server_head; server_head->next = ns; etc.)
- useless casts: resolv = (u8 *) malloc((size_t)st.st_size + 1);
- why is it doing CLEAR so often before free?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Safari0.2.0.22-rchttps://gitlab.torproject.org/legacy/trac/-/issues/633Tor retries download for unparseable descriptors2020-06-13T13:59:32ZNick MathewsonTor retries download for unparseable descriptors15:14 <@diseasearma> hm. moria1 is starting to complain
15:14 <@diseasearma> Mar 18 15:00:15.261 [warn] Invalid uptime "-29903"
15:14 <@diseasearma> so is moria2, and my bridge relay.
15:15 <@diseasearma> that's not a very useful warning...15:14 <@diseasearma> hm. moria1 is starting to complain
15:14 <@diseasearma> Mar 18 15:00:15.261 [warn] Invalid uptime "-29903"
15:14 <@diseasearma> so is moria2, and my bridge relay.
15:15 <@diseasearma> that's not a very useful warning message.
15:15 <@diseasearma> Mar 18 15:15:35.895 [info]
connection_dir_client_reached_eof(): Received server
15:15 <@diseasearma> info (size 2471) from server '194.109.206.212:80'
15:16 <@diseasearma> is what prefaces it.
15:16 < nickm> seeing that on peacetime too
15:16 <@diseasearma> looks like my relays are going to dizum to get a
descriptor they don't have,
15:16 <@diseasearma> and it's a descriptor they don't want,
15:16 <@diseasearma> but then they go back again and get it again.
15:17 <@diseasearma> they go back once a minute
15:17 < nickm> looks like they're counting it as a download failure.
15:17 < nickm> there should be some way to mark it as perma-failed.
15:18 * nickm restarts peacetime on the 0.2.0 branch.
15:19 <@diseasearma> ok. we're going to see this come up on or-talk shortly.
15:20 <@diseasearma> i guess i could preemptively post saying it's a known
problem and will be solved 'later'.
15:20 < nickm> s/later/soon/
15:20 < nickm> we can even add a flyspray entry.
15:20 < nickm> s/we/I/
In summary, when we download a descriptor and then can't parse it, we need to remember to never try to download
it again. Also, our log message could be better.
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/634can not resolve A records for domains ending with *.in-addr.arpa2020-06-13T13:59:33ZTraccan not resolve A records for domains ending with *.in-addr.arpaLocal dnscache, no tor:
$ DNSCACHEIP=127.0.0.1 dnsqr a 130.14.169.217.in-addr.arpa
1 130.14.169.217.in-addr.arpa:
61 bytes, 1+1+0+0 records, response, noerror
query: 1 130.14.169.217.in-addr.arpa
answer: 130.14.169.217.in-addr.arpa 3285 ...Local dnscache, no tor:
$ DNSCACHEIP=127.0.0.1 dnsqr a 130.14.169.217.in-addr.arpa
1 130.14.169.217.in-addr.arpa:
61 bytes, 1+1+0+0 records, response, noerror
query: 1 130.14.169.217.in-addr.arpa
answer: 130.14.169.217.in-addr.arpa 3285 A 217.169.14.130
Local dnscache, forwarding queries to tor:
$ DNSCACHEIP=127.0.0.69 dnsqr a 130.14.169.217.in-addr.arpa
1 130.14.169.217.in-addr.arpa:
temporary failure
2008-03-18 21:22:17.921528231 [info] addressmap_register(): Temporary addressmap ('REVERSE[130.14.169.217.in-addr.arpa]' to '130.14.169.217.in-addr.arpa') not performed, since it's already mapped to '130.14.169.217.in-addr.arpa'
Tor version 0.2.1.0-alpha-dev (r14110).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: SafariTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/635eventdns and caching of NXDOMAIN2020-06-13T13:59:33ZTraceventdns and caching of NXDOMAINLocal DNS proxy might not include the SOA record (in case of NXDOMAIN) when it is resolving for tor,
but faking a SOA record should be easy... maybe a config option or #define for the TTL of cached NXDOMAIN?
Now in case of NXDOMAIN, ev...Local DNS proxy might not include the SOA record (in case of NXDOMAIN) when it is resolving for tor,
but faking a SOA record should be easy... maybe a config option or #define for the TTL of cached NXDOMAIN?
Now in case of NXDOMAIN, eventdns does not include Authority RR with SOA record, so clients querying
tor can not cache the NXDOMAIN. They just keep on querying the same thing again and again.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: SafariTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/636torbutton removes protected cookie setting on cookie culler2008-04-12T06:40:53ZTractorbutton removes protected cookie setting on cookie cullerWhen toggling tor any non tor cookies who have been set "protected" in Cookie Culler lose their protection.
It would be great if cookies can keep the protected setting via Cookie Culler post Tor toggle. This allows
user a bit more contr...When toggling tor any non tor cookies who have been set "protected" in Cookie Culler lose their protection.
It would be great if cookies can keep the protected setting via Cookie Culler post Tor toggle. This allows
user a bit more control over cookies. Eg there are only 3 sites I need protected cookies for all the rest
get regularly cleared (non-tor usage).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: torberthttps://gitlab.torproject.org/legacy/trac/-/issues/637More Granular Cookie Control2020-06-12T23:31:28ZTracMore Granular Cookie ControlAdd Cookie Culler type features. Allow protecting of cookies in tor and non-tor mode so
they survive a toggle, this would allow the browsing of forums etc with out the need to
log back in every time you toggle.
Possibly also allow sh...Add Cookie Culler type features. Allow protecting of cookies in tor and non-tor mode so
they survive a toggle, this would allow the browsing of forums etc with out the need to
log back in every time you toggle.
Possibly also allow sharing of specific cookies between states.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: torberthttps://gitlab.torproject.org/legacy/trac/-/issues/638"blocked changed-state history manipulation" after crash2008-03-19T20:52:32ZRoger Dingledine"blocked changed-state history manipulation" after crashIf I load some tabs, then kill my Firefox, then select
'restore session' on the "Restore Previous Session" window,
Then it starts Firefox with my old windows, but it also pops up an
Alert:
"Torbutton blocked changed-state history manipu...If I load some tabs, then kill my Firefox, then select
'restore session' on the "Restore Previous Session" window,
Then it starts Firefox with my old windows, but it also pops up an
Alert:
"Torbutton blocked changed-state history manipulation.
See history settings to allow."
It seems to cancel one of the loading tabs at random once I click ok.
This is repeatable, at least for me.
Torbutton 1.1.17. Didn't happen with 1.1.16.
[Automatically added by flyspray2trac: Operating System: All]Mike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/639The uninstall-script isn't copied into /Library/Tor/ on Mac OS X2008-03-20T17:12:11ZSebastian HahnThe uninstall-script isn't copied into /Library/Tor/ on Mac OS Xpasted from IRC
[17:43] <killerchicken> because I've looked for a way to uninstall Vidalia + der Tor-package on OS X, and I've seen an uninstall script mentioned for the package without Vidalia on some wiki page. But I failed to find s...pasted from IRC
[17:43] <killerchicken> because I've looked for a way to uninstall Vidalia + der Tor-package on OS X, and I've seen an uninstall script mentioned for the package without Vidalia on some wiki page. But I failed to find something like that in the Vidalia-install bundle
[17:56] <killerchicken> phobos, also, when you list the files that will be installed from Installer, the uninstall-script does not show. It is in the diskimage, though.
[17:58] <killerchicken> The script is there, but it lives in /Library/Receipts/Tor.pkg/Contents/Resources/
[17:59] <phobos> hmm, let me poke that killerchicken
[18:00] <killerchicken> Should I write a flyspray bug entry to remind you? It's not top priority, I guess
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]https://gitlab.torproject.org/legacy/trac/-/issues/640Torbutton interferes with "Clear private data when firefox closes" setting2008-03-24T10:34:10ZTracTorbutton interferes with "Clear private data when firefox closes" settingI discovered that, once the Torbutton extension is installed and active, the "Clear private data when Firefox closes" privacy setting seems to be no longer effective. At least (non-tor) history and (non-tor) form data is not cleared on e...I discovered that, once the Torbutton extension is installed and active, the "Clear private data when Firefox closes" privacy setting seems to be no longer effective. At least (non-tor) history and (non-tor) form data is not cleared on exit. The explicit "clear private data" menu entry does not work anymore either.
This is with Torbutton 1.1.17-alpha on Firefox 2.0.0.12/Win32, with all other Firefox extensions disabled. Disabling the Torbutton extension restores the clear private data functionality.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: cybasheephttps://gitlab.torproject.org/legacy/trac/-/issues/641asking to exit from yourself launches many circuits2020-06-13T13:59:34ZRoger Dingledineasking to exit from yourself launches many circuitssebastian hahn reports that if you ask to exit via yourself, using the .exit
notation, it will launch dozens of circuits.
My guess is that it's noticing, each second, that it doesn't have any suitable
circuits for the .exit stream, so i...sebastian hahn reports that if you ask to exit via yourself, using the .exit
notation, it will launch dozens of circuits.
My guess is that it's noticing, each second, that it doesn't have any suitable
circuits for the .exit stream, so it launches a new one.
There's something wrong with recognizing that the in-progress circuits are
acceptable for the pending stream.
My guess is it has to do with not having our descriptor in the router list.
See connection_ap_can_use_exit() where we ask
if (router_get_by_nickname(conn->chosen_exit_name, 1) != exit)
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/642debug output: parameters reversed2020-06-13T13:59:34ZTracdebug output: parameters reversed--- tor-0.2.0.23-rc/src/common/tortls.c
+++ tor-0.2.0.23-rc/src/common/tortls.c
@@ -666,7 +666,7 @@
}
s = smartlist_join_strings(elts, ":", 0, NULL);
log_info(LD_NET, "Got a non-version-1 cipher list from %s. It is: '%s'"...--- tor-0.2.0.23-rc/src/common/tortls.c
+++ tor-0.2.0.23-rc/src/common/tortls.c
@@ -666,7 +666,7 @@
}
s = smartlist_join_strings(elts, ":", 0, NULL);
log_info(LD_NET, "Got a non-version-1 cipher list from %s. It is: '%s'",
- s, address);
+ address, s);
tor_free(s);
smartlist_free(elts);
}
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: bugmenothttps://gitlab.torproject.org/legacy/trac/-/issues/643tor shouldn't load the config file with --hash-password2020-06-13T13:59:34ZTractor 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/legacy/trac/-/issues/644Unchecking "Disable plugins during Tor usage" fails to restore plugins2008-04-10T07:58:34ZTracUnchecking "Disable plugins during Tor usage" fails to restore pluginsNOTE: This appears to affect 0.2.0.23-rc; please correct the version number if/when possible.
Since 0.2.0.23-rc, Torbutton will not allow plugins when browsing with Tor is enabled, even if the user has chosen to allow plugins by disabli...NOTE: This appears to affect 0.2.0.23-rc; please correct the version number if/when possible.
Since 0.2.0.23-rc, Torbutton will not allow plugins when browsing with Tor is enabled, even if the user has chosen to allow plugins by disabling the option to disable plugins.
To the best of my knowledge, this did not affect 0.2.0.22-rc.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: HANtwisterhttps://gitlab.torproject.org/legacy/trac/-/issues/645Torbutton Options Dialog "Blank" Fields when Browsing with Tor and Bittorrent...2018-03-10T14:38:12ZTracTorbutton Options Dialog "Blank" Fields when Browsing with Tor and Bittorrent pluginNOTE: This appears to affect 0.2.0.23-rc; please correct the version number if/when possible.
In 0.2.0.23-rc, if the user disables browsing with Tor and thereafter enables browsing with Tor, the fields in the Options Dialog for Torbutto...NOTE: This appears to affect 0.2.0.23-rc; please correct the version number if/when possible.
In 0.2.0.23-rc, if the user disables browsing with Tor and thereafter enables browsing with Tor, the fields in the Options Dialog for Torbutton will be blanked.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: HANtwisterhttps://gitlab.torproject.org/legacy/trac/-/issues/646miscellaneous stream event bugs for DNS requests2020-06-13T14:27:23ZRobert 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/legacy/trac/-/issues/647parent.document causes a security exception2008-03-30T09:41:43ZTracparent.document causes a security exceptionTry it at www.mediafire.com. First upload a file, then try to access (download) it. You should get a javascript alert box which is caused by a javascript code "parent.document.getElementById...".
This will only happen when kill_bad_js i...Try it at www.mediafire.com. First upload a file, then try to access (download) it. You should get a javascript alert box which is caused by a javascript code "parent.document.getElementById...".
This will only happen when kill_bad_js is on.
Torbutton 1.1.17.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Erixhttps://gitlab.torproject.org/legacy/trac/-/issues/648No available nodes after network outage2020-06-13T13:59:36ZTracNo 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/legacy/trac/-/issues/649When installing the Tor Bundle on OS X, Torbutton will not be installed into ...2020-06-13T13:59:36ZSebastian 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/legacy/trac/-/issues/650Using the .exit notation does not work with trunk (currently r14296)2020-06-13T13:59:37ZSebastian 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/legacy/trac/-/issues/651assert in refetching v2 rend desc2020-06-13T13:59:37ZRoger 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/legacy/trac/-/issues/652Tor doesn't detect when the world cannot reach it anymore2020-06-13T14:07:28ZSebastian 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/legacy/trac/-/issues/653geoip_remove_old_clients() never gets called?2020-06-13T13:59:39ZRoger 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/legacy/trac/-/issues/654Don't re-use entry point for testing circuits2020-06-13T14:57:10ZNick 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/legacy/trac/-/issues/655using all free CPU time in router_get_by_nickname2020-06-13T13:59:44ZTracusing 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
#2 0x00005555555de5e2 in add_nickname_list_to_smartlist ()
#3 0x00005555555e00ce in router_choose_random_node () from /proc/17463/exe
#4 0x000055555556aff7 in circuit_establish_circuit () from /proc/17463/exe
#5 0x0000555555572033 in circuit_get_open_circ_or_launch ()
#6 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
#7 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
#8 0x00005555555692e8 in circuit_send_next_onion_skin () from /proc/17463/exe
#9 0x00005555555c44b1 in connection_edge_process_relay_cell ()
#10 0x00005555555c5869 in circuit_receive_relay_cell () from /proc/17463/exe
#11 0x0000555555573e92 in command_process_cell () from /proc/17463/exe
#12 0x000055555558e16d in connection_or_process_cells_from_inbuf ()
#13 0x000055555558f4ec in connection_or_process_inbuf () from /proc/17463/exe
#14 0x000055555558567b in connection_handle_read () from /proc/17463/exe
#15 0x00005555555ba013 in conn_read_callback () from /proc/17463/exe
#16 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
#17 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
#18 0x00005555555b9e1d in tor_main () from /proc/17463/exe
#19 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
#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
#2 0x00005555555de5e2 in add_nickname_list_to_smartlist ()
#3 0x00005555555e00ce in router_choose_random_node () from /proc/17463/exe
#4 0x000055555556aff7 in circuit_establish_circuit () from /proc/17463/exe
#5 0x0000555555572033 in circuit_get_open_circ_or_launch ()
#6 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
#7 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
#8 0x000055555557332d in circuit_build_needed_circs () from /proc/17463/exe
#9 0x00005555555b9706 in second_elapsed_callback () from /proc/17463/exe
#10 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
#11 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
#12 0x00005555555b9e1d in tor_main () from /proc/17463/exe
#13 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
#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
#2 0x00005555555de5e2 in add_nickname_list_to_smartlist ()
#3 0x000055555556b340 in circuit_establish_circuit () from /proc/17463/exe
#4 0x0000555555572033 in circuit_get_open_circ_or_launch ()
#5 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
#6 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
#7 0x00005555555692e8 in circuit_send_next_onion_skin () from /proc/17463/exe
#8 0x00005555555c44b1 in connection_edge_process_relay_cell ()
#9 0x00005555555c5869 in circuit_receive_relay_cell () from /proc/17463/exe
#10 0x0000555555573e92 in command_process_cell () from /proc/17463/exe
#11 0x000055555558e16d in connection_or_process_cells_from_inbuf ()
#12 0x000055555558f4ec in connection_or_process_inbuf () from /proc/17463/exe
#13 0x000055555558567b in connection_handle_read () from /proc/17463/exe
#14 0x00005555555ba013 in conn_read_callback () from /proc/17463/exe
#15 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
#16 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
#17 0x00005555555b9e1d in tor_main () from /proc/17463/exe
#18 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
#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 ()
#2 0x00005555555de685 in add_nickname_list_to_smartlist ()
#3 0x000055555556b340 in circuit_establish_circuit () from /proc/17463/exe
#4 0x0000555555572033 in circuit_get_open_circ_or_launch ()
#5 0x0000555555572635 in connection_ap_handshake_attach_circuit ()
#6 0x000055555558ce99 in connection_ap_attach_pending () from /proc/17463/exe
#7 0x00005555555692e8 in circuit_send_next_onion_skin () from /proc/17463/exe
#8 0x00005555555c44b1 in connection_edge_process_relay_cell ()
#9 0x00005555555c5869 in circuit_receive_relay_cell () from /proc/17463/exe
#10 0x0000555555573e92 in command_process_cell () from /proc/17463/exe
#11 0x000055555558e16d in connection_or_process_cells_from_inbuf ()
#12 0x000055555558f4ec in connection_or_process_inbuf () from /proc/17463/exe
#13 0x000055555558567b in connection_handle_read () from /proc/17463/exe
#14 0x00005555555ba013 in conn_read_callback () from /proc/17463/exe
#15 0x00002b5b38841b8b in event_base_loop () from /usr/lib64/libevent-1.3e.so.1
#16 0x00005555555b9bbe in do_main_loop () from /proc/17463/exe
#17 0x00005555555b9e1d in tor_main () from /proc/17463/exe
#18 0x00002b5b398c536a in __libc_start_main () from /lib64/libc.so.6
#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/legacy/trac/-/issues/656Tor server crash in SSL_free with DH crypto error in logs2020-06-13T13:59:47ZMike 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
#2 0x4cfc6ab5 in SSL_free () from /lib/libssl.so.6
#3 0x080f335c in tor_tls_free (tls=0x40df1ac0) at tortls.c:831
#4 0x0806d2eb in _connection_free (conn=0x46229f00) at connection.c:328
#5 0x080a363c in connection_unlink (conn=0x46229f00) at main.c:212
#6 0x080a390e in close_closeable_connections () at main.c:603
#7 0x4cfe4125 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
#8 0x4cfe4349 in event_loop () from /usr/lib/libevent-1.1a.so.1
#9 0x080a5149 in do_main_loop () at main.c:1446
#10 0x080a52fb in tor_main (argc=3, argv=0x59c9d5c4) at main.c:1986
#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
#2 0x4cd6d884 in _IO_new_file_write () from /lib/libc.so.6
#3 0x4cd6d545 in new_do_write () from /lib/libc.so.6
#4 0x4cd6d82f in _IO_new_do_write () from /lib/libc.so.6
#5 0x4cd6e006 in _IO_new_file_sync () from /lib/libc.so.6
#6 0x4cd62c3c in fflush () from /lib/libc.so.6
#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
#8 0x080dad0e in _log (severity=4, domain=2,
format=0x8124004 "crypto error while %s: %s (in %s:%s)") at log.c:314
#9 0x080eb1a7 in crypto_log_errors (severity=4,
doing=0x8123cb0 "generating DH key") at crypto.c:146
#10 0x080ec104 in crypto_dh_generate_public (dh=0x34be56e0) at crypto.c:1467
#11 0x080ec31b in crypto_dh_get_public (scrubbed) at crypto.c:1492
#12 0x080a9e7e in onion_skin_server_handshake (scrubbed)
at onion.c:267
#13 0x08083a70 in cpuworker_main (data=0x4c2f2090) at cpuworker.c:284
#14 0x080e11ed in tor_pthread_helper_fn (_data=0x4c2f20a0) at compat.c:1482
#15 0x4ce5745b in start_thread () from /lib/libpthread.so.0
#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/legacy/trac/-/issues/657Restore old proxy settings when toggeling off2008-04-14T10:19:22ZTracRestore old proxy settings when toggeling offI usually have a proxy configuration that relies on a proxy configuration file (.pac).
However, Torbutton always resets the proxy settings to "no proxy" when toggled off, and I have to
manually go to the dialog and reset the original set...I usually have a proxy configuration that relies on a proxy configuration file (.pac).
However, Torbutton always resets the proxy settings to "no proxy" when toggled off, and I have to
manually go to the dialog and reset the original settings.
It would be nice if torbutton would "remember" the old proxy settings (probably including the values
manually filled into the "proxy" fields), and reset to those instead of "no proxy".
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: khonghttps://gitlab.torproject.org/legacy/trac/-/issues/658Tor breaks DNS on Linksys router.2020-06-13T13:59:48ZTracTor 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/legacy/trac/-/issues/659When configuring OR/Dir Ports, Tor always processes OR Port change first2020-06-13T13:59:48ZTracWhen 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/legacy/trac/-/issues/660swapped params in call to rep_hist_note_used_port2020-06-13T13:59:48ZTracswapped 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/legacy/trac/-/issues/661tor returns localized web pages2020-06-13T13:59:49ZTractor 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/legacy/trac/-/issues/662wrong size for allocation2020-06-13T13:59:49ZTracwrong 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/legacy/trac/-/issues/663netinfo clock skew warn too loud2020-06-13T13:59:49ZRoger 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/legacy/trac/-/issues/664Torbutton should not present custom certs if tor is enabled2020-06-16T01:27:27ZMike PerryTorbutton should not present custom certs if tor is enabledTorbutton should hide random client and server certs the user has if they check an option.
Ideally, we should provide 'certificate jars', but that may not be immediately possible with
the current XPCOM apis.
I'm guessing the option wi...Torbutton should hide random client and server certs the user has if they check an option.
Ideally, we should provide 'certificate jars', but that may not be immediately possible with
the current XPCOM apis.
I'm guessing the option will be optional and likely off by default, unless we can do the jar
thing.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/665Torbutton should provide a 'locked' mode2008-04-18T05:00:36ZMike PerryTorbutton should provide a 'locked' modeFor Torbrowser and other Tor-only setups, we should provide a locked mode where the user has
visual confirmation that Tor is enabled, but can't click it to change it.
[Automatically added by flyspray2trac: Operating System: All]For Torbrowser and other Tor-only setups, we should provide a locked mode where the user has
visual confirmation that Tor is enabled, but can't click it to change it.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/666clicking About -> Visit Home Page goes nowhere2008-04-18T13:02:13ZTracclicking About -> Visit Home Page goes nowhereclicking the "About, Visit Home Page" link fails both when Torbutton is enabled and disabled.
relevant IRC snippet:
arma> mikeperry: when i click "About Torbutton", and then click "Visit Home Page", nothing happens. i think.
mikeperry>...clicking the "About, Visit Home Page" link fails both when Torbutton is enabled and disabled.
relevant IRC snippet:
arma> mikeperry: when i click "About Torbutton", and then click "Visit Home Page", nothing happens. i think.
mikeperry> yeah, I noticed that..near as I could tell, that is some firefox bug unrelated to us, but I will keep an eye on it
it cuold be releated to the content policy and clicking links from non-browser.xul windows
arma> it can't be totally unrelated. we're the ones appearing to have the feature and having it not work.:)
mikeperry> true :)
keb> the same bug seems to occur when i try the About page in RefControl
mikeperry> do you also have torbutton installed in that profile?
mikeperry> it could be a torbutton content policy thing
arma> my torbutton was in 'disabled' mode
mikeperry> if torbutton can't find a state tag (or a browser window) for a load request, it blocks the request.
I thought I checked and that wasn't happening, but maybe I didn't look closely enough
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/legacy/trac/-/issues/667Error loading pages w/FF3b52008-04-20T05:50:53ZTracError loading pages w/FF3b5Exception in sandbox evaluation. Date hooks not applied:
[Exception... "Not enough arguments" nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame :: chrome://torbutton/content/torbutton.js :: anonymous :: line 172...Exception in sandbox evaluation. Date hooks not applied:
[Exception... "Not enough arguments" nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame :: chrome://torbutton/content/torbutton.js :: anonymous :: line 1722" data: no]
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: defconhttps://gitlab.torproject.org/legacy/trac/-/issues/668Disable updates during Tor vs "Tools, Addons, Find Updates"2008-04-20T07:17:56ZTracDisable updates during Tor vs "Tools, Addons, Find Updates"I have "Disable updates during Tor usage" checked,
and Torbutton is enabled.
The "Help, Check for Updates" menu item is greyed out.
However, when i click "Tools, Add-ons, Find Updates"
it goes and checks for updates to all the add-ons.
...I have "Disable updates during Tor usage" checked,
and Torbutton is enabled.
The "Help, Check for Updates" menu item is greyed out.
However, when i click "Tools, Add-ons, Find Updates"
it goes and checks for updates to all the add-ons.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/legacy/trac/-/issues/669Clients don't realize that a server has a different identity than stated in c...2020-06-13T13:59:50ZKarsten 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/legacy/trac/-/issues/670Tor Server unable to create a circuit2020-06-13T13:59:50ZTracTor 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/legacy/trac/-/issues/671tor 0.2.0.24-rc: mutex initialization problem?2020-06-13T13:59:51ZTractor 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
#2 0x0810f835 in tor_mutex_new () at compat.c:1756
#3 0x08108b84 in init_logging () at log.c:498
#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
#2 0x080e9f45 in tor_mutex_new () at compat.c:1756
#3 0x080e3294 in init_logging () at log.c:498
#4 0x080aae7c in tor_main (argc=1 argv=0xbfbfeaa4) at min.c:1968
#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/legacy/trac/-/issues/672[warn] Still had some address policies cached at shutdown.2020-06-13T15:07:47ZRoger 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/legacy/trac/-/issues/673'Spoof US English Browser' option cannot be turned off2008-04-24T21:29:05ZTrac'Spoof US English Browser' option cannot be turned offI have Torbutton 1.1.18alpha running on Firefox 3.0b5 and the 'Spoof US English Browser' cannot be turned off.
I have deselected it form the options, but still every time I toggle Tor or open the preferences panel of Torbutton all other ...I have Torbutton 1.1.18alpha running on Firefox 3.0b5 and the 'Spoof US English Browser' cannot be turned off.
I have deselected it form the options, but still every time I toggle Tor or open the preferences panel of Torbutton all other languages are removed leaving only 'en-US' and 'en'.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: deepdrafthttps://gitlab.torproject.org/legacy/trac/-/issues/674Functions not scrubbing IP addresses from log entries.2020-06-13T13:59:52ZTracFunctions not scrubbing IP addresses from log entries.A couple of functions aren't scrubbing IP addresses from log entries:
Apr 26 18:58:49.052 [Debug] circuit_handle_first_hop(): Looking for firsthop '194.109.206.212:443'
Apr 26 18:58:49.132 [Debug] connection_connect(): Connecting to [s...A couple of functions aren't scrubbing IP addresses from log entries:
Apr 26 18:58:49.052 [Debug] circuit_handle_first_hop(): Looking for firsthop '194.109.206.212:443'
Apr 26 18:58:49.132 [Debug] connection_connect(): Connecting to [scrubbed]:443.
[...]
Apr 26 18:58:54.345 [Debug] connection_or_finished_connecting(): OR connect() to router at 194.109.206.212:443 finished.
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: jasemandudehttps://gitlab.torproject.org/legacy/trac/-/issues/675update_consensus_networkstatus_downloads() & router_pick_directory_server() r...2020-06-13T14:06:09ZTracupdate_consensus_networkstatus_downloads() & router_pick_directory_server() rarely calledPossible solution to #648
Machine was left on for several hours with TOR running but no dial up network, then dial up network was brought
back up. TOR spends half an hour in a loop where it can't find nodes. Throughout this time, using ...Possible solution to #648
Machine was left on for several hours with TOR running but no dial up network, then dial up network was brought
back up. TOR spends half an hour in a loop where it can't find nodes. Throughout this time, using TORbutton to
switch off proxies in Firefox allowed me to browse the web with no problems, so I know the network is working fine.
After waiting 30 minutes, killing and relaunching TOR seemed to fix the problem, though from the logs below it looks
like TOR had finally made some circuits just before I killed it.
Taking a closer look at the logs, I can see it wasn't able to make circuits for a whole 30 minutes until it called
update_consensus_networkstatus_downloads() and router_pick_directory_server() - then all of a sudden everything
started to work.
Are these functions rarely called because of bandwidth issues? Could some logic be added so that if we get
"[Warning] No available nodes when trying to choose node. Failing." then these functions get called?
Here are the log messages:
Apr 26 18:28:46.820 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:28:46.822 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:28:46.824 [Info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another exit circ.
Apr 26 18:28:46.825 [Info] choose_good_exit_server_general(): Found 74 servers that might support 11/12 pending connections.
Apr 26 18:28:46.828 [Info] choose_good_exit_server_general(): Chose exit server 'oemloi'
Apr 26 18:28:46.830 [Info] router_choose_random_node(): We couldn't find any live, guard routers; falling back to list of all routers.
Apr 26 18:28:46.832 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.834 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.837 [Info] router_choose_random_node(): We couldn't find any live, guard routers; falling back to list of all routers.
Apr 26 18:28:46.839 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.842 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.844 [Info] router_choose_random_node(): We couldn't find any live, guard routers; falling back to list of all routers.
Apr 26 18:28:46.847 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.850 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:28:46.853 [Warning] Failed to find node for hop 0 of our path. Discarding this circuit.
Apr 26 18:28:46.856 [Info] onion_populate_cpath(): Generating cpath hop failed.
Apr 26 18:28:47.860 [Info] choose_good_exit_server_general(): Found 74 servers that might support 11/12 pending connections.
Apr 26 18:28:47.864 [Info] choose_good_exit_server_general(): Chose exit server 'gashmish'
Apr 26 18:28:47.899 [Info] router_choose_random_node(): We couldn't find any live, guard routers; falling back to list of all routers.
Apr 26 18:28:47.903 [Warning] No available nodes when trying to choose node. Failing.
[... and so on for 30 minutes, still no nodes ...]
Apr 26 18:58:16.130 [Warning] No available nodes when trying to choose node. Failing.
Apr 26 18:58:16.177 [Warning] Failed to find node for hop 0 of our path. Discarding this circuit.
Apr 26 18:58:16.219 [Info] onion_populate_cpath(): Generating cpath hop failed.
Apr 26 18:58:16.266 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
[... but suddenly ...]
Apr 26 18:58:43.588 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:58:43.994 [Info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another exit circ.Apr 26 18:58:44.258 [Info] update_consensus_router_descriptor_downloads(): 0 router descriptors downloadable. 0 delayed; 1782 present (0 of those were in old_routers); 0 would_reject; 391 wouldnt_use; 0 in progress.
Apr 26 18:58:44.329 [Info] routerlist_remove_old_routers(): We have 2211 live routers and 0 old router descriptors. At most 2173 must be retained because of networkstatuses.
Apr 26 18:58:44.398 [Info] update_consensus_networkstatus_downloads(): Launching networkstatus consensus download.
Apr 26 18:58:44.467 [Info] router_pick_directory_server(): No reachable router entries for dirservers. Trying them all again.
Apr 26 18:58:44.567 [Debug] directory_initiate_command(): anonymized 0, use_begindir 1.
Apr 26 18:58:44.640 [Debug] directory_initiate_command(): Initiating consensus network-status fetch
Apr 26 18:58:44.709 [Info] connection_ap_make_link(): Making internal anonymized tunnel to [scrubbed]:443 ...
Apr 26 18:58:44.778 [Debug] connection_add(): new conn type Socks, socket -1, n_conns 11.
Apr 26 18:58:44.847 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:58:44.916 [Info] connection_ap_make_link(): ... application connection created and linked.
Apr 26 18:58:44.985 [Debug] connection_add(): new conn type Directory, socket -1, n_conns 12.
Apr 26 18:58:45.054 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:58:45.124 [Info] circuit_get_open_circ_or_launch(): No safe circuit (purpose 5) ready for edge connection; delaying.
Apr 26 18:58:45.893 [Info] circuit_predict_and_launch_new(): Have 0 clean circs (0 internal), need another exit circ.
Apr 26 18:58:45.964 [Debug] new_route_len(): Chosen route length 3 (2211 routers available).
Apr 26 18:58:46.034 [Info] choose_good_exit_server_general(): Found 119 servers that might support 6/7 pending connections.
Apr 26 18:58:46.105 [Debug] smartlist_choose_by_bandwidth(): Total weighted bw = 17053612, exit bw = 23966189, nonexit bw = 1614269, exit
weight = 1.000000 (for exit == 1), guard bw = 19886442, nonguard bw = 5694016, guard weight = 0.571224 (for guard == 0)Apr 26 18:58:46.176 [Info] choose_good_exit_server_general(): Chose exit server 'dotplex1'
Apr 26 18:58:46.247 [Debug] onion_extend_cpath(): Path is 0 long; we want 3
Apr 26 18:58:46.320 [Info] router_choose_random_node(): We couldn't find any live, guard routers; falling back to list of all routers.Apr 26 18:58:46.391 [Info] add_an_entry_guard(): Chose 'dannenberg' as new entry guard.
Apr 26 18:58:46.462 [Info] log_entry_guards(): BrainwashEducation (up made-contact),GuyMontag (up made-contact) [...]
Apr 26 18:58:46.540 [Debug] onion_extend_cpath(): Chose router dannenberg for hop 1 (exit is dotplex1)
Apr 26 18:58:46.621 [Debug] onion_extend_cpath(): Path is 1 long; we want 3
Apr 26 18:58:46.698 [Debug] choose_good_middle_server(): Contemplating intermediate hop: random choice.
Apr 26 18:58:46.774 [Debug] smartlist_choose_by_bandwidth(): Total weighted bw = 70934573, exit bw = 23971981, nonexit bw = 107505582, ex
it weight = 0.000000 (for exit == 0), guard bw = 114082699, nonguard bw = 17394864, guard weight = 0.615841 (for guard == 0)
Apr 26 18:58:46.851 [Debug] onion_extend_cpath(): Chose router RentalSponge for hop 2 (exit is dotplex1)
Apr 26 18:58:46.928 [Debug] onion_extend_cpath(): Path is 2 long; we want 3
Apr 26 18:58:47.006 [Debug] onion_extend_cpath(): Chose router dotplex1 for hop 3 (exit is dotplex1)
Apr 26 18:58:47.084 [Debug] onion_extend_cpath(): Path is complete: 3 steps long
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: jasemandudeTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/676tor-0.1.2.19: fails to start after log rotation2008-04-28T17:34:15ZTractor-0.1.2.19: fails to start after log rotationAfter tor log file has been rotated by logrotate utility, tor fails to start.
Steps to Reproduce:
1. Start tor daemon
2. Wait until log file fill ups and log rotation happens
3. See that tor isn't functioning anymore
It happens because...After tor log file has been rotated by logrotate utility, tor fails to start.
Steps to Reproduce:
1. Start tor daemon
2. Wait until log file fill ups and log rotation happens
3. See that tor isn't functioning anymore
It happens because logrotate sets default ownership on newly created /var/log/tor.log - root:wheel. tor daemon
runs under tor:tor credentials, so it can't open its own log file and fails to start.
Solution: add "create 0640 tor tor" to contrib/tor.logrotate.in.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: gentoosiasthttps://gitlab.torproject.org/legacy/trac/-/issues/677block file:// access in TOR only2008-04-28T20:50:47ZTracblock file:// access in TOR onlyWould it be possible to modify the security feature so there was an option to
'block acces to network from file:// urls' when in Tor only, instead of the
default which blocks it wither tor is toggled or not
[Automatically added by fl...Would it be possible to modify the security feature so there was an option to
'block acces to network from file:// urls' when in Tor only, instead of the
default which blocks it wither tor is toggled or not
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: torberthttps://gitlab.torproject.org/legacy/trac/-/issues/678man page entries for RejectPlaintextPorts and WarnPlaintextPorts2020-06-13T13:59:54ZRoger 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/legacy/trac/-/issues/679suppress non-SSL warning for sending to .onion sites2015-07-14T06:33:32ZTracsuppress non-SSL warning for sending to .onion sitesIt is better that the hidden web servers do not use SSL.
(https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#HttpsHiddenService)
However, Firefox warns users when sending information to an unencrypted site (if the option is on)
a...It is better that the hidden web servers do not use SSL.
(https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#HttpsHiddenService)
However, Firefox warns users when sending information to an unencrypted site (if the option is on)
and warns when switching from encrypted to unencrypted.
Since connections to hidden services are always encrypted by the Tor network,
but Firefox does not know about this, perhaps Torbutton could suppress the warnings.
This would prevent a decrease in user confidence regarding use of hidden services.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/legacy/trac/-/issues/680tor won't run - can't find config file2008-05-04T07:45:46ZTractor won't run - can't find config fileEven though no config file was ever specified, somehow, and even after installing and re-installing, there is a path with no file name for where the config file is located.
With the path removed, tor will start. With the default strin...Even though no config file was ever specified, somehow, and even after installing and re-installing, there is a path with no file name for where the config file is located.
With the path removed, tor will start. With the default string, containing the path to the install directory, tor will not start.
Also - intial installation will get abort, retry message if vidalia is running - it won't shut down the previously running app to install the upgrade.
On win2k.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: zbonskiAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/681encrypted dir conns confuse LeaveStreamsUnattached2020-06-13T13:59:55ZRoger 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 #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 Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/682very slow in web browsing and cannot upload pictures to my web site2020-06-13T13:59:55ZTracvery slow in web browsing and cannot upload pictures to my web siteSince I downloaded mozilla firefox for this Tor, my web browsing is extremely slow and I cannot upload pictures to my web site that I sell on. Am I doing something wrong? I do want to stay anonymous and not have anyone knowing my ip addr...Since I downloaded mozilla firefox for this Tor, my web browsing is extremely slow and I cannot upload pictures to my web site that I sell on. Am I doing something wrong? I do want to stay anonymous and not have anyone knowing my ip address. I am tired of the spys out there. Please Help- Thank you
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: rockpapermarshttps://gitlab.torproject.org/legacy/trac/-/issues/683Disable non .onion access when browsing .onions2020-06-15T23:12:59ZTracDisable non .onion access when browsing .onionsWould it be a possibility to get a new security feature added that prevents .onion websites loading content from
non .onion sites. This would prevent hotlinked images etc from the regular internet being loaded.
Where possible this woul...Would it be a possibility to get a new security feature added that prevents .onion websites loading content from
non .onion sites. This would prevent hotlinked images etc from the regular internet being loaded.
Where possible this would only prevent the loading on hotlinked files. Browsing directly to a non hidden service
site should work as normal whether .onion sites are open in another tab or not.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: torberthttps://gitlab.torproject.org/legacy/trac/-/issues/684Recover from Config Parse Errors on HUP2020-06-13T13:59:56ZTracRecover from Config Parse Errors on HUPCurrently, if there's an error in the config, sending HUP to tor will cause it to exit. It should, instead, revert back to its previous configuration.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
*...Currently, if there's an error in the config, sending HUP to tor will cause it to exit. It should, instead, revert back to its previous configuration.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: BarkerJrhttps://gitlab.torproject.org/legacy/trac/-/issues/685Vidalia crashes every time it startet Tor 0.2.0.26rc2020-06-13T13:59:56ZTracVidalia crashes every time it startet Tor 0.2.0.26rcThe new version abort within the first minute of the starting process. I use the new vidalia bundle with the version 1.2
(the version 1.1 also chrashes when I start Tor).
[Automatically added by flyspray2trac: Operating System: Window...The new version abort within the first minute of the starting process. I use the new vidalia bundle with the version 1.2
(the version 1.1 also chrashes when I start Tor).
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Tokrahttps://gitlab.torproject.org/legacy/trac/-/issues/686How do I uninstall/remove the Tor enabled/disabled button?2008-05-18T04:14:05ZTracHow do I uninstall/remove the Tor enabled/disabled button?Hi,
I would like to know how I can permanently remove/uninstall the 'Tor 1.0.4.01 enabled/disabled' button located at
the lower right corner of the Mozilla Firefox search page.
Thank you.
winxp
[Automatically added by flyspray2trac...Hi,
I would like to know how I can permanently remove/uninstall the 'Tor 1.0.4.01 enabled/disabled' button located at
the lower right corner of the Mozilla Firefox search page.
Thank you.
winxp
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: winxphttps://gitlab.torproject.org/legacy/trac/-/issues/687Application Crash When BitTorrent Client Launched2020-06-13T13:59:56ZTracApplication Crash When BitTorrent Client LaunchedPlease Note: This is in regards to 0.2.0.26-rc.
Immediately after launching a BitTorrent Client configured to forward tracker information (ONLY!) through Tor
(file transfer connections were not forwarded through Tor; only tracker inform...Please Note: This is in regards to 0.2.0.26-rc.
Immediately after launching a BitTorrent Client configured to forward tracker information (ONLY!) through Tor
(file transfer connections were not forwarded through Tor; only tracker information), Tor crashed as follows:
szAppName: tor.exe
szModName: tor.exe
offset: 000be2c1
Tor was configured to run as a Service, and was running as a relay. The computer was Windows XP Home Edition.
I'll attempt to attach the crash dump. Note that this isn't always reproducible.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: HANtwisterAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/688Change on Band inside torrc aren't published on reload2020-06-13T13:59:57ZTracChange on Band inside torrc aren't published on reloadin 0.2.0.26rc
Process
modify one of this line:
RelayBandwidthRate 1000 KBytes # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 2000 KBytes # But allow bursts up to 200KB/s (1600Kbps)
MaxAdvertisedBandwidth 50 KBytes
Then d...in 0.2.0.26rc
Process
modify one of this line:
RelayBandwidthRate 1000 KBytes # Throttle traffic to 100KB/s (800Kbps)
RelayBandwidthBurst 2000 KBytes # But allow bursts up to 200KB/s (1600Kbps)
MaxAdvertisedBandwidth 50 KBytes
Then do a reload of tor /etc/init.d/tor reload
Change above aren't published in the directories.
Tor restart seems to be needed for publishing changes.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amisRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/689Add Bogon network to the default reject policy2020-06-13T13:59:57ZTracAdd Bogon network to the default reject policyIP from the bogon list could be found in the current directory:
1.1.1.1 1.1.1.2 39.x.x.X
Add the bogon network list in the default reject policy could be good.
If i don't think there is, an accept policy most of these IP could be added...IP from the bogon list could be found in the current directory:
1.1.1.1 1.1.1.2 39.x.x.X
Add the bogon network list in the default reject policy could be good.
If i don't think there is, an accept policy most of these IP could be added.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amishttps://gitlab.torproject.org/legacy/trac/-/issues/690Increase the security by adding Relays from the same provider to the same family2020-06-13T13:59:57ZTracIncrease the security by adding Relays from the same provider to the same familyHi
Many routers runned on the same provider could break security used in the same circuit.
Even if the is the /16 auto exclude and the Family declaration, it's seems there isn't any control of the provider traffic analysis.
We could se...Hi
Many routers runned on the same provider could break security used in the same circuit.
Even if the is the /16 auto exclude and the Family declaration, it's seems there isn't any control of the provider traffic analysis.
We could see in the directory many routers from the same provider with asn't the same /16 network.
It should be great to give directories to auto add families to OR from the same provider based on the RIPE registry AS number of the smallest IP range.
Perhaps should be better operated only by authorities directories.
Examples of multiples /16 from the word:
virtual.com.br 189.5 189.61 189.33 ...
brasiltelecom.net.br 200.180 201.3 201.24
hispeed.ch 84.75. 87.73. 85.2.
proxad.net
wanadoo.fr
chello.pl
t-dialin.net ...
Regards
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amishttps://gitlab.torproject.org/legacy/trac/-/issues/691Tor relay fails on startup if network not up yet2020-06-13T13:59:58ZTracTor relay fails on startup if network not up yetThis applies to 0.2.0.26.
On Windows XP Home Edition, if the Tor Service is started while no network adapters are physically connected,
Tor will immediately crash.
szAppName: tor.exe
szModName: unknown
offset: 0022e7d0
Crash Dump Atta...This applies to 0.2.0.26.
On Windows XP Home Edition, if the Tor Service is started while no network adapters are physically connected,
Tor will immediately crash.
szAppName: tor.exe
szModName: unknown
offset: 0022e7d0
Crash Dump Attached.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: HANtwister0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/692Our tarballs keep failing unit tests2008-06-04T03:30:18ZRoger DingledineOur tarballs keep failing unit testsWe should change it so 'make dist' requires 'make check' to pass.
That way we won't keep putting out new tarballs that are busted.
[Automatically added by flyspray2trac: Operating System: All]We should change it so 'make dist' requires 'make check' to pass.
That way we won't keep putting out new tarballs that are busted.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.0.xhttps://gitlab.torproject.org/legacy/trac/-/issues/693Corrections needed in French translations2008-06-04T07:34:41ZTracCorrections needed in French translationsIn version 1.2.0 rc1, some French translations are bad or missing:
1) (this one is most important because meaning is wrong)
When Tor shows as text in the status bar:
wee see: Tor activer / Tor désactiver
should be: Tor activé / Tor désa...In version 1.2.0 rc1, some French translations are bad or missing:
1) (this one is most important because meaning is wrong)
When Tor shows as text in the status bar:
wee see: Tor activer / Tor désactiver
should be: Tor activé / Tor désactivé
2)
In the Preferences screen:
wee see everywhere: (recommendé)
should be: (recommandé)
3)
In the Preferences screen, the lower left button is not translated
we see: Restore defaults
should be: `Restaurer les paramètres par défaut' or `Restaurer par défaut'
4)
In the About Torbutton screen
wee see: Créée par :
should be: Créé par :
If you like, I can check the full translation file and make the needed French corrections?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: cavahttps://gitlab.torproject.org/legacy/trac/-/issues/694Firefox extension (with embedded TOR-client)2020-06-13T13:59:59ZTracFirefox extension (with embedded TOR-client)Sometimes you're not able to install any additional software on a machine.
But to be able to use TOR anyway, it would be nice if you also could offer a browser extension,
where the client is already included as an embedded part of the ex...Sometimes you're not able to install any additional software on a machine.
But to be able to use TOR anyway, it would be nice if you also could offer a browser extension,
where the client is already included as an embedded part of the extension (without, that the TOR client has to run in the background or has to be installed separately).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Malcolmhttps://gitlab.torproject.org/legacy/trac/-/issues/695Tor crashing with a bus error2020-06-13T13:59:59ZTracTor crashing with a bus errorTOR, compiled on Debian Etch/Sparc with standard parameters consitently crashes with a Bus Error after setting up circuits.
Before the crash, lots of messages like
Jun 08 07:29:47.798 [debug] conn_read_callback(): socket 19 wants to r...TOR, compiled on Debian Etch/Sparc with standard parameters consitently crashes with a Bus Error after setting up circuits.
Before the crash, lots of messages like
Jun 08 07:29:47.798 [debug] conn_read_callback(): socket 19 wants to read.
Jun 08 07:29:47.798 [debug] read_to_buf_impl(): Read 996 bytes. 36354 on inbuf.
Jun 08 07:29:47.798 [debug] connection_dir_process_inbuf(): Got data, not eof. Leaving on inbuf.
are appearing.
The last message is always
Jun 08 07:29:47.799 [debug] conn_read_callback(): socket 13 wants to read.
Jun 08 07:29:47.799 [debug] read_to_buf_impl(): Read 229 bytes. 229 on inbuf.
suggesting perhaps a buffer underrun.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: ricoxxhttps://gitlab.torproject.org/legacy/trac/-/issues/696WFU not computed right for never-down relay2020-06-13T13:59:59ZRoger DingledineWFU not computed right for never-down relaycorfu has been up since it generated its key -- it has never been down.
Its entry in moria1's router-stability file is
R 7CAA2F5F998053EF5D2E622563DEB4A6175E49AC
+MTBF 0 0.00000 S=2008-05-15 23:26:01
+WFU 0 0
But in the cached-consens...corfu has been up since it generated its key -- it has never been down.
Its entry in moria1's router-stability file is
R 7CAA2F5F998053EF5D2E622563DEB4A6175E49AC
+MTBF 0 0.00000 S=2008-05-15 23:26:01
+WFU 0 0
But in the cached-consensus, we have
r corfu fKovX5mAU+9dLmIlY960phdeSaw fuzu6FZU2vwuiT47PLMblVITIAI 2008-06-09 06:19:48 140.247.60.83 443 80
s Fast Guard Running V2Dir Valid
It has no stable flag. Because its WFU is 0. Even though its only uptime
run is currently at about 26 days.
moria1 has been up since May 19.
So are we forgetting to update our WFU entries for relays that don't have
an up or down event? I wonder how much this is skewing our 'stable'
calculations.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/legacy/trac/-/issues/697Wrong DNS configuration could break navigation2020-06-13T14:00:00ZTracWrong DNS configuration could break navigationOn 0.2.0.26rc (add new version on reported version please),
Hello,
i've received one email who alert me.
One user have received OpenDNS pages when he is using tor.
OpenDNS is a company who resolve DNS for the others giving them filt...On 0.2.0.26rc (add new version on reported version please),
Hello,
i've received one email who alert me.
One user have received OpenDNS pages when he is using tor.
OpenDNS is a company who resolve DNS for the others giving them filtering, security, ads, but no privacy.
It appears that some nodes resolving DNS seems to have wrong DNS configured, blocking navigation.
If one router making dns resolution is misconfigured it could break navigation of others.
I think a DNS control need probably to be added making theses routers down.
Perhaps using a downloadable list for phishing.
---------- Forwarded message ----------
From: d
Date: 2008/6/10 04:22
Subject: Tor exit node policy
Hello,
I was browsing a phishing site using Tor recently and instead of the phish I saw an OpenDNS warning page (and apparently no way to bypass it). Yours was one of the exit nodes that was part of my Tor connection at the time.
I wasn't able to identify exactly which exit node it was.
Do you have Phish Filtering set up on your exit node, and if so is this a deliberate policy? I work in antiphishing and use Tor for some phish sites.
Thank you,
d
----------------------
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amisTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/698Uncaught exception on blocking local file network access2008-06-11T09:23:55ZTracUncaught exception on blocking local file network accessOSX 10.3.9
FF 2.0.0.14
Torbutton 1.2.0 rc2
When 'Block access to network from file:// urls' is enabled, an attempt to access the network from a local file
causes an uncaught exception error:
Error: uncaught exception: [Exception... "Comp...OSX 10.3.9
FF 2.0.0.14
Torbutton 1.2.0 rc2
When 'Block access to network from file:// urls' is enabled, an attempt to access the network from a local file
causes an uncaught exception error:
Error: uncaught exception: [Exception... "Component returned failure code: 0x805e000a [nsIDOMHTMLFormElement.submit]" nsresult: "0x805e000a (<unknown>)" location: "JS frame :: file:///xxxx/xxxx/xxx :: doSend :: line 165" data: no]
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: downiehttps://gitlab.torproject.org/legacy/trac/-/issues/699First page loaded under Tor, links dont work2008-06-11T09:27:17ZTracFirst page loaded under Tor, links dont workAs of torbutton 1.1.12RC2 The first page to be loaded, after Tor is toggled on, results none of the links in that page working.
This happens for Windows (XP) and OS X (10.4). With firefox 2.0.0.14
[Automatically added by flyspray2tra...As of torbutton 1.1.12RC2 The first page to be loaded, after Tor is toggled on, results none of the links in that page working.
This happens for Windows (XP) and OS X (10.4). With firefox 2.0.0.14
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: torberthttps://gitlab.torproject.org/legacy/trac/-/issues/700Installation error - maybe connected to OSX 10.5.3?2020-06-13T14:00:00ZTracInstallation error - maybe connected to OSX 10.5.3?Im getting an installation error of a postflight script not running for both
vidalia-bundle-0.1.2.19-0.0.16a-tiger.dmg
vidalia-bundle-0.2.0.27-rc-0.1.3-tiger.dmg
I have searched through the various help pages, and the one and only time...Im getting an installation error of a postflight script not running for both
vidalia-bundle-0.1.2.19-0.0.16a-tiger.dmg
vidalia-bundle-0.2.0.27-rc-0.1.3-tiger.dmg
I have searched through the various help pages, and the one and only time I can find this error referred to is in the Vidalia
forum. The problem with the answer I found here is that is that it refers to an installer log and I cant find that on my machine...
I have recently upgraded to OSX 10.5.3 as well and assume this might well be an issue as its very recent.
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: cheweyAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/701Phish filtering is forced on by turning off Tor2008-06-12T03:10:33ZTracPhish filtering is forced on by turning off TorOSX 10.3.9
FF 2.0.0.14
Torbutton 1.2.0 rc2
When turning off Tor, FF/Preferences/Security/Warn me if the site I'm visiting is a suspected forgery
gets forced on. I don't see a reference to it in Torbutton Preferences.
At least toggling T...OSX 10.3.9
FF 2.0.0.14
Torbutton 1.2.0 rc2
When turning off Tor, FF/Preferences/Security/Warn me if the site I'm visiting is a suspected forgery
gets forced on. I don't see a reference to it in Torbutton Preferences.
At least toggling Tor forces the filter to use a downloaded blacklist rather than submitting URLs to Google,
but I don't see a need to force phish filtering on (and it's undesirable for me).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: downie