Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:51Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/331ExitPolicy should reject nntps2020-06-27T14:10:51ZTracExitPolicy should reject nntpsThe default exit policy rejects nntp but not nntps.
The following line is missing:
ExitPolicy reject *:563
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: JensThe default exit policy rejects nntp but not nntps.
The following line is missing:
ExitPolicy reject *:563
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: JensAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/330DNS at exit should tolerate broken providers (aka "Earthlink")2020-06-27T14:10:52ZNick MathewsonDNS at exit should tolerate broken providers (aka "Earthlink")See http://slashdot.org/article.pl?sid=06/09/03/1359221
Some ISPs have decided that implementing the internet correctly is not so worthwhile
as pointing people towards their advertising. Sadly, some Tor exit server operators
have signe...See http://slashdot.org/article.pl?sid=06/09/03/1359221
Some ISPs have decided that implementing the internet correctly is not so worthwhile
as pointing people towards their advertising. Sadly, some Tor exit server operators
have signed up for these ISPs, and every time they attempt to resolve a nonexistant DNS
entry, they get the IP for the ISP's "oops! let's help you out!" site rather than the
correct error code.
Exit nodes could detect this pretty easily by periodically attempting to lookup a few
guaranteed-to-be-nonexistant domains, and seeing whether they resolve to anything. If
they do, the exit node could
a) switch to using the root nameservers
b) treat any IP returned by such test resolves as equivalent to a "no such domain" error.
c) warn the operator
d) ... ?
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/329do_main_loop() error, no buffer space available, TOR crash2022-04-06T21:04:08ZTracdo_main_loop() error, no buffer space available, TOR crashUpon opening this page http://www.vanjongeleu.nl/, Privoxy start generating this message in the log:
Sep 04 16:03:54 Privoxy(02716) Request: www.vanjongeleu.nl/index2.php?page=home&subpage=homeNieuws
Sep 04 16:03:54 Privoxy(02820) Error...Upon opening this page http://www.vanjongeleu.nl/, Privoxy start generating this message in the log:
Sep 04 16:03:54 Privoxy(02716) Request: www.vanjongeleu.nl/index2.php?page=home&subpage=homeNieuws
Sep 04 16:03:54 Privoxy(02820) Error: write to: www.vanjongeleu.nl failed: WSAECONNABORTED - Software caused connection abort.
This causes TOR to crash with the following error:
sep 04 15:57:36:750 [Error] do_main_loop(): libevent call with win32 failed: No buffer space available [WSAENOBUFS ] [10055]
Using Firefox 1.5.0.6, and the TOR-package "Tor 0.1.1.23" on Windows XP Pro with SP2 and all the latest patches installed.
The error is repeatable all the time.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: ziesjoemhttps://gitlab.torproject.org/tpo/core/tor/-/issues/328Valid flags should only apply for naming authorities?2020-06-27T14:10:52ZRoger DingledineValid flags should only apply for naming authorities?Right now authorities mark servers as valid unless they manually decide not to.
Part of the goal of the 'naming' flag for authorities is to specify whether they
want to futz with their configuration and express opinions, or just leave i...Right now authorities mark servers as valid unless they manually decide not to.
Part of the goal of the 'naming' flag for authorities is to specify whether they
want to futz with their configuration and express opinions, or just leave it to
run.
I think we should make clients decide whether a server is valid based on a majority
of naming authorities, rather than a majority of all authorities.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/327Build failure and warnings with svn 83082020-06-27T14:10:52ZTracBuild failure and warnings with svn 8308Hi,
I use NetBSD 3_Stable...
First, there is a mistake in src/common/compat.h. I interpreted what I thought you meant and created this diff:
clarity 141 -> svn di src/common/compat.h
Index: src/common/compat.h
=========================...Hi,
I use NetBSD 3_Stable...
First, there is a mistake in src/common/compat.h. I interpreted what I thought you meant and created this diff:
clarity 141 -> svn di src/common/compat.h
Index: src/common/compat.h
===================================================================
--- src/common/compat.h (revision 8308)
+++ src/common/compat.h (working copy)
@@ -90,7 +90,7 @@
#endif
/* GCC has several useful attributes. */
-#ifdef __GNUC__ && __GNUC_MAJOR__ >= 3
+#if defined(__GNUC__) && __GNUC_MAJOR__ >= 3
#define ATTR_NORETURN __attribute__((noreturn))
#define ATTR_PURE __attribute__((pure))
#define ATTR_MALLOC __attribute__((malloc))
****
In addition, after fixing this, I find the following warnings as probable mistakes:
util.c: In function `tor_strlower':
util.c:311: warning: subscript has type `char'
util.c: In function `tor_strupper':
util.c:322: warning: subscript has type `char'
----
config.c: In function `get_default_nickname':
config.c:1740: warning: subscript has type `char'
I don't know if this functions properly, I do not want to install until it builds clean.
--gene
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: yancmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/326New eventdns error messages w/svn 82892020-06-27T14:10:52ZTracNew 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/tpo/core/tor/-/issues/325[Ubuntu]: Old Tor Package2020-06-27T14:10:52ZTrac[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/tpo/core/tor/-/issues/324Subversion 8275 builds die on start-up2022-02-14T19:55:03ZTracSubversion 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
legacy/trac#2 0x08099e7b in _tor_strdup (s=0x0) at util.c:170
legacy/trac#3 0x0807ab3a in configure_nameservers (force=1) at dns.c:1285
legacy/trac#4 0x08078c76 in dns_init () at dns.c:184
legacy/trac#5 0x0807e837 in do_main_loop () at main.c:1113
legacy/trac#6 0x0807f4dd in tor_main (argc=7, argv=0xbfbfed78) at main.c:2163
legacy/trac#7 0x08099307 in main (argc=7, argv=0xbfbfed78) at tor_main.c:22
legacy/trac#8 0x0804c266 in ___start ()
(
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/323Vidalia causes some InstallShield installers to hang2020-06-27T14:10:52ZTracVidalia 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/tpo/core/tor/-/issues/322Cannot open Vidalia through Tor2020-06-27T14:10:53ZTracCannot 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/tpo/core/tor/-/issues/321TOR resolver appends localdomain to DNS requests2020-06-27T14:10:53ZTracTOR 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 legacy/trac#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/tpo/core/tor/-/issues/318Hibernating disables local socks proxy2020-06-27T14:10:53ZTracHibernating 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/tpo/core/tor/-/issues/317Unable to setup Tor server2020-06-27T14:10:53ZTracUnable 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/tpo/core/tor/-/issues/316tor crash cvs current on NetBSD 2.1_Stable2020-06-27T14:10:53ZTractor crash cvs current on NetBSD 2.1_StableMy tor server has crashed a few times with the following log messages
Aug 01 22:37:40.228 [warn] Please report: your clock just jumped 26 seconds forward; assuming established circuits no longer work.
Aug 01 22:37:52.850 [warn] Please r...My tor server has crashed a few times with the following log messages
Aug 01 22:37:40.228 [warn] Please report: your clock just jumped 26 seconds forward; assuming established circuits no longer work.
Aug 01 22:37:52.850 [warn] Please report: your clock just jumped 10 seconds forward; assuming established circuits no longer work.
Aug 01 22:52:49.537 [warn] Please report: your clock just jumped 13 seconds forward; assuming established circuits no longer work.
Aug 01 23:17:02.928 [err] dns.c:1212: assert_cache_ok: Assertion _cache_map_HT_REP_OK(&cache_root) failed; aborting.
The clock thing has been there a while, but the last line is the actual crash. I sync my clock via
ntpd and my log entries indicate drift of less than 0.2 seconds per day.
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 0x48230feb in kill () from /usr/lib/libc.so.12
(gdb) bt
#0 0x48230feb in kill () from /usr/lib/libc.so.12
#1 0x482a5a3f in abort () from /usr/lib/libc.so.12
legacy/trac#2 0x0807a75e in assert_cache_ok () at dns.c:1217
legacy/trac#3 0x08078a5a in dns_resolve (exitconn=0x9588b00) at dns.c:425
legacy/trac#4 0x080669da in connection_exit_begin_conn (cell=0xbfbff560, circ=0x957de00)
at connection_edge.c:1683
legacy/trac#5 0x08081e46 in connection_edge_process_relay_cell (cell=0xbfbff560,
circ=0x957de00, conn=0x0, layer_hint=0x0) at relay.c:943
legacy/trac#6 0x080806ec in circuit_receive_relay_cell (cell=0xbfbff560, circ=0x957de00,
cell_direction=2) at relay.c:169
legacy/trac#7 0x08058750 in command_process_relay_cell (cell=0xbfbff560, conn=0x9557500)
at command.c:316
legacy/trac#8 0x08068a30 in connection_or_process_cells_from_inbuf (conn=0x9557500)
at connection_or.c:778
legacy/trac#9 0x08061677 in connection_handle_read (conn=0x9557500) at connection.c:1223
legacy/trac#10 0x0807ca5f in conn_read_callback (fd=31, event=2, _conn=0x9557500)
at main.c:407
legacy/trac#11 0x48211988 in event_process_active () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#12 0x48211bee in event_base_loop () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#13 0x48211a77 in event_loop () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#14 0x482119b6 in event_dispatch () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#15 0x0807dcb8 in do_main_loop () at main.c:1153
legacy/trac#16 0x0807e8a9 in tor_main (argc=7, argv=0xbfbffb1c) at main.c:2128
legacy/trac#17 0x080966e3 in main (argc=7, argv=0xbfbffb1c) at tor_main.c:22
legacy/trac#18 0x0804c072 in ___start ()
Thanks,
gene
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/314Application uses IP warning when that IP is mapped through MapAddress to a ho...2020-06-27T14:10:53ZTracApplication 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/tpo/core/tor/-/issues/312100% CPU Usage2020-06-27T14:10:53ZTrac100% 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/tpo/core/tor/-/issues/311dirservers not zlibbing descriptors correctly2020-06-27T14:10:53ZRoger 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/tpo/core/tor/-/issues/309New routerlist.c assert in Tor cvs2020-06-27T14:10:54ZTracNew 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
legacy/trac#2 0x0808b819 in signed_descriptor_get_body (desc=0x9483540)
at routerlist.c:1165
legacy/trac#3 0x08089ea9 in router_rebuild_store (force=0) at routerlist.c:250
legacy/trac#4 0x0808d70e in router_load_routers_from_string (s=0x9867f95 "",
saved_location=SAVED_NOWHERE, requested_fingerprints=0x8d18c60)
at routerlist.c:2030
legacy/trac#5 0x08071200 in connection_dir_client_reached_eof (conn=0x953bc00)
at directory.c:1079
legacy/trac#6 0x080719d3 in connection_dir_reached_eof (conn=0x953bc00)
at directory.c:1201
legacy/trac#7 0x08060d6a in connection_handle_read (conn=0x953bc00) at connection.c:1228
legacy/trac#8 0x0807b9e7 in conn_read_callback (fd=27, event=2, _conn=0x953bc00)
at main.c:407
legacy/trac#9 0x48210988 in event_process_active () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#10 0x48210bee in event_base_loop () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#11 0x48210a77 in event_loop () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#12 0x482109b6 in event_dispatch () from /usr/pkg/lib/libevent-1.1a.so.1
legacy/trac#13 0x0807cc38 in do_main_loop () at main.c:1157
legacy/trac#14 0x0807d82d in tor_main (argc=7, argv=0xbfbffb1c) at main.c:2132
legacy/trac#15 0x08094f97 in main (argc=7, argv=0xbfbffb1c) at tor_main.c:22
legacy/trac#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/tpo/core/tor/-/issues/308confused by clock skew, doesn't start [debian #354259]2020-06-27T14:10:54Zweasel (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/tpo/core/tor/-/issues/307Win XP tor crash2020-06-27T14:10:54ZTracWin 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**: Moriarty