Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:59:23Zhttps://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/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/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/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/5990.2.0.18-alpha can't create a server behind NAT automatically2020-06-13T14:09:03ZAndrew Lewman0.2.0.18-alpha can't create a server behind NAT automaticallyIt appears 0.2.0.18-alpha can't detect my external IP address while behind NAT. Exact same torrc works in 0.2.0.16-alpha.
Feb 04 22:05:17.479 [Info] resolve_my_address(): Guessed local hostname 'mini.local' resolves to a private IP add...It appears 0.2.0.18-alpha can't detect my external IP address while behind NAT. Exact same torrc works in 0.2.0.16-alpha.
Feb 04 22:05:17.479 [Info] resolve_my_address(): Guessed local hostname 'mini.local' resolves to a private IP address (172.16.31.3). Trying something else.
Feb 04 22:05:17.483 [Info] get_interface_address6(): connect() failed: Invalid argument
Feb 04 22:05:17.486 [Info] resolve_my_address(): Could not get local interface IP address. Too bad.
Feb 04 22:05:17.490 [Info] resolve_my_address(): Address 'mini.local' resolves to private IP address '172.16.31.3'. Tor servers that use the default DirServers must have public IP addresses.
Feb 04 22:05:17.494 [Info] router_pick_published_address(): Could not determine our address locally. Checking if directory headers provide any hints.
Feb 04 22:05:17.500 [Info] router_pick_published_address(): No hints from directory headers either. Will try again later.
Feb 04 22:05:29.379 [Notice] Opening OR listener on 0.0.0.0:8443
Feb 04 22:05:29.383 [Notice] Opening Directory listener on 0.0.0.0:8080
I configured everything via Vidalia only. I know I can put in the external IP, but as the external IP is on DHCP, it changes every few days.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]0.2.0.x-rchttps://gitlab.torproject.org/legacy/trac/-/issues/586alpha users accumulating hashedcontrolpassword lines2020-06-13T13:59:11ZRoger Dingledinealpha users accumulating hashedcontrolpassword linesIn Tor 0.2.0.13-alpha, I added this feature:
- Allow multiple HashedControlPassword config lines, to support
multiple controller passwords.
But since Vidalia launches Tor by listing a newly generated
HashedControlPassword on t...In Tor 0.2.0.13-alpha, I added this feature:
- Allow multiple HashedControlPassword config lines, to support
multiple controller passwords.
But since Vidalia launches Tor by listing a newly generated
HashedControlPassword on the command-line, every time you
launch Vidalia and change thing and saveconf, it will append
that new HashedControlPassword to your torrc.
So my ~/.vidalia/torrc has 8 of them now. I bet there are people
who have even more.
It occurs to me that options given on the command line might not
need to be saved during a saveconf. But it's far too late to act
on that realization.
The best idea I've got is to change HashedControlPassword back so
you can only have one, and add a new config option
AlternateHashedControlPassword which lets you set multiple and
acts like the current one.
Then we should clear out the extra lines in the current torrcs,
and that new feature is still around in case somebody wants to
use it.
Anybody have a better answer?
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rchttps://gitlab.torproject.org/legacy/trac/-/issues/537Warnings on startup from cached descriptors and invalid time in mtbf history2020-06-13T13:58:52ZRoger DingledineWarnings on startup from cached descriptors and invalid time in mtbf historyhttp://asteria.noreply.org/~weasel/.loud-tor
includes
Bug #1:
Oct 27 12:43:14.706 [warn] Got invalid ISO time "1969-11-08 08:36:56".
(Before 1970)
Oct 27 12:43:14.706 [warn] Couldn't parse started-tracking time in mtbf
history file.
...http://asteria.noreply.org/~weasel/.loud-tor
includes
Bug #1:
Oct 27 12:43:14.706 [warn] Got invalid ISO time "1969-11-08 08:36:56".
(Before 1970)
Oct 27 12:43:14.706 [warn] Couldn't parse started-tracking time in mtbf
history file.
Bug #2: perhaps we shouldn't bitch to the log when we have complaints
(or at least certain complaints) about a descriptor we read from the
cache.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-rcNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/437Tor tries to connect to a TrackHostExits host/exit pair indefinitely2020-06-13T13:58:13ZTracTor tries to connect to a TrackHostExits host/exit pair indefinitelyWhen TrackHostExits is used and an exit is chosen for the site that's being connected to, if the exit fails to connect
to the site but is still running, Tor will attempt to connect to the site through that exit node through different
cir...When TrackHostExits is used and an exit is chosen for the site that's being connected to, if the exit fails to connect
to the site but is still running, Tor will attempt to connect to the site through that exit node through different
circuits and continue to fail to connect into all of eternity, until it finally does manage to make a connection, or
until the stream is closed.
Tor should be able to determine that the exit node is no longer capable of making a connection to the specified site,
and forget the current exit and use another after failing it's connection attempts for some extended period of time.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: SnowKate7090.2.0.x-rcRoger DingledineRoger Dingledine