Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:56:35Zhttps://gitlab.torproject.org/legacy/trac/-/issues/326New eventdns error messages w/svn 82892020-06-13T13:56:35ZTracNew eventdns error messages w/svn 8289I just started getting the following error messages with the latest svn builds ~8287-8289(current):
Aug 29 02:20:50.964 [warn] eventdns: Nameserver 127.0.0.1 has failed: request timed out.
Aug 29 02:20:50.964 [warn] eventdns: All namese...I just started getting the following error messages with the latest svn builds ~8287-8289(current):
Aug 29 02:20:50.964 [warn] eventdns: Nameserver 127.0.0.1 has failed: request timed out.
Aug 29 02:20:50.964 [warn] eventdns: All nameservers have failed
Aug 29 02:20:52.381 [warn] eventdns: Nameserver 127.0.0.1 is back up
Aug 29 04:53:41.131 [warn] eventdns: Nameserver 127.0.0.1 has failed: Bad response 2
Aug 29 04:53:41.132 [warn] eventdns: All nameservers have failed
Aug 29 04:53:41.140 [warn] eventdns: Nameserver 127.0.0.1 is back up
Aug 29 04:53:43.140 [warn] eventdns: Nameserver 127.0.0.1 has failed: Bad response 2
Aug 29 04:53:43.140 [warn] eventdns: All nameservers have failed
Aug 29 04:53:43.172 [warn] eventdns: Nameserver 127.0.0.1 is back up
Aug 29 04:53:51.581 [warn] eventdns: Nameserver 127.0.0.1 has failed: request timed out.
Aug 29 04:53:51.581 [warn] eventdns: All nameservers have failed
Aug 29 04:53:51.886 [warn] eventdns: Nameserver 127.0.0.1 is back up
Aug 29 04:53:54.591 [warn] eventdns: Nameserver 127.0.0.1 has failed: request timed out.
Aug 29 04:53:54.591 [warn] eventdns: All nameservers have failed
Aug 29 04:53:55.110 [warn] eventdns: Nameserver 127.0.0.1 is back up
Aug 29 04:53:57.601 [warn] eventdns: Nameserver 127.0.0.1 has failed: request timed out.
Aug 29 04:53:57.602 [warn] eventdns: All nameservers have failed
Aug 29 04:53:57.886 [warn] eventdns: Nameserver 127.0.0.1 is back up
Aug 29 06:21:49.752 [warn] eventdns: Nameserver 127.0.0.1 has failed: request timed out.
Aug 29 06:21:49.752 [warn] eventdns: All nameservers have failed
Aug 29 06:21:56.882 [warn] eventdns: Nameserver 127.0.0.1 is back up
Aug 29 07:33:48.065 [warn] eventdns: Nameserver 127.0.0.1 has failed: Bad response 2
Aug 29 07:33:48.066 [warn] eventdns: All nameservers have failed
Aug 29 07:33:49.163 [warn] eventdns: Nameserver 127.0.0.1 is back up
Aug 29 07:33:51.873 [warn] eventdns: Nameserver 127.0.0.1 has failed: Bad response 2
Aug 29 07:33:51.874 [warn] eventdns: All nameservers have failed
Aug 29 07:33:52.445 [warn] eventdns: Nameserver 127.0.0.1 is back up
Aug 29 07:33:53.723 [warn] eventdns: Nameserver 127.0.0.1 has failed: Bad response 2
Aug 29 07:33:53.723 [warn] eventdns: All nameservers have failed
Aug 29 07:33:53.827 [warn] eventdns: Nameserver 127.0.0.1 is back up
Is this expected?
I'm on NetBSD 3_Stable
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: yancm0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/325[Ubuntu]: Old Tor Package2020-06-13T13:56:34ZTrac[Ubuntu]: Old Tor PackageWhat to do?
weasel is mentioned as package maintainer for the dapper and edgy Tor package.
Is this correct?
The current Tor Ubuntu package is very old. (dapper/stable -> 0.1.0.15, edgy -> 0.1.1.22)
[Automatically added by flyspray2t...What to do?
weasel is mentioned as package maintainer for the dapper and edgy Tor package.
Is this correct?
The current Tor Ubuntu package is very old. (dapper/stable -> 0.1.0.15, edgy -> 0.1.1.22)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: thalunilhttps://gitlab.torproject.org/legacy/trac/-/issues/324Subversion 8275 builds die on start-up2020-06-13T13:56:34ZTracSubversion 8275 builds die on start-upLog message:
Aug 28 16:16:45.421 [notice] Tor 0.1.2.1-alpha-dev opening log file.
Aug 28 16:16:45.521 [err] util.c:162: _tor_strdup: Assertion s failed; aborting.
gdb/bt yields:
(gdb) bt
#0 0xbda160fb in kill () from /usr/lib/libc.so.1...Log message:
Aug 28 16:16:45.421 [notice] Tor 0.1.2.1-alpha-dev opening log file.
Aug 28 16:16:45.521 [err] util.c:162: _tor_strdup: Assertion s failed; aborting.
gdb/bt yields:
(gdb) bt
#0 0xbda160fb in kill () from /usr/lib/libc.so.12
#1 0xbda971a5 in abort () from /usr/lib/libc.so.12
#2 0x08099e7b in _tor_strdup (s=0x0) at util.c:170
#3 0x0807ab3a in configure_nameservers (force=1) at dns.c:1285
#4 0x08078c76 in dns_init () at dns.c:184
#5 0x0807e837 in do_main_loop () at main.c:1113
#6 0x0807f4dd in tor_main (argc=7, argv=0xbfbfed78) at main.c:2163
#7 0x08099307 in main (argc=7, argv=0xbfbfed78) at tor_main.c:22
#8 0x0804c266 in ___start ()
(
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancmhttps://gitlab.torproject.org/legacy/trac/-/issues/323Vidalia causes some InstallShield installers to hang2020-06-13T13:56:33ZTracVidalia causes some InstallShield installers to hangUsing Tor/Privoxy/Vidalia bundle 0.1.1.23 on Windows 2000 SP4 w/ Update Rollup 1.
The process "vidalia.exe" causes some InstallShield installer programs to hang, until the Vidalia process is terminated or Windows is shut down (Thus term...Using Tor/Privoxy/Vidalia bundle 0.1.1.23 on Windows 2000 SP4 w/ Update Rollup 1.
The process "vidalia.exe" causes some InstallShield installer programs to hang, until the Vidalia process is terminated or Windows is shut down (Thus terminating the process). A few programs that are affected include:
SwissKnife Partitioning Tool: http://www.compuapps.com/download/Swissknife/swissknife.htm
MicroSolutions BACKPACK Device Drivers: ftp://ftp.micro-solutions.com/software/backpack/pnp_driver/pnp407d.exe
I've encountered a few others, but I can't recall them at the moment. If more info is needed, please let me know, and I'll try to dig up some more.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Covitihttps://gitlab.torproject.org/legacy/trac/-/issues/322Cannot open Vidalia through Tor2020-06-13T13:56:33ZTracCannot open Vidalia through TorEach time I open Vidalia I have this error message: connection_create_listener(): Could not bind to 127.0.0.1:9050: Address already in use.
Is Tor already running?
I check in the task manager but no Tor.exe is running. I don't understan...Each time I open Vidalia I have this error message: connection_create_listener(): Could not bind to 127.0.0.1:9050: Address already in use.
Is Tor already running?
I check in the task manager but no Tor.exe is running. I don't understand. I restarted my PC many times but no change.
I have Windows XP pro SP2 with latest updates and Tor version 0.1.1.23 (latest)
Could you please help?
Thank you
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: silveradohttps://gitlab.torproject.org/legacy/trac/-/issues/321TOR resolver appends localdomain to DNS requests2020-06-13T13:56:33ZTracTOR resolver appends localdomain to DNS requestsFor some time now I see lots of AAAA requests in the query log of my domain's authoritative nameserver
looping back from my upstream resolvers. Here are some examples:
query: piichandiary.blog71.fc2.com.<mydomain> IN AAAA -E
query: fwin...For some time now I see lots of AAAA requests in the query log of my domain's authoritative nameserver
looping back from my upstream resolvers. Here are some examples:
query: piichandiary.blog71.fc2.com.<mydomain> IN AAAA -E
query: fwing.blog6.fc2.com.<mydomain> IN AAAA -E
query: nekosen.blog61.fc2.com.<mydomain> IN AAAA -E
query: tsuboriba.blog71.fc2.com.<mydomain> IN AAAA -E
query: 405405.blog65.fc2.com.<mydomain> IN AAAA -E
query: ocucoop2006-mon-e.seesaa.net.<mydomain> IN AAAA -E
Since the host running TOR is IPv6 enabled the resolver first tries to lookup IPv6 addresses. However
the problem is not the AAAA query, which should be "resolved" by #280, but the fact that the host's
domain name is added if the first query failed.
This even works with non-FQDN names, eg. use this to access my webserver:
http://www.peterp1701.exit/
As a workaround someone can set LOCALDOMAIN=. in the TOR init script, but appending the default domain
and using the domain search list should really be disabled by TOR itself.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: peterpramb0.1.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/318Hibernating disables local socks proxy2020-06-13T13:56:32ZTracHibernating disables local socks proxyVersion: tor-0.1.1.23
Aug 10 17:18:34.175 [notice] consider_hibernation(): Bandwidth soft limit reached; commencing hibernation.
Aug 10 17:21:43.194 [notice] hibernate_go_dormant(): Going dormant. Blowing away remaining connections.
On...Version: tor-0.1.1.23
Aug 10 17:18:34.175 [notice] consider_hibernation(): Bandwidth soft limit reached; commencing hibernation.
Aug 10 17:21:43.194 [notice] hibernate_go_dormant(): Going dormant. Blowing away remaining connections.
Once the bandwidth limit is hit all sockets are closed - including the Socks port. Bandwidth limits allow the
user to contribute whatever bandwidth they have available; however it is likely the enduser won't be able to
use Tor at all if bandwidth limits are configured. The network may have already used all the allocated
bandwidth causing Tor to hibernate. Currently the user is better off disabling "ORPort" and not contributing
to the network, this way they can be sure Tor will be available when/if they choose to use it.
Suggestion:
- The bandwidth limits should exclude and not account for any connections/data via the local Socks port.
- Hibernate should just temporarily disable "ORPort" once foreign nodes have used the data allocation.
Hope this report helps.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: markhttps://gitlab.torproject.org/legacy/trac/-/issues/317Unable to setup Tor server2020-06-13T13:56:32ZTracUnable to setup Tor serverI have run Tor server on Windows XP pro Sp2 (fully up to date) for many weeks without problems. But last week i update to
version 0.1.1.22 via Vidalia buddle (www.vidalia-project.net/dist/vidalia-bundle-0.1.1.22-0.0.7.exe) and now i can'...I have run Tor server on Windows XP pro Sp2 (fully up to date) for many weeks without problems. But last week i update to
version 0.1.1.22 via Vidalia buddle (www.vidalia-project.net/dist/vidalia-bundle-0.1.1.22-0.0.7.exe) and now i can't setup
a Tor server.
First i got many warning messages :
août 02 21:17:31:312 [Notice] connection_create_listener(): Opening OR listener on 0.0.0.0:9001
août 02 21:17:31:312 [Notice] Your Tor server's identity key fingerprint is 'Ygdrasil 16C3 D04A A690 40EC 1DB2 F5D3 1555 0981 2D69 34D7'
août 02 21:17:31:312 [Notice] Now checking whether ORPort 82.65.94.25:9001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
août 02 21:17:31:312 [Warning] spawn_cpuworker(): Couldn't construct socketpair: No such file or directory
août 02 21:17:31:312 [Warning] spawn_enough_cpuworkers(): Spawn failed. Will try again later.
août 02 21:17:31:312 [Warning] spawn_dnsworker(): Couldn't construct socketpair: No such file or directory
août 02 21:17:31:312 [Warning] spawn_enough_dnsworkers(): Spawn failed. Will try again later.
etc
and the server is not reachable :
août 02 21:37:29:562 [Warning] second_elapsed_callback(): Your server (82.65.94.25:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
août 02 21:37:29:687 [Warning] second_elapsed_callback(): Your server (82.65.94.25:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
Now, when i restart my computer Tor crash with this message :
juil. 31 21:08:10:718 [Error] main.c:137: connection_add: Assertion conn->s >= 0 failed; aborting.
The bug is fully reproductible. Just trying again to setup a server ...
It looks like a socket creation failure, so i trying some registry hacks in TcpIp/Parameters .... unlucky.
The Tor client run well, but i feel more funny to contribute to the onion land with my own ;) So any idea
to workaround will be good.
Cheer
Richie
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Sk0llhttps://gitlab.torproject.org/legacy/trac/-/issues/314Application uses IP warning when that IP is mapped through MapAddress to a ho...2020-06-13T13:56:30ZTracApplication uses IP warning when that IP is mapped through MapAddress to a hostnameThe Tor client provides MapAddress feature for mapping addresses.
It's also a handy way to force applications which try to resolve DNS names themselves to use a proper hostname.
Tor flags this as a warning, even though it does the resol...The Tor client provides MapAddress feature for mapping addresses.
It's also a handy way to force applications which try to resolve DNS names themselves to use a proper hostname.
Tor flags this as a warning, even though it does the resolution on its own.
Tor shouldn't give the warning iff that IP is mapped.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: AstralStormRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/313Norton AntiVirus (WinXP) reports worm on Tor 0.1.1.222020-06-13T13:56:30ZTracNorton AntiVirus (WinXP) reports worm on Tor 0.1.1.22Was running Tor 0.1.1.21 on Windows XP as a server. Was showing very low bit rates -
so decided to upgrade to newest version of Tor when it came out.
Now Norton Anti Virus is popping security alerts "Norton Internet Worm Protection
ha...Was running Tor 0.1.1.21 on Windows XP as a server. Was showing very low bit rates -
so decided to upgrade to newest version of Tor when it came out.
Now Norton Anti Virus is popping security alerts "Norton Internet Worm Protection
has detected a remoter system that is trying to access your computer..."
Path C:\Program Files\Tor\tor.exe
Direction: Inbound
Local address 192.168.2.50 (my NATed local IP)
Local Port 19001 (the port I selected for Tor to use)
Remote address 212.x.x.x (someone elses IP)
Remote port 60832
This keeps occuring at irregular intervals, even when I select "Permit" and have
attempted to configure Norton to allow tor.exe.
This did not happen on 0.1.1.21
Have searched for similar issues experienced by others but no luck - any ideas
(besides not running Tor server on XP)
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Grumpyhttps://gitlab.torproject.org/legacy/trac/-/issues/312100% CPU Usage2020-06-13T13:56:29ZTrac100% CPU UsageWhen used in conjunction with Azureus, tor continuously uses 100% of the CPU. Stopping and starting tor will halt the CPU usage for a few minutes, but the problem inevitably returns.
OS: Windows XP SP2
CPU: AMD Athlon 64 3500+ (NewCast...When used in conjunction with Azureus, tor continuously uses 100% of the CPU. Stopping and starting tor will halt the CPU usage for a few minutes, but the problem inevitably returns.
OS: Windows XP SP2
CPU: AMD Athlon 64 3500+ (NewCastle)
Azureus: 2.4.0.2
Vidalia: 0.0.5
Tor: 0.1.1.21
Qt: 4.1.0
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: aaronsellshttps://gitlab.torproject.org/legacy/trac/-/issues/311dirservers not zlibbing descriptors correctly2020-06-13T13:56:28ZRoger Dingledinedirservers not zlibbing descriptors correctlyJun 28 09:53:32.816 [debug] read_to_buf_impl(): Encountered eof
Jun 28 09:53:32.816 [debug] fetch_from_buf_http(): headerlen 123, bodylen 6436.
Jun 28 09:53:32.816 [debug] connection_dir_client_reached_eof(): Received response from direc...Jun 28 09:53:32.816 [debug] read_to_buf_impl(): Encountered eof
Jun 28 09:53:32.816 [debug] fetch_from_buf_http(): headerlen 123, bodylen 6436.
Jun 28 09:53:32.816 [debug] connection_dir_client_reached_eof(): Received response from directory server '86.59.21.38:80': 200 "OK"
Jun 28 09:53:32.816 [debug] connection_dir_client_reached_eof(): Time on received directory is within tolerance; we are 0 seconds skewed. (That's okay.)
Jun 28 09:53:32.816 [info] tor_gzip_uncompress(): possible truncated or corrupt zlib data
Jun 28 09:53:32.816 [info] connection_dir_client_reached_eof(): Unable to decompress HTTP body (server '86.59.21.38:80').
Jun 28 09:53:32.816 [debug] conn_close_if_marked(): Cleaning up connection (fd 706).
Jun 28 09:53:32.816 [debug] router_set_status(): Marking router 'tor26' as down.
Jun 28 09:53:32.816 [info] connection_dir_request_failed(): Giving up on directory server at '86.59.21.38'; retrying
This is occuring on tor26 and moria2, both of which are running recent cvs.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/309New routerlist.c assert in Tor cvs2020-06-13T13:56:28ZTracNew routerlist.c assert in Tor cvsI've had a couple of crashes on tor server clarity. I update from cvs daily.
Crashes started occuring about 6/21 or 6/22? Tor runs for about
24-36 hours before the crash.
(Sorry about the mistaken cvs update bug report...I knew better!)...I've had a couple of crashes on tor server clarity. I update from cvs daily.
Crashes started occuring about 6/21 or 6/22? Tor runs for about
24-36 hours before the crash.
(Sorry about the mistaken cvs update bug report...I knew better!)
Debug output and version info:
clarity 96 -> gdb /usr/local/bin/tor tor.core
GNU gdb 5.3nb1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386--netbsdelf"...
Core was generated by `tor'.
Program terminated with signal 6, Aborted.
Reading symbols from /usr/libexec/ld.elf_so...done.
Loaded symbols for /usr/libexec/ld.elf_so
Reading symbols from /usr/pkg/lib/libz.so.1...done.
Loaded symbols for /usr/pkg/lib/libz.so.1
Reading symbols from /usr/lib/libssl.so.3...done.
Loaded symbols for /usr/lib/libssl.so.3
Reading symbols from /usr/lib/libcrypto.so.2...done.
Loaded symbols for /usr/lib/libcrypto.so.2
Reading symbols from /usr/pkg/lib/libevent-1.1a.so.1...done.
Loaded symbols for /usr/pkg/lib/libevent-1.1a.so.1
Reading symbols from /usr/lib/libc.so.12...done.
Loaded symbols for /usr/lib/libc.so.12
#0 0x4822ffeb in kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0x4822ffeb in kill () from /usr/lib/libc.so.12
#1 0x482a4a3f in abort () from /usr/lib/libc.so.12
#2 0x0808b819 in signed_descriptor_get_body (desc=0x9483540)
at routerlist.c:1165
#3 0x08089ea9 in router_rebuild_store (force=0) at routerlist.c:250
#4 0x0808d70e in router_load_routers_from_string (s=0x9867f95 "",
saved_location=SAVED_NOWHERE, requested_fingerprints=0x8d18c60)
at routerlist.c:2030
#5 0x08071200 in connection_dir_client_reached_eof (conn=0x953bc00)
at directory.c:1079
#6 0x080719d3 in connection_dir_reached_eof (conn=0x953bc00)
at directory.c:1201
#7 0x08060d6a in connection_handle_read (conn=0x953bc00) at connection.c:1228
#8 0x0807b9e7 in conn_read_callback (fd=27, event=2, _conn=0x953bc00)
at main.c:407
#9 0x48210988 in event_process_active () from /usr/pkg/lib/libevent-1.1a.so.1
#10 0x48210bee in event_base_loop () from /usr/pkg/lib/libevent-1.1a.so.1
#11 0x48210a77 in event_loop () from /usr/pkg/lib/libevent-1.1a.so.1
#12 0x482109b6 in event_dispatch () from /usr/pkg/lib/libevent-1.1a.so.1
#13 0x0807cc38 in do_main_loop () at main.c:1157
#14 0x0807d82d in tor_main (argc=7, argv=0xbfbffb1c) at main.c:2132
#15 0x08094f97 in main (argc=7, argv=0xbfbffb1c) at tor_main.c:22
#16 0x0804c072 in ___start ()
clarity 97 -> tor -V
Jun 25 11:58:23.175 [notice] Tor v0.1.2.0-alpha-cvs. This is experimental software. Do not rely on it for strong anonymity.
Jun 25 07:58:23.210 [warn] config_get_commandlines(): Command-line option '-V' with no value. Failing.
Jun 25 07:58:23.211 [err] tor_init(): Reading config failed--see warnings above.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: yancmNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/308confused by clock skew, doesn't start [debian #354259]2020-06-13T13:56:26Zweasel (Peter Palfrader)confused by clock skew, doesn't start [debian #354259]> Hi!
> first thanks for your effort in tor! It's great! ...> Hi!
> first thanks for your effort in tor! It's great!
> from time to time I have my hw clock resetted back to 1904 if I leave my
> laptop without battery, tor gets confused and won't start:
>
> Jan 01 01:24:26.452 [notice] Tor 0.1.1.12-alpha opening log file.
> [...working normally here...]
> Jan 01 01:24:28.608 [warn] router_set_networkstatus(): Network status
> from directory server "moria1" at 18.244.0
> .188:9031 was published in the future (2006-02-24 12:05:52 GMT).
> Somebody is skewed here: check your clock. Not
> caching.
>
> but warping the clock to the future isn't liked by tor who eats almost
> all the cpu. Then I try to restart it:
>
> Feb 24 14:41:09.619 [notice] Tor 0.1.1.12-alpha opening log file.
> Feb 24 14:41:09.619 [warn] parse_iso_time(): Got invalid ISO time
> "1904-01-01 00:39:26". (Before 1970)
> Feb 24 14:41:09.620 [warn] Invalid time '1904-01-01 00:39:26' for
> keyword 'BWHistoryReadEnds'
> Feb 24 14:41:09.620 [err] set_options(): Acting on config options left
> us in a broken state. Dying.
>
> that is, it stores dates it can't parse back :)
Ooops, I'm sorry I have missed this bug report. I'm forwarding it to
the developers for their attention.
tor-bugs, please CC 354259@bugs.debian.org on future mails about that
bug.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/307Win XP tor crash2020-06-13T13:56:26ZTracWin XP tor crashUsing Windows XP Pro, SP2.
Tor: 0.1.1.21 (which isn't in the "reported version" drop down box on this bug reporter!)
It seems Tor is unhappy. First it crashed. Now it seems to have made vidalia unstable (because I can't right-click it's...Using Windows XP Pro, SP2.
Tor: 0.1.1.21 (which isn't in the "reported version" drop down box on this bug reporter!)
It seems Tor is unhappy. First it crashed. Now it seems to have made vidalia unstable (because I can't right-click it's taskbar icon), and when I try to run a new version of videlia I instantly get a:
"Vidalia detected Tor exiting unexpectedly"
This is the log from the start-up:
Jun 23 11:11:07:281 [Debug] conn_read_callback(): socket 1588 wants to read.
Jun 23 11:11:07:281 [Debug] conn_read_callback(): socket 1588 wants to read.
Jun 23 11:11:07:359 [Notice] Tor v0.1.1.21. This is experimental software. Do not rely on it for strong anonymity.
Jun 23 11:11:07:359 [Notice] Initialized libevent version 1.1a+imweasel using method win32. Good.
Jun 23 11:11:07:359 [Notice] connection_create_listener(): Opening Socks listener on 127.0.0.1:9050
Jun 23 11:11:07:359 [Warning] connection_create_listener(): Could not bind to 127.0.0.1:9050: Address already in use [WSAEADDRINUSE ]. Is Tor already running?
Jun 23 11:11:07:359 [Warning] Failed to parse/validate config: Failed to bind one of the listener ports.
Jun 23 11:11:07:359 [Error] tor_init(): Reading config failed--see warnings above. For usage, try -h.
This bug is probably because there's another version of vidalia/tor running that I can't shut down without killing using task-manager. Either way if you try to run a second version at the same time as the first it should die more gracefully.
You'd probably get more bug reports if you didn't force people create an account.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Moriartyhttps://gitlab.torproject.org/legacy/trac/-/issues/306tor servers not publishing dirport sometimes2020-06-13T13:56:26ZRoger Dingledinetor servers not publishing dirport sometimesWhen a Tor server finds its ORPort reachable, publishes a descriptor, and then finds
its DirPort reachable, does it then try to republish a new descriptor?
The operator of 1898 reports no.
[Automatically added by flyspray2trac: Operati...When a Tor server finds its ORPort reachable, publishes a descriptor, and then finds
its DirPort reachable, does it then try to republish a new descriptor?
The operator of 1898 reports no.
[Automatically added by flyspray2trac: Operating System: All]0.1.2.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/305Tor uninstall script isn't binary2020-06-13T13:56:25ZAndrew LewmanTor uninstall script isn't binaryThe Tor_Uninstaller.applescript located in /Library/Tor should be shipped as a binary with pretty icon and world executable.
This would allow users to 1) find it; 2) uninstall Tor cleanly.
[Automatically added by flyspray2trac: Operatin...The Tor_Uninstaller.applescript located in /Library/Tor should be shipped as a binary with pretty icon and world executable.
This would allow users to 1) find it; 2) uninstall Tor cleanly.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]0.1.1.x-finalAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/304Circuits being hijacked?2020-06-13T13:56:25ZTracCircuits being hijacked?
For all I know, this condition may be normal, but it seems odd to me and causes
me to wonder if some routers have been compromised or if circuits are being
hijacked.
First, I noticed that the Tor Detector sometimes reported that I was ...
For all I know, this condition may be normal, but it seems odd to me and causes
me to wonder if some routers have been compromised or if circuits are being
hijacked.
First, I noticed that the Tor Detector sometimes reported that I was connecting
from aala.MyLittleCorner.org (not sure if I remember the caps right), ip
149.9.0.25 -- which the detector said was _not_ a valid Tor router. To add to
the mystery, that router was supposedly configured as a middle-man only (reject
*:*) in the cached-routers file.
Alarmed, I added the fingerprint for that router to the ExcludeNodes in my torrc
file, cleared all the cache and state files, closed Tor, and re-started.
Surprise, that router was still sometimes being reported as my exit node by the
Tor detector and irc servers. Irc connections were extremely hard to come by
and short-lived.
The Tor Detector page mentioned the possibility of a "multi-homed" router.
Unable to find that term in the documentation, I decided to search the cache
files for similar ip addresses. I found a total of five routers for ip
149.9.*.* -- all of them running FreeBSD i386 and Tor 0.1.0.16:
router mauger 149.9.137.153 9001 0 9030
platform Tor 0.1.0.16 on FreeBSD i386
router donk3ypunch 149.9.25.222 9001 0 9030
platform Tor 0.1.0.16 on FreeBSD i386
router TheGreatSantini 149.9.92.194 9001 0 9030
platform Tor 0.1.0.16 on FreeBSD i38
router aala 149.9.0.25 9001 0 9030
platform Tor 0.1.0.16 on FreeBSD i386
router paxprivoso 149.9.205.73 9001 0 9030
platform Tor 0.1.0.16 on FreeBSD i386
I put *all* their fingerprints in the ExcludeNodes setting, and since then I
have not noticed the anomaly with Tor Detector, nor the unusual irc behavior.
I was using Tor 0.1.1.21 when I noticed phenomenon. It also occurred when I
experimented with 0.1.1.20 and 0.1.0.17.
Is this a problem or expected behavior?
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: anm_3418https://gitlab.torproject.org/legacy/trac/-/issues/303prevent single-hop proxy usage2020-06-13T13:56:25Zgoodellprevent single-hop proxy usageControllers that allow Tor clients to use Tor servers as single-hop
proxies present a danger to the Tor network. This use not only
reduces the anonymity attained by the client but also creates new
incentives for adversaries to run malic...Controllers that allow Tor clients to use Tor servers as single-hop
proxies present a danger to the Tor network. This use not only
reduces the anonymity attained by the client but also creates new
incentives for adversaries to run malicious Tor servers, compromise
existing Tor servers, or request logs from Tor servers.
Nevertheless, some users of the Tor network may have an incentive
to use Tor servers in this manner. Those users include (a) those
who are interested in anonymity from the server but not from the
network and (b) those who want to use Tor as a perspective access
network but do not care about anonymity.
Servers can defend against this particular attack by requiring
that for any given circuit extension request it receives, either
(a) the host from which the request was received OR (b) the
server to which the request will be extended is a valid Tor
server. This assures that each circuit involving this server
includes at least two Tor servers (though the first may actually
be a client).
To my knowledge, there is no way for servers to ensure that they
are only carrying circuits of length greater than two without
compromising some of the anonymity properties of the circuit.
This approach creates some new irregularities. For example, it
presumes that all servers have a (roughly) equivalent list of
all Tor servers. In particular, there will be a certain period
of time during which a new Tor server will not be accepted as
the second hop in a three-hop circuit while the other servers
learn about its existence.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/301OSX 10.4 Tiger distribution installs on 10.3 Panther without warning2020-06-13T13:56:24ZTracOSX 10.4 Tiger distribution installs on 10.3 Panther without warningWhen downloading the Tor installation package, it is very possible to select the wrong one for your OS.
In downloading the Tor distribution with the Vidalia interface for OSX 10.4 (Tiger) (http://www.vidalia-project.net/dist/vidalia-bund...When downloading the Tor installation package, it is very possible to select the wrong one for your OS.
In downloading the Tor distribution with the Vidalia interface for OSX 10.4 (Tiger) (http://www.vidalia-project.net/dist/vidalia-bundle-0.1.1.21-0.0.5-2.dmg), then running the install, the installation program does not check to see if it is being run on a OSX 10.4 machine.
The install interface in this package looks exactly like the standard Apple install interface, which normally will check your OS version and stop you from installing if it is not correct.
Trying to run Tor for OSX 10.4 in OSX 10.3 from within Vidallia gives an error window that states Tor failed to start and to check the Message window for details.
The message window remains blank - no messages were recorded.
Running Tor (OSX 10.4) in OSX 10.3.x from the command line gives this error:
geep:~ root# tor
dyld: tor Undefined symbols:
tor undefined reference to ___stderrp expected to be defined in /usr/lib/libSystem.B.dylib
tor undefined reference to ___stdinp expected to be defined in /usr/lib/libSystem.B.dylib
Trace/BPT trap
No other messages or notices are recorded.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: dosboss0.1.1.21Andrew LewmanAndrew Lewman