Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:14Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/768one-hop circuit restriction should not apply to special-purpose routers2020-06-27T14:10:14Zgoodellone-hop circuit restriction should not apply to special-purpose routersAt some point (r9735?), code was added to src/or/control.c that prevents
controllers from attaching streams to one-hop circuits. The idea seems to be
that we can use the cost of forking and maintaining a patch as a lever to
prevent peo...At some point (r9735?), code was added to src/or/control.c that prevents
controllers from attaching streams to one-hop circuits. The idea seems to be
that we can use the cost of forking and maintaining a patch as a lever to
prevent people from writing controllers that jeopardize the operational
security of routers and the anonymity properties of the Tor network by creating
and using one-hop circuits rather than the standard three-hop circuits. It may
be, for example, that some users do not actually seek true anonymity but simply
reachability through network perspectives afforded by the Tor network, and
since anonymity is stronger in numbers, forcing users to contribute to
anonymity and decrease the risk to server operators by using full-length paths
may be reasonable.
Whether or not we agree that the particular approach of using hardcoded,
immutable policy in the Tor client to limit self-determinism on the part of
clients is the right way to address the risks posed by one-hop circuit
utilization (for example, I think that routers ought to take responsibility for
ensuring that they are not allowing exit from one-hop circuits), it remains
true that as presently implemented, the sweeping restriction of one-hop
circuits for all routers limits the usefulness of Tor as a general-purpose
technology for building circuits. In particular, we should allow for
controllers, such as Blossom, that create and use single-hop circuits involving
routers that are not part of the Tor network.
There are several ways to address the problem while maintaining the approach of
using hardcoded restrictions in the client code. The simplest solution is to
just have a new configuration parameter that allows the attachment of streams
to one-hop circuits. An objection to that approach might be that the abusive
controllers will simply set the configuration paramter and carry on. Another
solution is to require that we can only exit from one-hop circuits if the
(single) router in the circuit has a descriptor whose associated purpose is not
general. Again, controllers can set purposes on descriptors, or feed the Tor
descriptors via POSTDESCRIPTOR, so controllers could still be abusive, but the
overhead would be somewhat greater.
A third solution is to require descriptors to have a special option that
indicates to the client that they can be used in one-hop circuits, and have
clients object, as they do now for all routers, to attaching streams to one-hop
circuits for routers that do not have this option set. That solution seems to
eliminate the worry about operational router security, since server operators
will not set this bit unless they are willing to take on such risk. If we
worry about the impact on anonymity of the network resulting from including
such "risky" routers in regular Tor path selection, we can just systematically
exclude those.
Tactically, we should do something to allow Blossom to say "yes, I really do
mean to use this one-hop circuit." What is the right way to achieve this in
the short-term?
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/771TLS no-compression is distinguishable?2020-06-27T14:10:14ZRoger DingledineTLS no-compression is distinguishable?We turned off TLS compression in Tor 0.2.1.1-alpha:
- Never use OpenSSL compression: it wastes RAM and CPU trying to
compress cells, which are basically all encrypted, compressed,
or both.
but it would appear that this is...We turned off TLS compression in Tor 0.2.1.1-alpha:
- Never use OpenSSL compression: it wastes RAM and CPU trying to
compress cells, which are basically all encrypted, compressed,
or both.
but it would appear that this isn't what Firefox and Apache do. How
noticeable is this?
See also http://archives.seul.org/or/talk/Jun-2008/msg00188.html
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/775tor crash on libevent error2020-06-27T14:10:14ZTractor crash on libevent errorJul 15 03:44:56.239 [notice] Tor 0.2.0.28-rc (r15188) opening new log file.
...
Jul 15 18:53:24.691 [err] Error from libevent: event_queue_remove: 0x9c331c38(fd 0) not on queue 1
...
Jul 17 11:58:35.282 [notice] Tor 0.2.1.2-alpha (r15383...Jul 15 03:44:56.239 [notice] Tor 0.2.0.28-rc (r15188) opening new log file.
...
Jul 15 18:53:24.691 [err] Error from libevent: event_queue_remove: 0x9c331c38(fd 0) not on queue 1
...
Jul 17 11:58:35.282 [notice] Tor 0.2.1.2-alpha (r15383) opening log file.
...
Jul 17 23:33:22.515 [err] Error from libevent: event_queue_remove: 0xb2797c38(fd 0) not on queue 1
Hello,
since the last two days i've the same error on mxr running on a debian hardy with all standard scripts.
I've no change in the config since some days.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: amishttps://gitlab.torproject.org/tpo/core/tor/-/issues/779Don't cross the exit streams!2020-06-27T14:10:14ZRoger DingledineDon't cross the exit streams!slush reports in
http://archives.seul.org/or/talk/Jul-2008/msg00061.html
that when he makes 300 circuits in a quick amount of time, then
refreshes his page, he gets a page with some content from a different
stream in it. See e.g. http:/...slush reports in
http://archives.seul.org/or/talk/Jul-2008/msg00061.html
that when he makes 300 circuits in a quick amount of time, then
refreshes his page, he gets a page with some content from a different
stream in it. See e.g. http://www.slush.cz/centrumyahoo.png for an
example.
Jens has independently reported this too.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/781segfault in libz2020-06-27T14:10:14ZTracsegfault in libzI'm using Version: 0.2.0.30-2~~etch+1 from http://mirror.noreply.org/pub/tor
Jul 20 22:30:39 magnesium Tor[31470]: Your Tor server's identity key fingerprint is 'nirgal 05F2 1249 3535 17EB 6205 0CF3 B309 7392 3F61 5B1C'
Jul 20 22:30:51 ...I'm using Version: 0.2.0.30-2~~etch+1 from http://mirror.noreply.org/pub/tor
Jul 20 22:30:39 magnesium Tor[31470]: Your Tor server's identity key fingerprint is 'nirgal 05F2 1249 3535 17EB 6205 0CF3 B309 7392 3F61 5B1C'
Jul 20 22:30:51 magnesium Tor[31470]: We now have enough directory information to build circuits.
Jul 20 22:30:51 magnesium Tor[31470]: Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 20 22:30:53 magnesium Tor[31470]: Tor has successfully opened a circuit. Looks like client functionality is working.
Jul 20 22:31:58 magnesium Tor[31470]: Performing bandwidth self-test...done.
Jul 20 22:32:23 magnesium Tor[31470]: Self-testing indicates your DirPort is reachable from the outside. Excellent.
Jul 23 07:11:00 magnesium kernel: [722001.420438] tor[31470]: segfault at 9ac7669c ip b7f9988e sp bf9c4850 error 4 in libz.so.1.2.3[b7f94000+13000]
I'm not sure that repport helps a lot...
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: nirgalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/782Patch: Open /dev/pf before dropping privileges with TransPort2020-06-27T14:10:14ZTracPatch: Open /dev/pf before dropping privileges with TransPortCurrently, when using TransPort and OpenBSD pf, Tor opens /dev/pf
after dropping privileges, so the permissions on /dev/pf must be
modified to allow access to the unprivileged Tor user.
The patch should ensure that /dev/pf is opened w...Currently, when using TransPort and OpenBSD pf, Tor opens /dev/pf
after dropping privileges, so the permissions on /dev/pf must be
modified to allow access to the unprivileged Tor user.
The patch should ensure that /dev/pf is opened while Tor is still
running as root.
Note: diff is to trunk
Index: src/or/config.c
===================================================================
--- src/or/config.c (revision 16230)
+++ src/or/config.c (working copy)
@@ -1060,6 +1060,16 @@
}
}
+#if defined(HAVE_NET_IF_H) && defined(HAVE_NET_PFVAR_H)
+ /* Open /dev/pf before dropping privileges. */
+ if (options->TransPort) {
+ if (get_pf_socket() < 0) {
+ *msg = tor_strdup("Unable to open /dev/pf for transparent proxy.");
+ goto rollback;
+ }
+ }
+#endif
+
/* Setuid/setgid as appropriate */
if (options->User || options->Group) {
/* XXXX021 We should only do this the first time through, not on
Index: src/or/connection_edge.c
===================================================================
--- src/or/connection_edge.c (revision 16230)
+++ src/or/connection_edge.c (working copy)
@@ -1641,8 +1641,7 @@
#ifdef TRANS_PF
static int pf_socket = -1;
-static int
-get_pf_socket(void)
+int get_pf_socket(void)
{
int pf;
/* Ideally, this should be opened before dropping privs. */
Index: src/or/or.h
===================================================================
--- src/or/or.h (revision 16230)
+++ src/or/or.h (working copy)
@@ -2939,6 +2939,10 @@
} hostname_type_t;
hostname_type_t parse_extended_hostname(char *address);
+#if defined(HAVE_NET_IF_H) && defined(HAVE_NET_PFVAR_H)
+int get_pf_socket(void);
+#endif
+
/********************************* connection_or.c ***************************/
void connection_or_remove_from_identity_map(or_connection_t *conn);
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: loafierNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/783contact2020-06-27T14:10:14ZTraccontactAm trying to act as a relay to help Tor. Relay button doesn't work. High speed microwave ISP with 0 latency
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: mhetheringtonAm trying to act as a relay to help Tor. Relay button doesn't work. High speed microwave ISP with 0 latency
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: mhetheringtonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/784unclear error message: crash state conflict2020-06-27T14:10:13ZTracunclear error message: crash state conflictThis concerns the tor button, sorry to file this report under tor client.
After some weird firefox behaviour (couldn't switch tabs anymore) i closed and reopened firefox which led to the following error message:
Crash state conflict! ...This concerns the tor button, sorry to file this report under tor client.
After some weird firefox behaviour (couldn't switch tabs anymore) i closed and reopened firefox which led to the following error message:
Crash state conflict! Please file bug report with these four values: false,false,false,true
It is obvious to me that i don't get to make any decissions here because i'm not part of this project, but the source of this error message was really hard to track down, it didn't mention at all that it was produced by the tor button.
I really wish this gets immediate fixing, because it makes firefox look unstable when it is acutally a tor button error.
(i only found out this is produced by the tor button because of a google search http://www.google.at/search?q=%22Crash+state+conflict!)
all the best,
hansi.
p.s. nevertheless... great work on tor!
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: kritzikratzihttps://gitlab.torproject.org/tpo/core/tor/-/issues/789Improperly bound listen addresses2020-06-27T14:10:13ZgrarpampImproperly bound listen addressesHi. I have various alias addressing on my interfaces. I mapped
everything to rfc1918 space for this note.
fxp0:
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
inet 10.0.0.2 netmask 0xffffffff broadcast 10.0.0.2
I fire up a sta...Hi. I have various alias addressing on my interfaces. I mapped
everything to rfc1918 space for this note.
fxp0:
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
inet 10.0.0.2 netmask 0xffffffff broadcast 10.0.0.2
I fire up a statically compiled tor in a chroot populated with the
minimum required to keep tor quiet:
/etc/resolv.conf
/dev/urandom
I exec tor while already under a dedicated non-root user/group.
I use the following addressing options:
-socksport 9050 -sockslistenaddress 127.0.0.1
-controlport 9051 -controllistenaddress 127.0.0.1
-orport 9001 -orlistenaddress 10.0.0.2
-dirport 9030 -dirlistenaddress 10.0.0.2
Note that my packet filters have proper holes for Tor.
========================================
As you can see, the OR and DIR binds honor the requested use of the
secondary address. Yet the udp and outbound connections bind to the
primary address on the interface.
# before outboundbindaddress
tor tor 55099 4 tcp4 10.0.0.2:9001 *:*
tor tor 55099 5 tcp4 10.0.0.2:9030 *:*
tor tor 55099 6 tcp4 127.0.0.1:9050 *:*
tor tor 55099 7 tcp4 127.0.0.1:9051 *:*
tor tor 55099 8 tcp4 10.0.0.1:1854 86.59.21.38:443
tor tor 55099 12 tcp4 10.0.0.1:1856 128.31.0.34:9001
tor tor 55099 9 udp4 10.0.0.1:3093 w.x.y.z:53
tor tor 55099 11 stream tor[55103]:12
tor tor 55103 9 udp4 10.0.0.1:3093 w.x.y.z:53
tor tor 55103 12 stream tor[55099]:11
So I added this to the config:
-outboundbindaddress 10.0.0.2
Now you can see that this was indeed honored as well. And we are
now left with only the udp binds to deal with. However, I can see
no configuration option to do that.
So that is missing feature #1.
# after outboundbindaddress
tor tor 82854 4 tcp4 10.0.0.2:9001 *:*
tor tor 82854 5 tcp4 10.0.0.2:9030 *:*
tor tor 82854 6 tcp4 127.0.0.1:9050 *:*
tor tor 82854 7 tcp4 127.0.0.1:9051 *:*
tor tor 82854 8 tcp4 10.0.0.2:2601 86.59.21.38:443
tor tor 82854 12 tcp4 10.0.0.2:3605 91.143.80.22:9001
tor tor 82854 9 udp4 10.0.0.1:2228 w.x.y.z:53
tor tor 82854 11 stream tor[82856]:12
tor tor 82856 9 udp4 10.0.0.1:2228 w.x.y.z:53
tor tor 82856 12 stream tor[82854]:11
========================================
Now note that _both_before_and_after_ outboundbindaddress, Tor seems
to be confused regarding its socket allocation as noted below.
Therefore it never publishes its descriptor and I have 384kbits
still sitting useless :-) :-(
So that is bug legacy/trac#2.
[n] Tor v0.2.0.30 (r15956) ... (FreeBSD i386)
[n] Configuration file "/.../etc/tor/torrc" not present, using
reasonable defaults.
[n] Opening OR listener on 10.0.0.2:9001
[n] Opening Directory listener on 10.0.0.2:9030
[n] Opening Socks listener on 127.0.0.1:9050
[n] Opening Control listener on 127.0.0.1:9051
[n] Now checking whether ORPort 10.0.0.1:9001 and DirPort
10.0.0.1:9030 are reachable... (this may take up to 20 minutes
-- look for log messages indicating success)
[w] Your server (10.0.0.1:9001) has not managed to confirm
that its ORPort is reachable. Please check your firewalls, ports,
address, /etc/hosts file, etc.
[w] Your server (10.0.0.1:9030) has not managed to confirm
that its DirPort is reachable. Please check your firewalls, ports,
address, /etc/hosts file, etc.
========================================
Lastly, I think the pairing of:
-<Whatever_function>Port Port
-<Whatever_function>ListenAddress IP[:PORT]
is a bit klunky. In that the pure Port statement is required to
enable the function. But if you also want to bind it somewhere
deterministic you _also_ have to specify the Address IP. And some
functions may be useful to bind more than once in the future. So I
would perhaps see about moving to this style instead:
-<Whatever_function>ListenAddress "{IP|*|#}[:PORT]"
Where '*' means bind to all addresses. And perhaps '#' might refer
to however the current pure Port statement picks its addresses
currently.
========================================
> If you're a relay, tor will attempt to do name resolution for
> clients, perhaps this is what you're seeing.
Yes. And it should have the facility to bind to whatever address I
tell it to use for that purpose. Not the primary address on any
given interface, the '*' address, etc. Tor already has facilities
for its OR and DIR 'listeners' and the 'outboundbindaddress'. It
needs one one for DNS resolution as well. I don't want it using .1
for that. Create a -dnssrcport and -dnsbindaddress. -dnssrcport
should allow >=1024 for non-root and anything for root, particularly
53.
Note that Tor still performs some tor related DNS queries even if
it is: 'reject *:*'. Otherwise there would be no need to bind udp
in that case.
>> [w] Your server (10.0.0.1:9001) has not managed to confirm
> Because tor can't confirm 10.0.0.1 is a valid non-rfc1918 address.
No. As with w.x.y.z:53, I have protected the innocent for this note.
In your mind, do the reverse and replace every instance of 10.0.0.0/24
above with one publicy routed /24 cidr block while preserving the
last octet. Then it is clear that something is wrong. I have bound
OR, DIR and the 'outboundbindaddress' to .2. It thinks otherwise.
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/792libevent "error" causes Tor not to start at all2020-06-27T14:10:13ZTraclibevent "error" causes Tor not to start at allThis is only tested on Windows Vista with Service Pack 1 and all updates except Windows Search 4.0
Tor 0.2.0.30 stable version was released officially a few days ago, but upon upgrading or uninstalling/reinstalling, the following messag...This is only tested on Windows Vista with Service Pack 1 and all updates except Windows Search 4.0
Tor 0.2.0.30 stable version was released officially a few days ago, but upon upgrading or uninstalling/reinstalling, the following messages always showed up 100% of the time.
Aug 03 19:44:21.798 [Notice] Tor v0.2.0.30 (r15956). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows "Longhorn" Service Pack 1 [workstation] {terminal services, single user})
Aug 03 19:44:21.936 [Error] Error from libevent: evsignal_init: socketpair: No error
First of all this should not be experimental software since it is a stable release, and how come I am unable to start Tor especially when the "error" is actually "No error"?
[Automatically added by flyspray2trac: Operating System: Windows Vista]
**Trac**:
**Username**: coshanTor: 0.2.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/794Another minor leak2020-06-27T14:10:13ZRoger DingledineAnother minor leakrovv> arma: please, look at http://rafb.net/p/ldxDw235.html (sequel of
r16302)
--- mempool.original.c Tue Feb 26 18:56:28 2008
+++ mempool.c Sun Aug 3 13:50:26 2008
@@ -144,7 +144,7 @@
};
/** Number of extra bytes needed beyond mem...rovv> arma: please, look at http://rafb.net/p/ldxDw235.html (sequel of
r16302)
--- mempool.original.c Tue Feb 26 18:56:28 2008
+++ mempool.c Sun Aug 3 13:50:26 2008
@@ -144,7 +144,7 @@
};
/** Number of extra bytes needed beyond mem_size to allocate a chunk. */
-#define CHUNK_OVERHEAD (sizeof(mp_chunk_t)-1)
+#define CHUNK_OVERHEAD STRUCT_OFFSET(mp_chunk_t, mem[0])
/** Given a pointer to a mp_allocated_t, return a pointer to the memory
* item it holds. */
rovv: exciting. is this an active bug, meaning it's a problem for somebody,
or is this more preventative?
rovv> 3 byte per 128KB chunk. I don't think that is a problem, but
> of wasted space?
rovv> yes for x86
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/797FastFirstHopPK 0 prevents tunneled directory connections from working.2020-06-27T14:10:13ZNick MathewsonFastFirstHopPK 0 prevents tunneled directory connections from working.See Erwin Lam's email from 3 August 2008 on or-talk:
http://archives.seul.org/or/talk/Aug-2008/msg00010.html
It seems that in some cases we build a one-hop circuit to a server without putting its onion key in the
extend_info. This h...See Erwin Lam's email from 3 August 2008 on or-talk:
http://archives.seul.org/or/talk/Aug-2008/msg00010.html
It seems that in some cases we build a one-hop circuit to a server without putting its onion key in the
extend_info. This happens _at least_ when we don't know any onion key for the server, because we are
connecting to it for directory information and we don't have any descriptors yet.
You can test this yourself: run with -FastFirstHopPK 0, with a new empty datadirectory (to avoid cached data),
and with no other options set.
The right fix is probably to override should_use_create_fast_for_router so that it uses a create_fast cell
for one-hop tunnels when no onion key is known, even if FastFirstHopPK 0 is set.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/799Aug 12 16:37:07.937 [Fehler] Error from libevent: evsignal_init: socketpair: ...2020-06-27T14:10:13ZTracAug 12 16:37:07.937 [Fehler] Error from libevent: evsignal_init: socketpair: No errorVidalia can not start TOR.
See report.
Aug 12 16:37:07.937 [Fehler] Error from libevent: evsignal_init: socketpair: No error
How can I sart TOR?
Thanks for soloutiones.
[Automatically added by flyspray2trac: Operating System: Window...Vidalia can not start TOR.
See report.
Aug 12 16:37:07.937 [Fehler] Error from libevent: evsignal_init: socketpair: No error
How can I sart TOR?
Thanks for soloutiones.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: leMaximumhttps://gitlab.torproject.org/tpo/core/tor/-/issues/802BandwidthBurst rate being used constantly2020-06-27T14:10:12Zmicahmicah@torproject.orgBandwidthBurst rate being used constantlyI have three machines, all configured exactly the same way acting as round-robin web servers. They get an even distribution
of traffic, averaging 50kbps in and 200kbps out and have had an even distribution amongst the nodes for a year an...I have three machines, all configured exactly the same way acting as round-robin web servers. They get an even distribution
of traffic, averaging 50kbps in and 200kbps out and have had an even distribution amongst the nodes for a year and a half.
I installed tor on one of the nodes to test an exit enclave setup, with the idea that if it worked well, I would deploy it
to the other nodes (as well as elsewhere). I used the following configuration:
SocksPort 0 # what port to open for local application connections
SocksListenAddress 127.0.0.1 # accept connections only from localhost
Log notice syslog
RunAsDaemon 1
DataDirectory /var/lib/tor
Nickname auk
Address my.ip.here
OutboundBindAddress my.ip.here
ContactInfo my.contact.info.here
ORPort 9001
ExitPolicyRejectPrivate 0
ExitPolicy accept my.ip.here:80
ExitPolicy accept my.ip.here:443
ExitPolicy reject *:*
BandwidthRate 250 KB
BandwidthBurst 1MB
As you can see, I set BandwidthBurst to 1MB, and BadwidthRate to be 250KB, but looking at my bandwidth usage
statistics, I see that this node is using 1MB the entire time, averaging 872kbps in and 1.03M out (almost always at
this rate, with some fluctuations up to 2.35M in and 2.71M out.
This doesn't seem like what I would expect for these bandwidth settings, I could be misunderstanding how these
are applied, and if so please tell me what I am missing.
Thanks for your work on tor, its appreciated!
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/803assert in routerstatus_format_entry()2020-06-27T14:10:12ZRoger Dingledineassert in routerstatus_format_entry()r16563.
Aug 16 18:42:00.186 [] Downloading consensus from 82.94.251.204:443 using /tor/s
tatus-vote/current/consensus/14C131+27B6B5+585769+81349F+E2A2AF+E8A9C4.z
Aug 16 19:33:57.203 [] routerstatus_format_entry(): Bug: Cannot get the de...r16563.
Aug 16 18:42:00.186 [] Downloading consensus from 82.94.251.204:443 using /tor/s
tatus-vote/current/consensus/14C131+27B6B5+585769+81349F+E2A2AF+E8A9C4.z
Aug 16 19:33:57.203 [] routerstatus_format_entry(): Bug: Cannot get the descript
or with digest 009CF1422D2244E918B4530A673871D46009B752 for 5193811E81189B705618
C7DB16BE3B48170C2800.
Aug 16 19:33:57.208 [] routerstatus_format_entry(): Bug: descriptor digest in ro
uterlist does not match the one in routerstatus: 33503E7B5447030D4289F465F2BD0A0
44781B34E vs 78DB41D7DAA1B80572FB422E789FBDBCEF456C68
Aug 16 19:33:57.212 [] Bug: dirserv.c:1966: routerstatus_format_entry: Assertion
!memcmp(desc->cache_info.signed_descriptor_digest, rs->descriptor_digest, DIGES
T_LEN) failed; aborting.
#0 0xb7fd1410 in ?? ()
#1 0xbfe9327c in ?? ()
legacy/trac#2 0x00000006 in ?? ()
legacy/trac#3 0x00001144 in ?? ()
legacy/trac#4 0xb7d01811 in raise () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#5 0xb7d02fb9 in abort () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#6 0x08093bd4 in routerstatus_format_entry (
buf=0xbfe93541 "r agate ATQMjN9ekLnU/xrr3KQDzS/25WI eNtB19qhuAVy+0IueJ+9vO9FbGg 2008-08-16 20:14:41 193.202.115.224 9001 0\ns Running Unnamed Valid\n",
buf_len=1379, rs=0x88f9918, version=0x0, first_line_only=0, v2_format=0)
at dirserv.c:1964
legacy/trac#7 0x080ab8da in networkstatus_getinfo_helper_single (rs=0x88f9918)
at networkstatus.c:1782
legacy/trac#8 0x080ad1e7 in getinfo_helper_networkstatus (conn=0x8663de0,
question=0x8170880 "ns/all", answer=0xbfe93be0) at networkstatus.c:1862
legacy/trac#9 0x08086535 in connection_control_process_inbuf (conn=0x8663de0)
at control.c:1976
legacy/trac#10 0x08070c68 in connection_process_inbuf (conn=0x8663de0, package_partial=6)
at connection.c:2733
legacy/trac#11 0x080729b1 in connection_handle_read (conn=0x8663de0) at connection.c:1931
legacy/trac#12 0x080ab5c8 in conn_read_callback (fd=10, event=2, _conn=0x8663de0)
at main.c:458
legacy/trac#13 0xb7f9cc79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#14 0xb7f9cf65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#15 0xb7f9cdcb in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#16 0x080ab10f in do_main_loop () at main.c:1459
legacy/trac#17 0x080ab2e5 in tor_main (argc=11, argv=0xbfe93e64) at main.c:2025
legacy/trac#18 0x080e5b92 in main (argc=Cannot access memory at address 0x1144
) at tor_main.c:29
legacy/trac#6 0x08093bd4 in routerstatus_format_entry (
buf=0xbfe93541 "r agate ATQMjN9ekLnU/xrr3KQDzS/25WI eNtB19qhuAVy+0IueJ+9vO9FbGg 2008-08-16 20:14:41 193.202.115.224 9001 0\ns Running Unnamed Valid\n",
buf_len=1379, rs=0x88f9918, version=0x0, first_line_only=0, v2_format=0)
at dirserv.c:1964
1964 tor_assert(!memcmp(desc->cache_info.signed_descriptor_digest,
(gdb) print *rs
$4 = {published_on = 1218917681, nickname = "agate", '\0' <repeats 14 times>,
identity_digest = "\0014\f\214ß!^\220¹Ôÿ\032ëܤ\003Í/öåb",
descriptor_digest = "xÛA×Ú¡¸\005rûB.x\237½¼ïElh", addr = 3251270624,
or_port = 9001, dir_port = 0, is_authority = 0, is_exit = 0, is_stable = 0,
is_fast = 0, is_running = 1, is_named = 0, is_unnamed = 1, is_valid = 1,
is_v2_dir = 0, is_possible_guard = 0, is_bad_exit = 0, is_bad_directory = 0,
is_hs_dir = 0, version_known = 1, version_supports_begindir = 1,
version_supports_conditional_consensus = 0,
version_supports_extrainfo_upload = 1, version_supports_v3_dir = 1,
has_bandwidth = 0, has_exitsummary = 0, bandwidth = 0, exitsummary = 0x0,
need_to_mirror = 0, name_lookup_warned = 0, last_dir_503_at = 0,
dl_status = {next_attempt_at = 0, n_download_failures = 0 '\0',
schedule = DL_SCHED_GENERIC}}
(gdb) print desc
No symbol "desc" in current context.
(darn optimizer)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/804seg fault on r16563 v3 authority2020-06-27T14:10:12ZRoger Dingledineseg fault on r16563 v3 authoritymoria1 on Tor 0.2.1.4-alpha-dev (r16563)
Aug 16 20:55:01.039 [notice] Time to compute a consensus.
Aug 16 20:55:01.039 [info] networkstatus_compute_consensus(): Generating consens
us using method 3.
#0 0x00002b93dfb35580 in strlen () ...moria1 on Tor 0.2.1.4-alpha-dev (r16563)
Aug 16 20:55:01.039 [notice] Time to compute a consensus.
Aug 16 20:55:01.039 [info] networkstatus_compute_consensus(): Generating consens
us using method 3.
#0 0x00002b93dfb35580 in strlen () from /lib/libc.so.6
#1 0x00002b93dfb07560 in vfprintf () from /lib/libc.so.6
legacy/trac#2 0x00002b93dfb276fa in vsnprintf () from /lib/libc.so.6
legacy/trac#3 0x00000000004963e3 in tor_vsnprintf (
str=0x7fffcb8f1900 "p Bandwidth=6266160\n", size=4981567,
format=0x7fffcb8f0201 "3\v\002", args=0x5) at compat.c:340
legacy/trac#4 0x0000000000496481 in tor_snprintf (
str=0x2b9300002b93 <Address 0x2b9300002b93 out of bounds>, size=4981567,
format=0x7fffcb8f0201 "3\v\002") at compat.c:321
legacy/trac#5 0x000000000044dbf0 in networkstatus_compute_consensus (votes=0x16a4d00,
total_authorities=6, identity_key=0x62c0e0, signing_key=0x62bff0,
legacy_id_key_digest=0x0, legacy_signing_key=0x0) at dirvote.c:1049
legacy/trac#6 0x000000000044ec11 in dirvote_act (options=0x5faf00, now=1218934501)
at dirvote.c:1907
legacy/trac#7 0x0000000000459213 in second_elapsed_callback (fd=<value optimized out>,
event=<value optimized out>, args=<value optimized out>) at main.c:1067
legacy/trac#8 0x00002b93df3e90e2 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#9 0x00000000004599f8 in do_main_loop () at main.c:1459
legacy/trac#10 0x0000000000459b95 in tor_main (argc=3, argv=<value optimized out>)
at main.c:2025
legacy/trac#11 0x00002b93dfadf4ca in __libc_start_main () from /lib/libc.so.6
legacy/trac#12 0x0000000000406b0a in _start () at ../sysdeps/x86_64/elf/start.S:113
legacy/trac#3 0x00000000004963e3 in tor_vsnprintf (
str=0x7fffcb8f1900 "p Bandwidth=6266160\n", size=4981567,
format=0x7fffcb8f0201 "3\v\002", args=0x5) at compat.c:340
340 r = vsnprintf(str, size, format, args);
legacy/trac#5 0x000000000044dbf0 in networkstatus_compute_consensus (votes=0x16a4d00,
total_authorities=6, identity_key=0x62c0e0, signing_key=0x62bff0,
legacy_id_key_digest=0x0, legacy_signing_key=0x0) at dirvote.c:1049
1049 int r = tor_snprintf(buf, sizeof(buf), "p %s\n", rs_out.exitsummary);
(gdb) print buf
$7 = 6401584
(gdb) print sizeof(buf)
$8 = 4
(gdb) print rs_out
No symbol "rs_out" in current context.
(another victim of optimization i guess)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/805choice of the best OR connection2020-06-27T14:10:12ZTracchoice of the best OR connectionconnection_or_get_by_identity_digest() returns a correct best connection of type OR; at most cases.
(if no other problems with other parts of code)
But checks not generalize enough. As example:
Let Tor has two (or more) non-obsolete co...connection_or_get_by_identity_digest() returns a correct best connection of type OR; at most cases.
(if no other problems with other parts of code)
But checks not generalize enough. As example:
Let Tor has two (or more) non-obsolete connections with the same digest and one of them
is non-canonical and newest (self present at orconn_identity_map).
While other conditions the same, function returns those non-canonical connection
from orconn_identity_map even if oldest connections (also non-obsolete) is canonical.
This situation with several not marked for close non-obsolete connections
was hypothetical but it's happened.
here a version of fix
--- connection_or.original.c Sat Jul 26 22:36:20 2008
+++ connection_or.c Tue Aug 19 09:38:30 2008
@@ -480,6 +480,8 @@
continue; /* We never prefer obsolete over non-obsolete connections. */
if (
+ /* We prefer canonical connections: */
+ (!best->is_canonical && conn->is_canonical) ||
/* We prefer non-obsolete connections: */
(best->_base.or_is_obsolete && !conn->_base.or_is_obsolete) ||
/* If both have circuits we prefer the newer: */
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rovv0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/806error during build on ming322020-06-27T14:10:12ZAndrew Lewmanerror during build on ming32When compiling tor 0.2.0.30 in mingw:
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../common -I/usr/local/include -I/usr/local/ssl/include -I...When compiling tor 0.2.0.30 in mingw:
gcc -DHAVE_CONFIG_H -I. -I../.. -DSHARE_DATADIR="\"/usr/local/share\"" -DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\"" -I../common -I/usr/local/include -I/usr/local/ssl/include -I/usr/local/include -g -O2 -Wall -g -O2 -MT config.o -MD -MP -MF .deps/config.Tpo -c -o config.o config.c
config.c: In function `options_act':
config.c:1268: warning: initialization makes integer from pointer without a cast
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/807Stream status events for reverse resolve requests2020-06-27T14:10:12ZRobert HoganStream status events for reverse resolve requests(http://archives.seul.org/or/dev/Jul-2008/msg00017.html)
Stream status events for reverse resolve requests for which Tor has a cached
answer look like this:
650 STREAM 6 NEWRESOLVE 0 64.4.33.7:0
650 STREAM 6 FAILED 0 REVERSE[64.4.33.7...(http://archives.seul.org/or/dev/Jul-2008/msg00017.html)
Stream status events for reverse resolve requests for which Tor has a cached
answer look like this:
650 STREAM 6 NEWRESOLVE 0 64.4.33.7:0
650 STREAM 6 FAILED 0 REVERSE[64.4.33.7]:0
650 STREAM 7 NEWRESOLVE 0 64.4.33.7:0
650 STREAM 7 FAILED 0 REVERSE[64.4.33.7]:0
The stream 'fails' because there is never a need to create it. The spec is a bit
unclear on this point but I think all streams deserve a CLOSE event. Or
is 'FAILED' considered sufficient?
I can allow a CLOSE event by doing:
Index: src/or/connection_edge.c
===================================================================
--- src/or/connection_edge.c (revision 15824)
+++ src/or/connection_edge.c (working copy)
@@ -1369,8 +1369,7 @@
map_expires);
connection_mark_unattached_ap(conn,
END_STREAM_REASON_DONE |
- END_STREAM_REASON_FLAG_ALREADY_SOCKS_REPLIED |
- END_STREAM_REASON_FLAG_ALREADY_SENT_CLOSED);
+ END_STREAM_REASON_FLAG_ALREADY_SOCKS_REPLIED);
return 0;
}
if (options->ClientDNSRejectInternalAddresses) {
but maybe it's the spec that needs to be clarified. A short note stating which
events should be expected for all streams maybe.
See also:
http://archives.seul.org/or/dev/Jul-2008/msg00033.html
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/809Tor 0.2.1.5-alpha rejects valid bridge addresses2020-06-27T14:10:11ZedmanmTor 0.2.1.5-alpha rejects valid bridge addressesTor 0.2.1.5-alpha rejects what appear to be properly formatted bridge addresses. For example, placing
the following line in my torrc:
bridge 128.31.0.34:9009 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
results in the following ...Tor 0.2.1.5-alpha rejects what appear to be properly formatted bridge addresses. For example, placing
the following line in my torrc:
bridge 128.31.0.34:9009 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
results in the following error:
Sep 04 15:47:35.887 [warn] Missing port in Bridge address '128.31.0.34:9009'
even though a port is indeed specified.
[I selected 0.2.1.4-alpha for the "Reported Version", because 0.2.1.5-alpha is not currently in the list.]
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/811can't open/start tor due to a bug2020-06-27T14:10:11ZTraccan't open/start tor due to a bugi can't open or start tor due to a bug. (Please note both od the bugs listed) I recently installed tor and can't seem to figure out why it says this:
Sep 06 19:04:09.948 [Notice] Tor v0.2.1.5-alpha (r16710). This is experimental software...i can't open or start tor due to a bug. (Please note both od the bugs listed) I recently installed tor and can't seem to figure out why it says this:
Sep 06 19:04:09.948 [Notice] Tor v0.2.1.5-alpha (r16710). This is experimental software. Do not rely on it for strong anonymity. (Running on Darwin Power Macintosh)
Sep 06 19:04:09.963 [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.
Sep 06 19:04:09.964 [Notice] Initialized libevent version 1.4.7-stable using method kqueue. Good.
Sep 06 19:04:09.965 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 06 19:04:09.966 [Notice] Opening Directory listener on 0.0.0.0:9030
Sep 06 19:04:09.967 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 06 19:04:09.967 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 06 19:04:11.640 [Notice] Your Tor server's identity key fingerprint is 'Unnamed E0FD F8F7 6A06 4AF1 3B2A CAD7 C323 CB8D 1FC2 1468'
Sep 06 19:04:11.648 [Error] Bug: policies.c:1230: addr_policy_free: Assertion p == found->policy failed; aborting.
Sep 06 22:35:36.885 [Notice] Tor v0.2.1.5-alpha (r16710). This is experimental software. Do not rely on it for strong anonymity. (Running on Darwin Power Macintosh)
Sep 06 22:35:36.891 [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.
Sep 06 22:35:36.892 [Notice] Initialized libevent version 1.4.7-stable using method kqueue. Good.
Sep 06 22:35:36.893 [Notice] Opening OR listener on 0.0.0.0:9001
Sep 06 22:35:36.894 [Notice] Opening Directory listener on 0.0.0.0:9030
Sep 06 22:35:36.895 [Notice] Opening Socks listener on 127.0.0.1:9050
Sep 06 22:35:36.896 [Notice] Opening Control listener on 127.0.0.1:9051
Sep 06 22:35:38.614 [Notice] Your Tor server's identity key fingerprint is 'Unnamed E0FD F8F7 6A06 4AF1 3B2A CAD7 C323 CB8D 1FC2 1468'
Sep 06 22:35:38.616 [Error] Bug: policies.c:1230: addr_policy_free: Assertion p == found->policy failed; aborting.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: ecoteahttps://gitlab.torproject.org/tpo/core/tor/-/issues/813Tor is unable to find my DNS and exits on startup2020-06-27T14:10:11ZTracTor is unable to find my DNS and exits on startupVersion 2.1.5 is unable to start on my german WinXP SP3. The log looks this way:
Sep 08 21:28:44.411 [Hinweis] Tor v0.2.1.5-alpha (r16710). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Se...Version 2.1.5 is unable to start on my german WinXP SP3. The log looks this way:
Sep 08 21:28:44.411 [Hinweis] Tor v0.2.1.5-alpha (r16710). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 3 [workstation] {terminal services, single user})
Sep 08 21:28:44.411 [Warnung] You have requested constrained socket buffers while also serving directory entries via DirPort. It is strongly suggested that you disable serving directory requests when system TCP buffer resources are scarce.
Sep 08 21:28:44.411 [Hinweis] Initialized libevent version 1.4.7-stable using method win32. Good.
Sep 08 21:28:44.411 [Hinweis] Opening OR listener on 0.0.0.0:443
Sep 08 21:28:44.411 [Hinweis] Opening Directory listener on 0.0.0.0:80
Sep 08 21:28:44.411 [Hinweis] Opening Socks listener on 127.0.0.1:9050
Sep 08 21:28:44.411 [Hinweis] Opening Control listener on 127.0.0.1:9051
Sep 08 21:28:44.645 [Warnung] eventdns: Didn't find any nameservers.
Sep 08 21:28:44.645 [Warnung] Could not config nameservers.
Sep 08 21:28:44.645 [Fehler] Error initializing dns subsystem; exiting
Version 2.1.4 (or earlier) do start up normally. As far as I can see there is no other
programm that has any issues with my DNS, everything works fine.
I will upload the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip
from my registry shortly.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: knappo0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/814Fetching v0 and v2 rendezvous descriptors in parallel sometimes fails2020-06-27T14:10:11ZKarsten LoesingFetching v0 and v2 rendezvous descriptors in parallel sometimes failsThe logic to download v0 and v2 rendezvous descriptors in parallel does not
work correctly. If the v0 request returns first and unsuccessfully, the
hidden service connection is closed with the statement "[notice] Closing
stream for '[......The logic to download v0 and v2 rendezvous descriptors in parallel does not
work correctly. If the v0 request returns first and unsuccessfully, the
hidden service connection is closed with the statement "[notice] Closing
stream for '[...].onion': hidden service is unavailable (try again later)."
A subsequent successful result of a v2 request cannot be processed
correctly; while the descriptor is stored for later use, it cannot be used
for the requesting connection any more.
This is a minor problem, since hidden services that only publish v2
descriptors are still rare (unless people perform tests with them).
Patch follows.
[Automatically added by flyspray2trac: Operating System: All]Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/core/tor/-/issues/816Tor server endlessly hibernates2020-06-27T14:10:11ZAndrew LewmanTor server endlessly hibernates0.2.1.5-alpha compiled from source on 64bit redhat4. torrc options set for bandwidth are:
AccountingMax 900GB
AccountingStart month 19 00:00
On start up, tor states:
"Configured hibernation. This interval began at 2008-08-19 00:00:00...0.2.1.5-alpha compiled from source on 64bit redhat4. torrc options set for bandwidth are:
AccountingMax 900GB
AccountingStart month 19 00:00
On start up, tor states:
"Configured hibernation. This interval began at 2008-08-19 00:00:00; the scheduled wake-up time was
2008-08-19 00:00:00; we expect to exhaust our quota for this interval around 2008-09-19 00:00:00;
the next interval begins at 2008-09-19 00:00:00 (all times local)"
Watching traffic from my node, which before was easily 2-3 mb/s, is now nearly zero. IIRC, 0.2.1.2-alpha ran correctly
and consumed all 900GB in the time interval.
My state file is:
# How many bytes have we read in this accounting period?
AccountingBytesReadInInterval 65724230656
# How many bytes have we written in this accounting period?
AccountingBytesWrittenInInterval 66265904128
# How many bytes did we expect to use per minute? (0 for no estimate.)
AccountingExpectedUsage 2083252
# When did this accounting period begin?
AccountingIntervalStart 2008-08-19 05:00:00
# How long have we been awake in this period?
AccountingSecondsActive 1983625
# When does the last-recorded read-interval end?
BWHistoryReadEnds 2008-09-11 04:15:41
# When does the last-recorded write-interval end?
BWHistoryWriteEnds 2008-09-11 04:15:41
[Automatically added by flyspray2trac: Operating System: Redhat/CentOS Linux]post 0.2.1.xhttps://gitlab.torproject.org/tpo/core/tor/-/issues/820Tor left in broken state on startup2020-06-27T14:10:11ZseeessTor left in broken state on startupSep 21 20:05:21.660 [notice] Tor 0.2.1.5-alpha (r16710) opening log file.
Sep 21 20:05:21.661 [warn] /var/lib/tor/cached-status is not owned by this user (root, 0) but by username (1001). Perhaps you are running Tor as the wrong user?
Se...Sep 21 20:05:21.660 [notice] Tor 0.2.1.5-alpha (r16710) opening log file.
Sep 21 20:05:21.661 [warn] /var/lib/tor/cached-status is not owned by this user (root, 0) but by username (1001). Perhaps you are running Tor as the wrong user?
Sep 21 20:05:21.661 [warn] Couldn't access/create private data directory "/var/lib/tor/cached-status"
Sep 21 20:05:21.661 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying.
The directory initially wasnt owned by the correct user and it complained in system.out/err correctly so i could fix it,
but i forgot everything under it had the wrong perms too. But when i tried to start it the second time it just failed to launch
without anything significant printed out in system.out/err. I had to check the log for the above msg
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/823r16621 introduced random stream detaching2020-06-27T14:10:10ZTracr16621 introduced random stream detachingWhen I use a relay of mine running a version later than r16621 as an exit to, for
example, http://upload.wikimedia.org/wikipedia/commons/7/79/Yellowjacket_nest_1_sjh.JPG
then the first few (between 3 and 100) times I try, the stream get...When I use a relay of mine running a version later than r16621 as an exit to, for
example, http://upload.wikimedia.org/wikipedia/commons/7/79/Yellowjacket_nest_1_sjh.JPG
then the first few (between 3 and 100) times I try, the stream gets DETACHED with reason=END and
remote_reason=unknown. Re-attaching the stream to another circuit works fine, and then
the stream succeeds. If I keep trying the same address through my relay a bunch of times,
it eventually succeeds. However, restarting my CLIENT Tor program (which I'm using to
test this, ie, not the relay), and trying again at the same address causes the same problem.
I narrowed down the problem to this block in eventdns.c:
/* we only bother with the first four addresses. */
if (j + 4*addrtocopy > length) goto err;
//if (name_matches) {
memcpy(&reply.data.a.addresses[reply.data.a.addrcount],
packet + j, 4*addrtocopy);
reply.data.a.addrcount += addrtocopy;
reply.have_answer = 1;
if (reply.data.a.addrcount == MAX_ADDRS) break;
//}
j += 4*addrtocopy;
Note that the // comments were added by me, and they actually fix this problem
(ie, the stream never detaches if those //'s are present, but the problem DOES
happen when they are NOT present). However, I dont understand this code at all,
so I figured I'd submit a bug report with what I've figured out so far, and see
what you guys think.
I printed out the names right after the assignment of name_matches in that function,
and the print statement was run twice for a single stream attach try. This is what
my tor log (level=debug) looked like:
launch_resolve(): Launching eventdns request for [scrubbed]
eventdns: Resolve requested.
eventdns: Setting timeout for request 3afe38
eventdns: req->name = upload.wikimedia.org and tmp_name = upload.wikimedia.org
eventdns: req->name = upload.wikimedia.org and tmp_name = upload.pmtpa.wikimedia.org
eventdns: Removing timeout for request 3afe38
Note that I'm running windows XP, compiling from source, and in case it matters,
my DNS server is 192.168.1.1, which is my router running DD-WRT
Hope this helps!
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: TheJashNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/824More accurate calculation of bandwith limits in past.2020-06-27T14:10:10ZTracMore accurate calculation of bandwith limits in past.
Buckets decrements with raw bytes for OR connection which more than
real bytes. So global write bucket can and do run dry with negative
numbers, if Tor transmit cells.
Fix can repair possibly issue with DoS against relay with DirPort
...
Buckets decrements with raw bytes for OR connection which more than
real bytes. So global write bucket can and do run dry with negative
numbers, if Tor transmit cells.
Fix can repair possibly issue with DoS against relay with DirPort
reported by Scott Bennett on or-talk some time ago
(december '07 and later).
--- connection.original.c Mon Sep 8 13:10:16 2008
+++ connection.c Thu Sep 25 20:44:40 2008
@@ -1718,7 +1718,7 @@
tor_assert(seconds_elapsed >= 0);
write_buckets_empty_last_second =
- global_relayed_write_bucket == 0 || global_write_bucket == 0;
+ global_relayed_write_bucket <= 0 || global_write_bucket <= 0;
/* refill the global buckets */
connection_bucket_refill_helper(&global_read_bucket,
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rovvhttps://gitlab.torproject.org/tpo/core/tor/-/issues/826tor-resolve can't adapt to SocksPort change2020-06-27T14:10:10ZTractor-resolve can't adapt to SocksPort changeOS: Ubuntu 8.04
TOR Version: 0.2.0.31-1~hardy+1
If the listening socks port changes in /etc/tor/torrc and /etc/tor/tor-tsocks.conf, i.e:
$ diff -ruN torrc torrc.bak
--- torrc.bak 2008-09-27 09:37:47.000000000 +0800
+++ torrc 2008-09-2...OS: Ubuntu 8.04
TOR Version: 0.2.0.31-1~hardy+1
If the listening socks port changes in /etc/tor/torrc and /etc/tor/tor-tsocks.conf, i.e:
$ diff -ruN torrc torrc.bak
--- torrc.bak 2008-09-27 09:37:47.000000000 +0800
+++ torrc 2008-09-27 09:39:48.000000000 +0800
@@ -18,1 +18,1 @@
-SocksPort 9050 # what port to open for local application connections
+SocksPort 9051 # what port to open for local application connections
$ diff -ruN tor-tsocks.conf.bak tor-tsocks.conf
--- tor-tsocks.conf.bak 2008-09-27 09:37:59.000000000 +0800
+++ tor-tsocks.conf 2008-09-27 09:40:53.000000000 +0800
@@ -7,1 +7,1 @@
-server_port = 9050
+server_port = 9051
tor-resolve will not work. Report this error:
$ tor-resolve www.google.com
Sep 27 09:46:41.704 [err] Error while connecting to SOCKS host: Connection refused
It seems tor-resolve does not read the configure files in /etc/tor. If I restore configure files to default, everything works OK.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: solrexhttps://gitlab.torproject.org/tpo/core/tor/-/issues/827Tor detects imaginary IP change2020-06-27T14:10:10ZTracTor detects imaginary IP changeWeird! Details : had Tor set to "guess" our WAN IP. Minutes before starting the Tor (server), I voluntarily changed my ISP assigned IP.
Launched Tor : it detected the correct IP (line 1). But 1 minute later, Tor senses an *imaginary* cha...Weird! Details : had Tor set to "guess" our WAN IP. Minutes before starting the Tor (server), I voluntarily changed my ISP assigned IP.
Launched Tor : it detected the correct IP (line 1). But 1 minute later, Tor senses an *imaginary* change of IP address (line 6) that was to the FORMER
IP address, i.e. one that was in effect BEFORE the server was launched. I can only suppose Tor found the IP number from some stale file or cache !
First time ever seen that, but usually I didn't let Tor "guess" the WAN IP, rather giving it a (dynamic DNS) host name.
Oh and 10 minutes later, Tor redected our IP, this time correctly (not shown in below log).
Log excerpt :
_______________________________________________________________________________________________________________
Sep 27 12:23:41.203 [notice] Guessed our IP address as XX.XX.237.161.
Sep 27 12:23:44.109 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 27 12:23:44.109 [notice] Now checking whether ORPort XX.XX.237.161:110 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Sep 27 12:24:00.093 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Sep 27 12:24:18.609 [notice] Performing bandwidth self-test...done.
Sep 27 12:24:42.593 [notice] Our IP Address has changed from XX.XX.237.161 to XX.XX.250.23; rebuilding descriptor.
_______________________________________________________________________________________________________________
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Noino6670.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/828native-connect sockaddr error2020-06-27T14:10:10ZTracnative-connect sockaddr errorI am running Tor in systrace v1.6d on OpenBSD 4.3
After an upgrade of Tor 0.1.2.19 to 0.2.0.30/31 a new policy appeared
native-connect: sockaddr eq "error" then permit
Apart from that, I get numerous messages on a terminal window:
sy...I am running Tor in systrace v1.6d on OpenBSD 4.3
After an upgrade of Tor 0.1.2.19 to 0.2.0.30/31 a new policy appeared
native-connect: sockaddr eq "error" then permit
Apart from that, I get numerous messages on a terminal window:
systrace: getnameinfo: No such file or directory
systrace: getnameinfo: No such file or directory
systrace: getnameinfo: No such file or directory
systrace: getnameinfo: No such file or directory
and so on. It makes it very hard to use the terminal because the error
messages come and go, often when you are in the middle of something. It
just makes it impossible to use. Unlike policy violations these errors
are not logged, they just scroll on screen.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: komohttps://gitlab.torproject.org/tpo/core/tor/-/issues/833prefer canonical connections2020-06-27T14:10:09ZRoger Dingledineprefer canonical connectionsThis fix for checking prefer canonical connections even if that cases
looks as impossible.
helped in some cases against hypothetical situation which happened.
for two non-obsolete connections with a non-canonical newest one.
(currently ...This fix for checking prefer canonical connections even if that cases
looks as impossible.
helped in some cases against hypothetical situation which happened.
for two non-obsolete connections with a non-canonical newest one.
(currently for conns between 0.2.x and 0.1.2.x)
so it's cosmetic hypothetical fix for next future of old bugs.
--- connection_or.original.c Sat Jul 26 22:36:20 2008
+++ connection_or.c Tue Aug 19 09:38:30 2008
@@ -480,6 +480,8 @@
continue; /* We never prefer obsolete over non-obsolete connections. */
if (
+ /* We prefer canonical connections: */
+ (!best->is_canonical && conn->is_canonical) ||
/* We prefer non-obsolete connections: */
(best->_base.or_is_obsolete && !conn->_base.or_is_obsolete) ||
/* If both have circuits we prefer the newer: */
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/839Tor 0.2.0.31 (r16744) crash on OpenBSD 4.3-stable (GENERIC)2020-06-27T14:10:09ZfredzupyTor 0.2.0.31 (r16744) crash on OpenBSD 4.3-stable (GENERIC)After only 3 days online, my new Tor relay crashed with no error in log.
Here is the backtrace from the core :
#0 0x0eb5828d in kill () from /usr/lib/libc.so.43.0
#1 0x0eb90833 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
legac...After only 3 days online, my new Tor relay crashed with no error in log.
Here is the backtrace from the core :
#0 0x0eb5828d in kill () from /usr/lib/libc.so.43.0
#1 0x0eb90833 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
legacy/trac#2 0x0eb31817 in __assert2 (file=0x2742ace0 "/usr/src/lib/libssl/src/crypto/rand/md_rand.c", line=313, func=0x2742ac74 "ssleay_rand_add",
failedexpr=0x2742ad80 "md_c[1] == md_count[1]") at /usr/src/lib/libc/gen/assert.c:52
legacy/trac#3 0x07492eb4 in ssleay_rand_add (buf=0xcfbccd7c, num=4, add=0) at /usr/src/lib/libssl/src/crypto/rand/md_rand.c:219
legacy/trac#4 0x0749282e in RAND_add (buf=0xcfbccd78, num=4, entropy=0) at /usr/src/lib/libssl/src/crypto/rand/rand_lib.c:167
legacy/trac#5 0x0036f9e3 in ssl23_connect (s=0x7fd8ec00) at /usr/src/lib/libssl/src/ssl/s23_clnt.c:114
legacy/trac#6 0x0037ac09 in SSL_connect (s=0x7fd8ec00) at /usr/src/lib/libssl/src/ssl/ssl_lib.c:825
legacy/trac#7 0x1c090d3f in tor_tls_handshake (tls=0x82987900) at tortls.c:936
legacy/trac#8 0x1c02b3e2 in connection_tls_continue_handshake (conn=0x84984900) at connection_or.c:629
legacy/trac#9 0x1c0219af in connection_read_to_buf (conn=0x84984900, max_to_read=0xcfbcce58) at connection.c:1950
legacy/trac#10 0x1c021338 in connection_handle_read (conn=0x84984900) at connection.c:1843
legacy/trac#11 0x1c04e990 in conn_read_callback (fd=181, event=2, _conn=0x84984900) at main.c:457
legacy/trac#12 0x0bcb6214 in event_process_active (base=0x839da1c0) at /usr/src/lib/libevent/event.c:317
legacy/trac#13 0x0bcb6482 in event_base_loop (base=0x839da1c0, flags=0) at /usr/src/lib/libevent/event.c:433
legacy/trac#14 0x0bcb631b in event_loop (flags=0) at /usr/src/lib/libevent/event.c:368
legacy/trac#15 0x1c050467 in do_main_loop () at main.c:1447
legacy/trac#16 0x1c0512c1 in tor_main (argc=3, argv=0xcfbccfe4) at main.c:1990
legacy/trac#17 0x1c07e7b7 in main (argc=3, argv=0xcfbccfe4) at tor_main.c:29
[Automatically added by flyspray2trac: Operating System: BSD]https://gitlab.torproject.org/tpo/core/tor/-/issues/840Should Hidden Service answer if a wrong 'begin' cell?2020-06-27T14:10:09ZTracShould Hidden Service answer if a wrong 'begin' cell?
After fix of 444, HS not anymore closing circuits if a wrong 'begin'
cells received. However they never sended 'RELAY_END' cells also.
So well-behaved clients don't known if problems happened.
On other hand, if HS answers then attacker...
After fix of 444, HS not anymore closing circuits if a wrong 'begin'
cells received. However they never sended 'RELAY_END' cells also.
So well-behaved clients don't known if problems happened.
On other hand, if HS answers then attacker can measure latency
(bad 'begin' <-> 'end' cell) on Tor-level so long as he want. (just IMO)
if HS should answer, then a fix:
--- connection_edge.original.c Mon Sep 29 19:20:02 2008
+++ connection_edge.c Mon Oct 20 15:34:18 2008
@@ -2566,7 +2566,7 @@
n_stream->_base.port);
end_payload[0] = END_STREAM_REASON_EXITPOLICY;
relay_send_command_from_edge(rh.stream_id, circ, RELAY_COMMAND_END,
- end_payload, 1, NULL);
+ end_payload, 1, origin_circ->cpath->prev);
connection_free(TO_CONN(n_stream));
tor_free(address);
return 0;
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rovvhttps://gitlab.torproject.org/tpo/core/tor/-/issues/843tor exited unexpectedly2020-06-27T14:10:09ZTractor exited unexpectedlyI installed vidalia bundle on my mac. When I click on start tor a message saying tor exited unexpectedly cames out.
What is wrong? what should I do? the message log doesn't work either.
thks,
Adriana
[Automatically added by flyspray2tra...I installed vidalia bundle on my mac. When I click on start tor a message saying tor exited unexpectedly cames out.
What is wrong? what should I do? the message log doesn't work either.
thks,
Adriana
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: adrianaAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/845Tor crash on ppc64 with bad descriptors2020-06-27T14:10:09ZcodermanTor crash on ppc64 with bad descriptorsTor 0.2.1.6-alpha on ppc64 (PS3 Ubuntu) fails assert reliably with a bad descriptor found in http://peertech.org/files/save-bad-cached-files-tor-ppc64-crash.tgz
The failed assert is:
[err] Bug: policies.c:1266: addr_policy_free: Asserti...Tor 0.2.1.6-alpha on ppc64 (PS3 Ubuntu) fails assert reliably with a bad descriptor found in http://peertech.org/files/save-bad-cached-files-tor-ppc64-crash.tgz
The failed assert is:
[err] Bug: policies.c:1266: addr_policy_free: Assertion p == found->policy failed; aborting.
The Tor instance attempts to remove a canonical policy returned by the hash table HT_REMOVE.
The policy to find is (i added some additional debugging info to help troubleshoot):
debug_policy(): Policy data for 0x101f2d88:
HASH: 1105958104
IsPrivate: 0
addr: 190.21.106.7
mask: 32
prt_min: 1
prt_max: 65535
type: 2
The matched policy shouldn't match, but does return:
debug_policy(): Policy data for 0x1027bb68:
HASH: 2801726591
IsPrivate: 0
addr: 89.2.10.96
mask: 32
prt_min: 1
prt_max: 65535
type: 2
The assert fails because the search policy does not match the found policy in addr_policy_free.
The policy at address 0x1027bb68 is for router "router Unnamed 221.207.2.77 443 0 9030" in the cached files.
The policy at address 0x101f2d88 is for router "router utumno 98.100.128.152 9001 0 0".
I can attempt to assist further if necessary. This does not appear to be a problem on x86 for the same alpha version.
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/847Extreme values in downloading directory information2020-06-27T14:10:09ZKarsten LoesingExtreme values in downloading directory informationSometimes it takes a really long time until Tor has downloaded enough
directory information to build circuits. In an experiment with 1,220
attempts to start new Tor instances, the following times were measured for
downloading directory i...Sometimes it takes a really long time until Tor has downloaded enough
directory information to build circuits. In an experiment with 1,220
attempts to start new Tor instances, the following times were measured for
downloading directory information (in seconds):
Min. 1st Qu. Median Mean 3rd Qu. Max.
1.732 5.016 7.602 35.680 17.210 681.300
The highest 50 values are:
141.560 151.013 151.880 164.672 169.010 184.269 184.280 187.733 207.903
222.899 238.430 248.529 250.513 252.959 265.249 269.104 281.840 295.144
307.421 307.719 307.863 307.940 308.403 308.438 308.672 308.730 308.741
309.053 309.293 309.357 309.839 310.033 310.259 310.275 311.930 313.203
313.385 313.597 315.260 317.916 318.327 325.420 362.017 367.175 452.797
487.972 489.534 537.029 615.759 681.341
A look at the log files reveals that Tor attempts to fetch network
statuses or authority certificates from a single directory that is
unavailable at the moment. The request times out after 120 seconds, and
another attempt is made---possibly to the same directory. During the
measurements, dannenberg appeared to be offline, so that attempts to that
authority timed out:
egrep "Bootstrap|86.59.21.38|216.224.124.114|213.73.91.31|141.13.4.202|128.31.0.34|194.109.206.212" log
Nov 01 08:42:02.390 [info] Bootstrapped 0%: Starting.
Nov 01 08:42:02.390 [info] connection_ap_make_link(): Making internal direct tunnel to 194.109.206.212:443 ...
Nov 01 08:42:02.391 [notice] Bootstrapped 5%: Connecting to directory server.
Nov 01 08:42:02.393 [info] connection_ap_make_link(): Making internal direct tunnel to 213.73.91.31:443 ...
Nov 01 08:42:02.393 [info] directory_send_command(): Downloading consensus from 213.73.91.31:443 using /tor/status-vote/current/consensus.z
Nov 01 08:42:02.413 [notice] Bootstrapped 10%: Finishing handshake with directory server.
Nov 01 08:42:02.603 [info] command_process_versions_cell(): Negotiated version 2 with 194.109.206.212; sending NETINFO.
Nov 01 08:42:02.604 [notice] Bootstrapped 15%: Establishing an encrypted directory connection.
Nov 01 08:42:02.605 [info] command_process_netinfo_cell(): Got good NETINFO cell from 194.109.206.212; OR connection is now open, using protocol version 2
Nov 01 08:42:02.693 [notice] Bootstrapped 20%: Asking for networkstatus consensus.
Nov 01 08:42:02.790 [info] connection_dir_client_reached_eof(): Received authority certificates (size 9804) from server '194.109.206.212:443'
Nov 01 08:42:35.033 [info] command_process_versions_cell(): Negotiated version 2 with 213.73.91.31; sending NETINFO.
Nov 01 08:44:02.857 [info] connection_ap_expire_beginning(): Tried for 120 seconds to get a connection to 213.73.91.31:443. Giving up. (waiting for circuit)
Nov 01 08:44:02.857 [info] connection_ap_make_link(): Making internal direct tunnel to 213.73.91.31:443 ...
Nov 01 08:44:02.858 [info] directory_send_command(): Downloading consensus from 213.73.91.31:443 using /tor/status-vote/current/consensus.z
Nov 01 08:46:02.317 [info] connection_ap_expire_beginning(): Tried for 120 seconds to get a connection to 213.73.91.31:443. Giving up. (waiting for circuit)
Nov 01 08:47:07.565 [info] connection_ap_make_link(): Making internal direct tunnel to 213.73.91.31:443 ...
Nov 01 08:47:07.565 [info] directory_send_command(): Downloading consensus from 213.73.91.31:443 using /tor/status-vote/current/consensus.z
Nov 01 08:47:35.669 [info] run_connection_housekeeping(): Expiring non-open OR connection to fd 16 (213.73.91.31:443).
Nov 01 08:47:35.669 [info] connection_ap_fail_onehop(): Closing onehop stream to '$7BE683E65D48141321C5ED92F075C55364AC7123/213.73.91.31' because the OR conn just failed.
Nov 01 08:53:13.929 [info] connection_ap_make_link(): Making internal direct tunnel to 216.224.124.114:9090 ...
Nov 01 08:53:13.930 [info] directory_send_command(): Downloading consensus from 216.224.124.114:9090 using /tor/status-vote/current/consensus.z
Nov 01 08:53:15.788 [info] command_process_versions_cell(): Negotiated version 2 with 216.224.124.114; sending NETINFO.
Nov 01 08:53:15.788 [info] command_process_netinfo_cell(): Got good NETINFO cell from 216.224.124.114; OR connection is now open, using protocol version 2
Nov 01 08:53:16.677 [notice] Bootstrapped 25%: Loading networkstatus consensus.
Nov 01 08:53:21.322 [info] connection_dir_client_reached_eof(): Received consensus directory (size 256583) from server '216.224.124.114:9090'
Nov 01 08:53:21.345 [notice] Bootstrapped 45%: Asking for relay descriptors.
Nov 01 08:53:21.742 [notice] Bootstrapped 50%: Loading relay descriptors.
Nov 01 08:53:22.105 [notice] Bootstrapped 59%: Loading relay descriptors.
Nov 01 08:53:22.652 [notice] Bootstrapped 69%: Loading relay descriptors.
Nov 01 08:53:23.092 [notice] Bootstrapped 80%: Connecting to the Tor network.
Nov 01 08:53:24.408 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Nov 01 08:53:25.394 [notice] Bootstrapped 100%: Done.
Nov 01 08:53:59.577 [info] connection_ap_make_link(): Making internal anonymized tunnel to 141.13.4.202:443 ...
Nov 01 09:08:24.117 [info] run_connection_housekeeping(): Expiring non-used OR connection to fd 15 (194.109.206.212:443) [Not in clique mode].
Possible fixes could be shorter timeouts or parallel requests. However,
these fixes have side-effects on network load. Maybe there is also a way to
detect and exclude unavailable directory more quickly (requests are
tunneled directory requests using one-hop circuits).
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/848Fix switch_id to properly drop euid/uid/egid/gid2020-06-27T14:10:09ZJacob AppelbaumFix switch_id to properly drop euid/uid/egid/gidI spent the day with Theo De Raadt and he pointed out that we incorrectly try to drop uid/gid. I'll attach a patch that fixes this.
[Automatically added by flyspray2trac: Operating System: All]I spent the day with Theo De Raadt and he pointed out that we incorrectly try to drop uid/gid. I'll attach a patch that fixes this.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/849Dir-spec requires "dir-address"2020-06-27T14:10:09ZTracDir-spec requires "dir-address"The current dir-spec.txt from trunk requires "dir-address" [Once or more], but the current implementation does
not display this. Probably the spec should be changed to "any number" or the keyword removed entirely.
[Automatically added...The current dir-spec.txt from trunk requires "dir-address" [Once or more], but the current implementation does
not display this. Probably the spec should be changed to "any number" or the keyword removed entirely.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Freedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/850Compiler warning on FreeBSD 7.02020-06-27T14:10:09ZSteven MurdochCompiler warning on FreeBSD 7.0When compiling Tor using FreeBSD 7.0 (SVN r17189), I get the following warning:
util.c: In function '_tor_malloc_roundup':
util.c:260: warning: implicit declaration of function 'malloc_usable_size'
#include'ing <malloc_np.h> in util.c ...When compiling Tor using FreeBSD 7.0 (SVN r17189), I get the following warning:
util.c: In function '_tor_malloc_roundup':
util.c:260: warning: implicit declaration of function 'malloc_usable_size'
#include'ing <malloc_np.h> in util.c fixes the warning (this header file is mentioned in the malloc(3) manpage).
[Automatically added by flyspray2trac: Operating System: BSD]https://gitlab.torproject.org/tpo/core/tor/-/issues/851Authorities and clients don't mind expiry of v3 certificates2020-06-27T14:10:08ZKarsten LoesingAuthorities and clients don't mind expiry of v3 certificatesThe certificate of ides has expired on 2008-11-07 09:00:50, but the
authority continues signing the consensus and clients continue believing in
it:
0 unknown, 0 missing key, 6 good, 0 bad, 0 no signature, 4 required
Although dir-spec.t...The certificate of ides has expired on 2008-11-07 09:00:50, but the
authority continues signing the consensus and clients continue believing in
it:
0 unknown, 0 missing key, 6 good, 0 bad, 0 no signature, 4 required
Although dir-spec.txt does not specifically state whether authorities and
clients should behave differently, it says:
Authorities MUST generate a new signing key and corresponding
certificate before the key expires.
The current behavior should be changed so that a) authorities don't sign
the consensus with a known expired signing key, and b) clients should
check whether a certificate is still valid when validating a consensus.
Brought to attention by miner.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/852Ubuntu Intrepid fresh install - fails to find authority certificate 250A21E16...2020-06-27T14:10:08ZTracUbuntu Intrepid fresh install - fails to find authority certificate 250A21E163A25851BB574E80DC4E41Atail -f /var/log/tor/log
What does it mean and how to help it?
[and so forth]
Nov 07 21:26:02.935 [notice] We're missing a certificate from authority with signing key 250A21E163A25851BB574E80DC4E41AE86F60C89: launching request.
Nov 07 ...tail -f /var/log/tor/log
What does it mean and how to help it?
[and so forth]
Nov 07 21:26:02.935 [notice] We're missing a certificate from authority with signing key 250A21E163A25851BB574E80DC4E41AE86F60C89: launching request.
Nov 07 21:27:03.178 [notice] We're missing a certificate from authority with signing key 250A21E163A25851BB574E80DC4E41AE86F60C89: launching request.
Nov 07 21:28:04.411 [notice] We're missing a certificate from authority with signing key 250A21E163A25851BB574E80DC4E41AE86F60C89: launching request.
Nov 07 21:29:05.699 [notice] We're missing a certificate from authority with signing key 250A21E163A25851BB574E80DC4E41AE86F60C89: launching request.
Nov 07 21:30:06.939 [notice] We're missing a certificate from authority with signing key 250A21E163A25851BB574E80DC4E41AE86F60C89: launching request.
Nov 07 21:31:07.167 [notice] We're missing a certificate from authority with signing key 250A21E163A25851BB574E80DC4E41AE86F60C89: launching request.
[and so forth]
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: grizzlyhttps://gitlab.torproject.org/tpo/core/tor/-/issues/853"w" and "p" lines undocumented in dir-spec2020-06-27T14:10:08ZTrac"w" and "p" lines undocumented in dir-specCurrent tor authority server implementation returns a network status document
(the consensus document, for example) in this format (random OR picked as example):
r TheDonor AKSWi6nWN/RJlwA25u+ZpqCEHjc UBWA+46OxsrBbmliStCpSLR3lWQ 2008-1...Current tor authority server implementation returns a network status document
(the consensus document, for example) in this format (random OR picked as example):
r TheDonor AKSWi6nWN/RJlwA25u+ZpqCEHjc UBWA+46OxsrBbmliStCpSLR3lWQ 2008-11-03 18:59:48 91.120.135.250 443 0
s Exit Running Valid
v Tor 0.2.0.31 (r16744)
w Bandwidth=17
p accept 110,143,443,706,993,995,1863,5050,5190,5222-5223,6660-6669,6697,8300,8888
However, dir-spec only documents the "r", "s" and "v" lines, documentation should be added for "w" and "p" lines.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Freedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/855"Unnamed" flag not documented in the context of "s" lines in dir-spec2020-06-27T14:10:08ZTrac"Unnamed" flag not documented in the context of "s" lines in dir-specThe "Unnamed" router status flag is mentioned in dir-spec, but missing from the
list of all possible router status flags in 3.2, the section about "s" lines.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**U...The "Unnamed" router status flag is mentioned in dir-spec, but missing from the
list of all possible router status flags in 3.2, the section about "s" lines.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Freedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/856SIGHUP not compatible with configuring tor over controlport2020-06-27T14:10:08ZRobert HoganSIGHUP not compatible with configuring tor over controlportThe Debian/Ubuntu noreply package of Tor performs regular logrotates on Tor. This results in Tor handling a SIGHUP
and reloading the config from torrc. Any configuration made over the controlport, but not written to torrc, is lost
when t...The Debian/Ubuntu noreply package of Tor performs regular logrotates on Tor. This results in Tor handling a SIGHUP
and reloading the config from torrc. Any configuration made over the controlport, but not written to torrc, is lost
when this happens.
I suggest that Tor should respect the existing soft configuration during a SIGHUP.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/857Latest SVNs will not start - no log messages2020-06-27T14:10:08ZTracLatest SVNs will not start - no log messagesWhen I try to start the latest SVN version of tor, I receive the following console messages.
Despite the last line, there is nothing at all in the log file.
Nov 09 09:30:11.070 [notice] Tor v0.2.1.7-alpha (r17224). This is experimental ...When I try to start the latest SVN version of tor, I receive the following console messages.
Despite the last line, there is nothing at all in the log file.
Nov 09 09:30:11.070 [notice] Tor v0.2.1.7-alpha (r17224). This is experimental software. Do not rely on it for strong anonymity. (Running on NetBSD i386)
Nov 09 09:30:11.086 [notice] Initialized libevent version 1.4.3-stable using method kqueue. Good.
Nov 09 09:30:11.088 [notice] Opening Socks listener on 192.168.1.1:9050
Nov 09 09:30:11.094 [warn] Error setting configured groups: Operation not permitted
Nov 09 09:30:11.094 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
Nov 09 09:30:11.095 [err] Reading config failed--see warnings above.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: yancmhttps://gitlab.torproject.org/tpo/core/tor/-/issues/858getinfo circuit-status doesn't include PURPOSE=2020-06-27T14:10:07ZRoger Dingledinegetinfo circuit-status doesn't include PURPOSE=We changed the extended circ event to say PURPOSE=, so the controller would
have a better sense of how to display the circuit.
But we didn't add any corresponding parameter to the getinfo circuit-status
output. Controllers need this whe...We changed the extended circ event to say PURPOSE=, so the controller would
have a better sense of how to display the circuit.
But we didn't add any corresponding parameter to the getinfo circuit-status
output. Controllers need this when they connect to Tor and want to get up to
speed on what's already happened.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/859datadirectory locking doesn't work on windows?2020-06-27T14:10:07ZRoger Dingledinedatadirectory locking doesn't work on windows?We have a user on #tor who says he's running 3 Tor clients on a single
datadirectory.
Lirezh_off> there is a lock file but it is ignored
Lirezh_off> i tried to run 3 tor at the same time, it didnot seem to make a
problem
> did the newe...We have a user on #tor who says he's running 3 Tor clients on a single
datadirectory.
Lirezh_off> there is a lock file but it is ignored
Lirezh_off> i tried to run 3 tor at the same time, it didnot seem to make a
problem
> did the newer tors overwrite the lock file?
> or did it stay with the first one
Lirezh_off> second
Lirezh_off> lock and state were changed, but only with the first launch
Lirezh_off> the other files are untouched atm
Perhaps we are not locking correctly on Windows?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/860Tor-spec does not specify how clients should manage identity certificates2020-06-27T14:10:07ZTracTor-spec does not specify how clients should manage identity certificatesTor-spec requires two certificates from each part when negotiating a TLS session, one using a temporary key,
and one using the identity key of each part. This is fine when one OR connects to another, but when a client/OP
connects to its ...Tor-spec requires two certificates from each part when negotiating a TLS session, one using a temporary key,
and one using the identity key of each part. This is fine when one OR connects to another, but when a client/OP
connects to its initial OR, it should reveal as little as possible about itself. The client might of course be
tracked by IP by the first OR, but having a long term identity key will make it even less anonymous. For example,
the client might be connecting from a large NAT network, or through another anonymization service.
The specification should either specify how often clients are supposed to change their identity keys (use a new one
for each connection?), or explicitly allow clients to connect using only one certificate (any issues with this,
making it easier to tell client-OR connections from OR-OR connections?).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Freedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/861tor doesn't release log fd on hup if log failed2020-06-27T14:10:07ZRoger Dingledinetor doesn't release log fd on hup if log failedIf my disk fills up and Tor's log stops (write failed or the like), then Tor
handles it fine -- it doesn't die:
% lsof|grep tord
tor 18060 arma 16w REG 3,5 11517952 782436 /tmp/tord-log
But when I hup tor,...If my disk fills up and Tor's log stops (write failed or the like), then Tor
handles it fine -- it doesn't die:
% lsof|grep tord
tor 18060 arma 16w REG 3,5 11517952 782436 /tmp/tord-log
But when I hup tor, I get two handles:
tor 18060 arma 9w REG 3,5 11517952 782436 /tmp/tord-log
tor 18060 arma 16w REG 3,5 11517952 782436 /tmp/tord-log
I deleted tord-log, and I still have the handles (makes sense):
tor 18060 arma 9w REG 3,5 11517952 782436 /tmp/tord-log (deleted)
tor 18060 arma 16w REG 3,5 11517952 782436 /tmp/tord-log (deleted)
But then I hup tor and they're still here:
tor 18060 arma 9w REG 3,5 11517952 782436 /tmp/tord-log (deleted)
tor 18060 arma 16w REG 3,5 11517952 782436 /tmp/tord-log (deleted)
tor 18060 arma 20w REG 3,5 0 783109 /tmp/tord-log
It only happens when I'm out of disk space. So presumably there's something about
our seems_dead log entries that makes them not get cleaned when Tor hups.
Bug affects both 0.2.0.x and 0.2.1.x. I didn't check 0.1.2.x.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/862tor segfaults on sparc642020-06-27T14:10:07Zrator segfaults on sparc64i tried 0.2.0.31 and 0.2.1.7-alpha. both produce a bus error after a few seconds running on sparc64 gentoo linux.
[Automatically added by flyspray2trac: Operating System: Other Linux]i tried 0.2.0.31 and 0.2.1.7-alpha. both produce a bus error after a few seconds running on sparc64 gentoo linux.
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/863Relay crashes OSX 10.3.92020-06-27T14:10:07ZTracRelay crashes OSX 10.3.9Tor v0.2.0.31 (r16744). Mac OSX10.3.9 500Mhz 640Mb Libevent 1.4.7 ORPort 9001
Running a Tor relay consistently crashes the machine after a few hours (black screen of death).
No other desktop software is running apart from Anti-virus and ...Tor v0.2.0.31 (r16744). Mac OSX10.3.9 500Mhz 640Mb Libevent 1.4.7 ORPort 9001
Running a Tor relay consistently crashes the machine after a few hours (black screen of death).
No other desktop software is running apart from Anti-virus and PGP-Desktop memory-resident programs.
Little Snitch is also running, it is set to allow Tor any network connection.
The torrc is the bare minimum, apart from an Address line to avoid a bug with dynamic IP not being detected correctly
(submitted separately). Bandwidth is limited for 512k upload. Logging is currently at Notice level.
Tell me what to log and how please!
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]
**Trac**:
**Username**: downie0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/864patch2020-06-27T14:10:07ZTracpatch
--- dirvote.c Fri Nov 14 08:48:40 2008
+++ dirvote.wtf.c Fri Nov 14 09:07:06 2008
@@ -2082,13 +2082,15 @@
tor_free(pending_consensus_signatures);
pending_consensus_signatures = new_detached;
*msg_out = "Signatures added";...
--- dirvote.c Fri Nov 14 08:48:40 2008
+++ dirvote.wtf.c Fri Nov 14 09:07:06 2008
@@ -2082,13 +2082,15 @@
tor_free(pending_consensus_signatures);
pending_consensus_signatures = new_detached;
*msg_out = "Signatures added";
+ } else if (r == 0) {
+ *msg_out = "Signatures ignored";
} else {
goto err;
}
goto done;
err:
- if (!msg_out)
+ if (!*msg_out)
*msg_out = "Unrecognized error while adding detached signatures.";
done:
if (sigs)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rovvhttps://gitlab.torproject.org/tpo/core/tor/-/issues/867Tor segfaults when trying to set EntryNodes via control port2020-06-27T14:10:07ZSebastian HahnTor segfaults when trying to set EntryNodes via control port[17:00] <Lirezh_off> 0x080ce0ec in routerset_equal (old=0x0, new=0x84db730) at routerlist.c:5071
[17:00] <Lirezh_off> 5071 if (smartlist_len(old->list) != smartlist_len(new->list))
[17:00] <Lirezh_off> SETCONF EntryNodes=16D8815839503...[17:00] <Lirezh_off> 0x080ce0ec in routerset_equal (old=0x0, new=0x84db730) at routerlist.c:5071
[17:00] <Lirezh_off> 5071 if (smartlist_len(old->list) != smartlist_len(new->list))
[17:00] <Lirezh_off> SETCONF EntryNodes=16D8815839503CB9DE594EEE463BD106F6F6FA2B
[17:01] <Lirezh_off> Tor v0.2.1.6-alpha (r17011)
[17:04] <Lirezh_off> Hm it crashes in general when setting a entrynode for me, no idea why
[17:04] <Lirezh_off> ExitNodes work
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/868DNS nameservers not correctly loaded in Windows XP2020-06-27T14:10:07ZTracDNS nameservers not correctly loaded in Windows XPI think this bug might be related to:
http://bugs.noreply.org/flyspray/?do=details&id=813
However, here the problem is with dealing with bad nameservers from GetNetworkParams. When I started up Tor
on another network, it gave the follo...I think this bug might be related to:
http://bugs.noreply.org/flyspray/?do=details&id=813
However, here the problem is with dealing with bad nameservers from GetNetworkParams. When I started up Tor
on another network, it gave the following output and exited:
Nov 17 10:32:50.656 [notice] Parsing GEOIP file.
Nov 17 10:32:53.078 [info] eventdns: Added nameserver 196.1.106.65
Nov 17 10:32:53.078 [info] eventdns: Successfully added 65.106.1.196 as nameserver
Nov 17 10:32:53.078 [info] eventdns: Could not add nameserver 65.106.7.196 to list,error: 0
Nov 17 10:32:53.078 [info] eventdns: Didn't find nameservers in nt_key/"NameServer"
Nov 17 10:32:53.078 [info] eventdns: Didn't find nameservers in nt_key/"DhcpNameServer"
Nov 17 10:32:53.078 [info] eventdns: Didn't find nameservers in interfaces_key/"NameServer"
Nov 17 10:32:53.078 [info] eventdns: Didn't find nameservers in interfaces_key/"DhcpNameServer"
Nov 17 10:32:53.078 [warn] eventdns: Didn't find any nameservers.
Nov 17 10:32:53.078 [warn] Could not config nameservers.
Nov 17 10:32:53.078 [err] Error initializing dns subsystem; exiting
I think there are a few bugs here. First, evdns_config_windows_nameservers can fail even when there are valid
nameservers because load_nameservers_with_getnetworkparams will fail even when there are valid nameservers, which
causes load_nameservers_from_registry to be called, and there are no DNS settings in my registry (and that is probably
the case for most Windows users), which in turn causes the whole function to fail, and Tor to exit.
The second bug is that within load_nameservers_with_getnetworkparams, calls to evdns_nameserver_ip_add_line seem to
fail at the wrong time. I originally encountered the above error when testing on another network (that I cant get back
to), so while I was trying to reproduce the error, I ended up making my own IP_ADDR_STRING lists: (note that everything
from this point on was done on the HEAD revision of Tor. The previous error came from 2.1.6-alpha)
near the top of load_nameservers_with_getnetworkparams:
IP_ADDR_STRING addr1, addr2;
memcpy(addr1.IpAddress.String, "192.168.1.9\0", 12);
memcpy(addr2.IpAddress.String, "192.168.1.1\0", 12);
addr1.Next = &addr2;
addr2.Next = NULL;
ns = &addr1;
//...later on in that function, I just commented out where ns was set normally, so it used the debug IP list:
assert(fixed);
added_any = 0;
//ns = &(fixed->DnsServerList);
while (ns) {
//...
In my network, 192.168.1.1 is the DNS server, and 192.168.1.9 does not exist. However, running the above test gives
this output:
Nov 17 14:33:31.227 [info] eventdns: Added nameserver 9.1.168.192
Nov 17 14:33:32.446 [info] eventdns: Successfully added 192.168.1.9 as nameserver
Nov 17 14:33:37.680 [info] eventdns: Could not add nameserver 192.168.1.1 to list,error: 0
Which is not right. Tor also fails if I reverse the order of the list (trying 192.168.1.1 before 192.168.1.9), with
this more logical output:
Nov 17 14:32:01.680 [info] eventdns: Added nameserver 1.1.168.192
Nov 17 14:32:04.118 [info] eventdns: Successfully added 192.168.1.1 as nameserver
Nov 17 14:32:19.915 [info] eventdns: Could not add nameserver 192.168.1.9 to list,error: 0
Sorry that I can't provide a patch, but I cant figure out what is causing evdns_nameserver_ip_add_line to fail at
the wrong time. Hopefully this information is helpful.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: TheJashhttps://gitlab.torproject.org/tpo/core/tor/-/issues/869Node kyirong 404 for hi5.com2020-06-27T14:10:06ZTracNode kyirong 404 for hi5.comNode kyirong in the netherlands ALWAYS reports 404 error when processing requests for hi5.com
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: toby_ft_laudNode kyirong in the netherlands ALWAYS reports 404 error when processing requests for hi5.com
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: toby_ft_laudAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/870Suddenly can't connect to the Tor network2020-06-27T14:10:06ZTracSuddenly can't connect to the Tor networkSorry, dont't know where else to ask, so i'm here. (Couldn't find, where to register on Vidalia bug tracker.)
I've had problems with finding enough routers or like this for a few days.
They appeared suddenly, so it seems that my Outpost...Sorry, dont't know where else to ask, so i'm here. (Couldn't find, where to register on Vidalia bug tracker.)
I've had problems with finding enough routers or like this for a few days.
They appeared suddenly, so it seems that my Outpost firewall and NOD32 aren't reasons.
No OS modifications were made.
Decided to reinstall Vidalia+Privoxy.
Win XP SP2, Vidalia 0.1.9, Tor 0.2.0.31 (r16744). (I've got external IP.)
But now I have this:
---
ноя 20 13:47:38.828 [Info] circuit_n_conn_done(): or_conn failed. Closing circ.
ноя 20 13:47:38.828 [Info] connection_ap_fail_onehop(): Closing onehop stream to '$68333D0761BCF397A587A0C0B963E4A9E99EC4D3/88.198.7.215' because the OR conn just failed.
ноя 20 13:47:38.828 [Info] connection_ap_fail_onehop(): Closing onehop stream to '$68333D0761BCF397A587A0C0B963E4A9E99EC4D3/88.198.7.215' because the OR conn just failed.
ноя 20 13:47:38.828 [Info] _connection_free(): Freeing linked Socks connection [waiting for circuit] with 77 bytes on inbuf, 0 on outbuf.
ноя 20 13:47:38.828 [Info] _connection_free(): Freeing linked Socks connection [waiting for circuit] with 299 bytes on inbuf, 0 on outbuf.
ноя 20 13:47:38.828 [Info] connection_dir_client_reached_eof(): 'fetch' response not all here, but we're at eof. Closing.
ноя 20 13:47:38.828 [Info] update_consensus_networkstatus_downloads(): Launching networkstatus consensus download.
ноя 20 13:47:38.828 [Info] router_pick_directory_server(): No reachable router entries for dirservers. Trying them all again.
ноя 20 13:47:38.828 [Info] router_pick_directory_server(): Still no reachable router entries. Reloading and trying again.
ноя 20 13:47:38.828 [Info] tor_mmap_file(): Couldn't mmap file "C:\Documents and Settings\Haze\Application Data\tor\cached-descriptors": Íå óäàåòñÿ íàéòè óêàçàííûé ôàéë.
ноя 20 13:47:38.828 [Info] tor_mmap_file(): Couldn't mmap file "C:\Documents and Settings\Haze\Application Data\tor\cached-extrainfo": Íå óäàåòñÿ íàéòè óêàçàííûé ôàéë.
ноя 20 13:47:38.828 [Info] directory_get_from_dirserver(): No router found for consensus network-status fetch; falling back to dirserver list.
ноя 20 13:47:38.828 [Info] connection_ap_make_link(): Making internal anonymized tunnel to [scrubbed]:443 ...
ноя 20 13:47:38.828 [Info] onion_pick_cpath_exit(): Using requested exit node '7BE683E65D48141321C5ED92F075C55364AC7123'
ноя 20 13:47:38.828 [Info] connection_ap_make_link(): ... application connection created and linked.
ноя 20 13:47:38.828 [Info] _connection_free(): Freeing linked Directory connection [client reading] with 0 bytes on inbuf, 0 on outbuf.
ноя 20 13:47:38.828 [Info] connection_dir_client_reached_eof(): 'fetch' response not all here, but we're at eof. Closing.
ноя 20 13:47:38.828 [Info] connection_dir_request_failed(): Giving up on directory server at '88.198.7.215'; retrying
ноя 20 13:47:38.828 [Notice] No current certificate known for authority moria1; launching request.
ноя 20 13:47:38.828 [Notice] No current certificate known for authority tor26; launching request.
ноя 20 13:47:38.828 [Notice] No current certificate known for authority dizum; launching request.
ноя 20 13:47:38.828 [Notice] No current certificate known for authority ides; launching request.
ноя 20 13:47:38.828 [Notice] No current certificate known for authority gabelmoo; launching request.
ноя 20 13:47:38.828 [Notice] No current certificate known for authority dannenberg; launching request.
ноя 20 13:47:38.843 [Info] router_pick_directory_server(): No reachable router entries for dirservers. Trying them all again.
ноя 20 13:47:38.843 [Info] router_pick_directory_server(): Still no reachable router entries. Reloading and trying again.
ноя 20 13:47:38.843 [Info] tor_mmap_file(): Couldn't mmap file "C:\Documents and Settings\Haze\Application Data\tor\cached-descriptors": Íå óäàåòñÿ íàéòè óêàçàííûé ôàéë.
ноя 20 13:47:38.843 [Info] tor_mmap_file(): Couldn't mmap file "C:\Documents and Settings\Haze\Application Data\tor\cached-extrainfo": Íå óäàåòñÿ íàéòè óêàçàííûé ôàéë.
ноя 20 13:47:38.843 [Info] directory_get_from_dirserver(): No router found for authority cert fetch; falling back to dirserver list.
ноя 20 13:47:38.843 [Info] connection_ap_make_link(): Making internal anonymized tunnel to [scrubbed]:9001 ...
ноя 20 13:47:38.843 [Info] onion_pick_cpath_exit(): Using requested exit node 'FFCB46DB1339DA84674C70D7CB586434C4370441'
ноя 20 13:47:38.843 [Info] connection_ap_make_link(): ... application connection created and linked.
ноя 20 13:47:38.843 [Info] _connection_free(): Freeing linked Directory connection [client reading] with 0 bytes on inbuf, 0 on outbuf.
ноя 20 13:47:38.843 [Info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
ноя 20 13:47:38.843 [Info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
ноя 20 13:47:38.843 [Info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
ноя 20 13:47:38.843 [Info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
ноя 20 13:48:00.046 [Info] circuit_n_conn_done(): or_conn failed. Closing circ.
ноя 20 13:48:00.046 [Info] connection_ap_fail_onehop(): Closing onehop stream to '$7BE683E65D48141321C5ED92F075C55364AC7123/213.73.91.31' because the OR conn just failed.
ноя 20 13:48:00.046 [Info] _connection_free(): Freeing linked Socks connection [waiting for circuit] with 77 bytes on inbuf, 0 on outbuf.
ноя 20 13:48:00.046 [Info] circuit_n_conn_done(): or_conn failed. Closing circ.
ноя 20 13:48:00.046 [Info] connection_ap_fail_onehop(): Closing onehop stream to '$FFCB46DB1339DA84674C70D7CB586434C4370441/128.31.0.34' because the OR conn just failed.
ноя 20 13:48:00.046 [Info] _connection_free(): Freeing linked Socks connection [waiting for circuit] with 299 bytes on inbuf, 0 on outbuf.
ноя 20 13:48:00.046 [Info] connection_dir_client_reached_eof(): 'fetch' response not all here, but we're at eof. Closing.
ноя 20 13:48:00.046 [Info] _connection_free(): Freeing linked Directory connection [client reading] with 0 bytes on inbuf, 0 on outbuf.
ноя 20 13:48:00.046 [Info] connection_dir_client_reached_eof(): 'fetch' response not all here, but we're at eof. Closing.
ноя 20 13:48:00.046 [Info] connection_dir_request_failed(): Giving up on directory server at '128.31.0.34'; retrying
ноя 20 13:48:00.046 [Info] _connection_free(): Freeing linked Directory connection [client reading] with 0 bytes on inbuf, 0 on outbuf.
---
What's wrong with finding certificates? (Outpost Firewall shows, that all in/out connections for Tor are OK.)
https://bridges.torproject.org couldn't help:
---
ноя 20 13:55:30.593 [Notice] Tor v0.2.0.31 (r16744). This is experimental software. Do not rely on it for strong anonymity. (Running on Windows XP Service Pack 2 [workstation] {terminal services, single user})
ноя 20 13:55:30.703 [Notice] Initialized libevent version 1.4.7-stable using method win32. Good.
ноя 20 13:55:30.703 [Notice] Opening Socks listener on 127.0.0.1:9050
ноя 20 13:55:30.703 [Notice] Opening Control listener on 127.0.0.1:9051
ноя 20 13:55:30.921 [Notice] I learned some more directory information, but not enough to build a circuit: We have no network-status consensus.
ноя 20 13:55:41.875 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
ноя 20 13:55:52.093 [Info] circuit_n_conn_done(): or_conn failed. Closing circ.
ноя 20 13:55:52.093 [Info] connection_ap_fail_onehop(): Closing onehop stream to '$4A0CCD2DDC7995083D73F5D667100C8A5831F16D/82.94.251.206' because the OR conn just failed.
ноя 20 13:55:52.093 [Info] connection_ap_fail_onehop(): Closing onehop stream to '$4A0CCD2DDC7995083D73F5D667100C8A5831F16D/82.94.251.206' because the OR conn just failed.
ноя 20 13:55:52.093 [Info] connection_ap_fail_onehop(): Closing onehop stream to '$4A0CCD2DDC7995083D73F5D667100C8A5831F16D/82.94.251.206' because the OR conn just failed.
ноя 20 13:55:52.093 [Info] _connection_free(): Freeing linked Socks connection [waiting for circuit] with 99 bytes on inbuf, 0 on outbuf.
ноя 20 13:55:52.093 [Info] _connection_free(): Freeing linked Socks connection [waiting for circuit] with 99 bytes on inbuf, 0 on outbuf.
ноя 20 13:55:52.093 [Info] _connection_free(): Freeing linked Socks connection [waiting for circuit] with 99 bytes on inbuf, 0 on outbuf.
ноя 20 13:55:52.093 [Info] connection_dir_client_reached_eof(): 'fetch' response not all here, but we're at eof. Closing.
ноя 20 13:55:52.093 [Info] connection_dir_request_failed(): Giving up on directory server at '82.94.251.206'; retrying
ноя 20 13:55:52.093 [Info] _connection_free(): Freeing linked Directory connection [client reading] with 0 bytes on inbuf, 0 on outbuf.
ноя 20 13:55:52.093 [Info] connection_dir_client_reached_eof(): 'fetch' response not all here, but we're at eof. Closing.
ноя 20 13:55:52.093 [Info] connection_dir_request_failed(): Giving up on directory server at '82.94.251.206'; retrying
ноя 20 13:55:52.093 [Info] _connection_free(): Freeing linked Directory connection [client reading] with 0 bytes on inbuf, 0 on outbuf.
ноя 20 13:55:52.093 [Info] connection_dir_client_reached_eof(): 'fetch' response not all here, but we're at eof. Closing.
ноя 20 13:55:52.093 [Info] connection_dir_request_failed(): Giving up on directory server at '82.94.251.206'; retrying
ноя 20 13:55:52.093 [Info] _connection_free(): Freeing linked Directory connection [client reading] with 0 bytes on inbuf, 0 on outbuf.
ноя 20 13:55:52.875 [Info] should_delay_dir_fetches(): delaying dir fetches (no running bridges known)
---
"ноя" means NOVember in russian.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Voidhttps://gitlab.torproject.org/tpo/core/tor/-/issues/872Endless loop of requests if broken resolves.2020-06-27T14:10:06ZTracEndless loop of requests if broken resolves.Client to ignore all DNS answers with local addresses by default (v 0.2.0.32).
However, it lead connection_edge_process_end_not_open() to
endless loop of connections attempt (connection_ap_detach_retriable())
via the same exit, if relay ...Client to ignore all DNS answers with local addresses by default (v 0.2.0.32).
However, it lead connection_edge_process_end_not_open() to
endless loop of connections attempt (connection_ap_detach_retriable())
via the same exit, if relay cell (END_STREAM_REASON_EXITPOLICY)
contains local addresses.
Attached some ideas of fix.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rovvTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/873compile error - compat.c: In function `tor_lockfile_lock'2020-06-27T14:10:06ZTraccompile error - compat.c: In function `tor_lockfile_lock'#:/usr/local/lib/tor-0.2.1.7-alpha>
#:/usr/local/lib/tor-0.2.1.7-alpha> ./configure --with-libevent-dir=/opt/csw \
> --with-tor-user=tor \
> --with-tor-group=guest \
> --enable-eventdn \
> ...#:/usr/local/lib/tor-0.2.1.7-alpha>
#:/usr/local/lib/tor-0.2.1.7-alpha> ./configure --with-libevent-dir=/opt/csw \
> --with-tor-user=tor \
> --with-tor-group=guest \
> --enable-eventdn \
> --sysconfdir=/home/tor
checking for a BSD-compatible install... /opt/sfw/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/sfw/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
configure: You are running Solaris; Sometimes threading makes
cpu workers lock up here, so I will disable threads.
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking whether make sets $(MAKE)... (cached) yes
checking for ranlib... ranlib
checking for win32... no
checking for MIPSpro compiler... no
checking for grep that handles long lines and -e... /usr/sfw/bin/ggrep
checking for egrep... /usr/sfw/bin/ggrep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking whether byte ordering is bigendian... no
checking for library containing socket... -lsocket
checking for library containing gethostbyname... -lnsl
checking for library containing dlopen... none required
checking for library containing inet_aton... -lresolv
checking for gettimeofday... yes
checking for ftime... yes
checking for socketpair... yes
checking for uname... yes
checking for inet_aton... yes
checking for strptime... yes
checking for getrlimit... yes
checking for strlcat... yes
checking for strlcpy... yes
checking for strtoull... yes
checking for ftello... yes
checking for getaddrinfo... yes
checking for localtime_r... yes
checking for gmtime_r... yes
checking for memmem... no
checking for strtok_r... yes
checking for inet_pton... yes
checking for inet_ntop... yes
checking for writev... yes
checking for readv... yes
checking for mallinfo... no
checking for malloc_good_size... no
checking for malloc_usable_size... no
checking for sys/types.h... (cached) yes
checking for u_int64_t... no
checking for u_int32_t... no
checking for u_int16_t... no
checking for u_int8_t... no
checking for libevent directory... /opt/csw
checking whether we need extra options to link libevent... (none)
checking for event_get_version... yes
checking for event_get_method... yes
checking for event_set_log_callback... yes
checking for openssl directory... /usr/local/ssl
checking whether we need extra options to link openssl... (none)
checking for zlib directory... (system)
checking whether we need extra options to link zlib... (none)
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... 64
checking for unistd.h... (cached) yes
checking for string.h... (cached) yes
checking signal.h usability... yes
checking signal.h presence... yes
checking for signal.h... yes
checking ctype.h usability... yes
checking ctype.h presence... yes
checking for ctype.h... yes
checking for sys/stat.h... (cached) yes
checking for sys/types.h... (cached) yes
checking fcntl.h usability... yes
checking fcntl.h presence... yes
checking for fcntl.h... yes
checking sys/fcntl.h usability... yes
checking sys/fcntl.h presence... yes
checking for sys/fcntl.h... yes
checking sys/time.h usability... yes
checking sys/time.h presence... yes
checking for sys/time.h... yes
checking errno.h usability... yes
checking errno.h presence... yes
checking for errno.h... yes
checking assert.h usability... yes
checking assert.h presence... yes
checking for assert.h... yes
checking time.h usability... yes
checking time.h presence... yes
checking for time.h... yes
checking netdb.h usability... yes
checking netdb.h presence... yes
checking for netdb.h... yes
checking sys/ioctl.h usability... yes
checking sys/ioctl.h presence... yes
checking for sys/ioctl.h... yes
checking sys/socket.h usability... yes
checking sys/socket.h presence... yes
checking for sys/socket.h... yes
checking arpa/inet.h usability... yes
checking arpa/inet.h presence... yes
checking for arpa/inet.h... yes
checking netinet/in.h usability... yes
checking netinet/in.h presence... yes
checking for netinet/in.h... yes
checking pwd.h usability... yes
checking pwd.h presence... yes
checking for pwd.h... yes
checking grp.h usability... yes
checking grp.h presence... yes
checking for grp.h... yes
checking sys/un.h usability... yes
checking sys/un.h presence... yes
checking for sys/un.h... yes
checking sys/uio.h usability... yes
checking sys/uio.h presence... yes
checking for sys/uio.h... yes
checking for stdint.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for inttypes.h... (cached) yes
checking sys/param.h usability... yes
checking sys/param.h presence... yes
checking for sys/param.h... yes
checking sys/wait.h usability... yes
checking sys/wait.h presence... yes
checking for sys/wait.h... yes
checking limits.h usability... yes
checking limits.h presence... yes
checking for limits.h... yes
checking sys/limits.h usability... no
checking sys/limits.h presence... no
checking for sys/limits.h... no
checking for netinet/in.h... (cached) yes
checking for arpa/inet.h... (cached) yes
checking machine/limits.h usability... no
checking machine/limits.h presence... no
checking for machine/limits.h... no
checking syslog.h usability... yes
checking syslog.h presence... yes
checking for syslog.h... yes
checking for sys/time.h... (cached) yes
checking sys/resource.h usability... yes
checking sys/resource.h presence... yes
checking for sys/resource.h... yes
checking for inttypes.h... (cached) yes
checking utime.h usability... yes
checking utime.h presence... yes
checking for utime.h... yes
checking sys/utime.h usability... yes
checking sys/utime.h presence... yes
checking for sys/utime.h... yes
checking sys/mman.h usability... yes
checking sys/mman.h presence... yes
checking for sys/mman.h... yes
checking netinet/in6.h usability... no
checking netinet/in6.h presence... no
checking for netinet/in6.h... no
checking malloc.h usability... yes
checking malloc.h presence... yes
checking for malloc.h... yes
checking sys/syslimits.h usability... no
checking sys/syslimits.h presence... no
checking for sys/syslimits.h... no
checking malloc/malloc.h usability... no
checking malloc/malloc.h presence... no
checking for malloc/malloc.h... no
checking linux/types.h usability... no
checking linux/types.h presence... no
checking for linux/types.h... no
checking sys/file.h usability... yes
checking sys/file.h presence... yes
checking for sys/file.h... yes
checking malloc_np.h usability... no
checking malloc_np.h presence... no
checking for malloc_np.h... no
checking for declaration of malloc_good_size... no
checking for net/if.h... yes
checking for net/pfvar.h... no
checking for linux/netfilter_ipv4.h... no
configure: Transparent proxy support enabled, but missing headers.
checking for _LARGEFILE_SOURCE value needed for large files... no
checking for struct timeval.tv_sec... yes
checking for int8_t... yes
checking size of int8_t... 1
checking for int16_t... yes
checking size of int16_t... 2
checking for int32_t... yes
checking size of int32_t... 4
checking for int64_t... yes
checking size of int64_t... 8
checking for uint8_t... yes
checking size of uint8_t... 1
checking for uint16_t... yes
checking size of uint16_t... 2
checking for uint32_t... yes
checking size of uint32_t... 4
checking for uint64_t... yes
checking size of uint64_t... 8
checking for intptr_t... yes
checking size of intptr_t... 4
checking for uintptr_t... yes
checking size of uintptr_t... 4
checking for char... yes
checking size of char... 1
checking for short... yes
checking size of short... 2
checking for int... yes
checking size of int... 4
checking for long... yes
checking size of long... 4
checking for long long... yes
checking size of long long... 8
checking for __int64... no
checking size of __int64... 0
checking for void *... yes
checking size of void *... 4
checking for time_t... yes
checking size of time_t... 4
checking for size_t... yes
checking size of size_t... 4
checking for uint... yes
checking for u_char... yes
checking for ssize_t... yes
checking for struct in6_addr... yes
checking for struct sockaddr_in6... yes
checking for struct sockaddr_storage... yes
checking for sa_family_t... yes
checking for struct in6_addr.s6_addr32... no
checking for struct in6_addr.s6_addr16... no
checking for rlim_t... yes
checking whether time_t is signed... yes
checking for socklen_t... yes
checking size of socklen_t... 4
checking for cell_t... no
checking size of cell_t... 0
checking whether memset(0) sets pointers to NULL... yes
checking whether we can malloc(0) safely.... yes
checking whether we are using 2s-complement arithmetic... yes
checking whether to use dmalloc (debug memory allocation library)... no
checking for getresuid... no
checking for getresgid... no
checking for gethostbyname_r... yes
checking how many arguments gethostbyname_r() wants... 5
checking whether the C compiler supports __func__... yes
checking whether the C compiler supports __FUNC__... no
checking whether the C compiler supports __FUNCTION__... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating tor.spec
config.status: creating Doxyfile
config.status: creating contrib/tor.sh
config.status: creating contrib/torctl
config.status: creating contrib/torify
config.status: creating contrib/tor.logrotate
config.status: creating contrib/Makefile
config.status: creating contrib/osx/Makefile
config.status: creating contrib/osx/TorBundleDesc.plist
config.status: creating contrib/osx/TorBundleInfo.plist
config.status: creating contrib/osx/TorDesc.plist
config.status: creating contrib/osx/TorInfo.plist
config.status: creating contrib/osx/TorStartupDesc.plist
config.status: creating src/config/torrc.sample
config.status: creating doc/tor.1
config.status: creating src/Makefile
config.status: creating doc/Makefile
config.status: creating doc/design-paper/Makefile
config.status: creating doc/spec/Makefile
config.status: creating src/config/Makefile
config.status: creating src/common/Makefile
config.status: creating src/or/Makefile
config.status: creating src/win32/Makefile
config.status: creating src/tools/Makefile
config.status: creating contrib/suse/Makefile
config.status: creating contrib/suse/tor.sh
config.status: creating orconfig.h
config.status: executing depfiles commands
#:/usr/local/lib/tor-0.2.1.7-alpha>
#:/usr/local/lib/tor-0.2.1.7-alpha> gmake
gmake all-recursive
gmake[1]: Entering directory `/usr/local/lib/tor-0.2.1.7-alpha'
Making all in src
gmake[2]: Entering directory `/usr/local/lib/tor-0.2.1.7-alpha/src'
Making all in common
gmake[3]: Entering directory `/usr/local/lib/tor-0.2.1.7-alpha/src/common'
gcc -DHAVE_CONFIG_H -I. -I../.. -I../common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -MT address.o -MD -MP -MF .deps/address.Tpo -c -o address.o address.c
mv -f .deps/address.Tpo .deps/address.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -MT log.o -MD -MP -MF .deps/log.Tpo -c -o log.o log.c
mv -f .deps/log.Tpo .deps/log.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -MT util.o -MD -MP -MF .deps/util.Tpo -c -o util.o util.c
mv -f .deps/util.Tpo .deps/util.Po
gcc -DHAVE_CONFIG_H -I. -I../.. -I../common -I/opt/csw/include -I/usr/local/ssl/include -g -O2 -Wall -g -O2 -MT compat.o -MD -MP -MF .deps/compat.Tpo -c -o compat.o compat.c
compat.c: In function `tor_lockfile_lock':
compat.c:509: warning: implicit declaration of function `flock'
compat.c:509: error: `LOCK_EX' undeclared (first use in this function)
compat.c:509: error: (Each undeclared identifier is reported only once
compat.c:509: error: for each function it appears in.)
compat.c:509: error: `LOCK_NB' undeclared (first use in this function)
compat.c: In function `tor_lockfile_unlock':
compat.c:538: error: `LOCK_UN' undeclared (first use in this function)
compat.c: In function `log_credential_status':
compat.c:955: warning: unsigned int format, uid_t arg (arg 5)
compat.c:955: warning: unsigned int format, uid_t arg (arg 6)
compat.c:973: warning: unsigned int format, gid_t arg (arg 5)
compat.c:973: warning: unsigned int format, gid_t arg (arg 6)
gmake[3]: *** [compat.o] Error 1
gmake[3]: Leaving directory `/usr/local/lib/tor-0.2.1.7-alpha/src/common'
gmake[2]: *** [all-recursive] Error 1
gmake[2]: Leaving directory `/usr/local/lib/tor-0.2.1.7-alpha/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/usr/local/lib/tor-0.2.1.7-alpha'
gmake: *** [all] Error 2
#:/usr/local/lib/tor-0.2.1.7-alpha>
[Automatically added by flyspray2trac: Operating System: Solaris]
**Trac**:
**Username**: ottohttps://gitlab.torproject.org/tpo/core/tor/-/issues/874Problem establishing new introduction points after reloading2020-06-27T14:10:06ZKarsten LoesingProblem establishing new introduction points after reloadingReported by Special (John Brooks) on #tor:
00:27:02 < Special> i've got an interesting looking bug here.
00:27:13 < Special> related to establishing hidden services
00:38:46 < Special> http://rafb.net/p/Dl4prP86.html <- hidden service i...Reported by Special (John Brooks) on #tor:
00:27:02 < Special> i've got an interesting looking bug here.
00:27:13 < Special> related to establishing hidden services
00:38:46 < Special> http://rafb.net/p/Dl4prP86.html <- hidden service introduction bug, seen at least after reload, haven't tested at startup.
00:38:51 < Special> on 0.2.1.7-alpha
00:41:23 < Special> 7 cycles of it were seen in roughly 12 seconds; every time except one it chose 'smafio' to cannibalize
http://rafb.net/p/Dl4prP86.html:
--------------------------------
This cycle repeats indefinitely after a reload, possibly all the time (unsure). Hidden service is not operable.
Hidden service replaced with 'aaaaaaaaaaaaaaaa'
Nodes used as introduction replaced with a unique 'SR-xxx' name
smafio ($6C0F99C574A739BD51698076B2C513182379689F) and Lifuka are not mentioned elsewhere, and have been preserved.
Nov 24 16:22:48.803 [info] rend_services_introduce(): Picked router SR-1 as an intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:48.803 [info] rend_services_introduce(): Picked router SR-2 as an intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:48.804 [info] rend_services_introduce(): Picked router SR-3 as an intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:48.804 [info] rend_services_introduce(): Picked router SR-4 as an intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:48.805 [info] rend_services_introduce(): Picked router SR-5 as an intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:48.805 [info] rend_service_launch_establish_intro(): Launching circuit to introduction point [scrubbed] for service aaaaaaaaaaaaaaaa
Nov 24 16:22:48.805 [debug] circuit_find_to_cannibalize(): Hunting for a circ to cannibalize: purpose 13, uptime 1, capacity 0, internal 1
Nov 24 16:22:48.805 [info] circuit_launch_by_extend_info(): Cannibalizing circ 'smafio' for purpose 13
Nov 24 16:22:48.805 [info] rend_service_launch_establish_intro(): The intro circuit we just cannibalized ends at $6C0F99C574A739BD51698076B2C513182379689F, but we requested an intro circuit to SR-1. Updating our service.
Nov 24 16:22:48.805 [info] rend_service_intro_has_opened(): We have just finished an introduction circuit, but we already have enough. Redefining purpose to general.
Nov 24 16:22:48.805 [info] rend_service_launch_establish_intro(): Launching circuit to introduction point [scrubbed] for service aaaaaaaaaaaaaaaa
Nov 24 16:22:48.805 [debug] circuit_find_to_cannibalize(): Hunting for a circ to cannibalize: purpose 13, uptime 1, capacity 0, internal 1
Nov 24 16:22:48.805 [info] circuit_launch_by_extend_info(): Cannibalizing circ 'smafio' for purpose 13
Nov 24 16:22:48.805 [info] rend_service_launch_establish_intro(): The intro circuit we just cannibalized ends at $6C0F99C574A739BD51698076B2C513182379689F, but we requested an intro circuit to SR-2. Updating our service.
Nov 24 16:22:48.805 [info] rend_service_intro_has_opened(): We have just finished an introduction circuit, but we already have enough. Redefining purpose to general.
Nov 24 16:22:48.806 [info] rend_service_launch_establish_intro(): Launching circuit to introduction point [scrubbed] for service aaaaaaaaaaaaaaaa
Nov 24 16:22:48.806 [debug] circuit_find_to_cannibalize(): Hunting for a circ to cannibalize: purpose 13, uptime 1, capacity 0, internal 1
Nov 24 16:22:48.806 [info] circuit_launch_by_extend_info(): Cannibalizing circ 'smafio' for purpose 13
Nov 24 16:22:48.806 [info] rend_service_launch_establish_intro(): The intro circuit we just cannibalized ends at $6C0F99C574A739BD51698076B2C513182379689F, but we requested an intro circuit to SR-3. Updating our service.
Nov 24 16:22:48.806 [info] rend_service_intro_has_opened(): We have just finished an introduction circuit, but we already have enough. Redefining purpose to general.
Nov 24 16:22:48.806 [info] rend_service_launch_establish_intro(): Launching circuit to introduction point [scrubbed] for service aaaaaaaaaaaaaaaa
Nov 24 16:22:48.806 [debug] circuit_find_to_cannibalize(): Hunting for a circ to cannibalize: purpose 13, uptime 1, capacity 0, internal 1
Nov 24 16:22:48.806 [info] circuit_launch_by_extend_info(): Cannibalizing circ 'smafio' for purpose 13
Nov 24 16:22:48.806 [info] rend_service_launch_establish_intro(): The intro circuit we just cannibalized ends at $6C0F99C574A739BD51698076B2C513182379689F, but we requested an intro circuit to SR-4. Updating our service.
Nov 24 16:22:48.806 [info] rend_service_intro_has_opened(): We have just finished an introduction circuit, but we already have enough. Redefining purpose to general.
Nov 24 16:22:48.806 [info] rend_service_launch_establish_intro(): Launching circuit to introduction point [scrubbed] for service aaaaaaaaaaaaaaaa
Nov 24 16:22:48.806 [debug] circuit_find_to_cannibalize(): Hunting for a circ to cannibalize: purpose 13, uptime 1, capacity 0, internal 1
Nov 24 16:22:48.807 [info] circuit_launch_by_extend_info(): Cannibalizing circ 'smafio' for purpose 13
Nov 24 16:22:48.807 [info] rend_service_launch_establish_intro(): The intro circuit we just cannibalized ends at $6C0F99C574A739BD51698076B2C513182379689F, but we requested an intro circuit to SR-5. Updating our service.
Nov 24 16:22:48.807 [info] rend_service_intro_has_opened(): We have just finished an introduction circuit, but we already have enough. Redefining purpose to general.
Nov 24 16:22:48.807 [info] rend_services_introduce(): Giving up on smafio as intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:48.807 [info] rend_services_introduce(): Giving up on smafio as intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:48.807 [info] rend_services_introduce(): Giving up on Lifuka as intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:48.807 [info] rend_services_introduce(): Giving up on smafio as intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:48.807 [info] rend_services_introduce(): Giving up on smafio as intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:48.886 [info] rend_services_introduce(): Picked router SR-6 as an intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:49.034 [info] rend_services_introduce(): Picked router SR-7 as an intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:49.167 [info] rend_services_introduce(): Picked router SR-8 as an intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:49.218 [info] rend_services_introduce(): Picked router SR-9 as an intro point for aaaaaaaaaaaaaaaa.
Nov 24 16:22:49.242 [info] rend_services_introduce(): Picked router SR-10 as an intro point for aaaaaaaaaaaaaaaa.
[Automatically added by flyspray2trac: Operating System: All]Karsten LoesingKarsten Loesinghttps://gitlab.torproject.org/tpo/core/tor/-/issues/877Vidalia don't open2020-06-27T14:10:06ZTracVidalia don't openVidalia Control Panel don't open completely and don't star Tor.When I make click in Vidalia(any button) the screem retorn white.Sistem Windows XP.
I will be wating for your help to make Tor works.Thank you.
[Automatically added by flys...Vidalia Control Panel don't open completely and don't star Tor.When I make click in Vidalia(any button) the screem retorn white.Sistem Windows XP.
I will be wating for your help to make Tor works.Thank you.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: GregorioAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/878Running out of RELAY_EARLY cells.2020-06-27T14:10:05ZAndrew LewmanRunning out of RELAY_EARLY cells.I wasn't even at my computer when this showed up in the log file:
Nov 29 13:10:06.102 [Warning] relay_send_command_from_edge(): Bug: Uh-oh. We're sending a RELAY_COMMAND_EXTEND cell, but we have run out o
f RELAY_EARLY cells on that cir...I wasn't even at my computer when this showed up in the log file:
Nov 29 13:10:06.102 [Warning] relay_send_command_from_edge(): Bug: Uh-oh. We're sending a RELAY_COMMAND_EXTEND cell, but we have run out o
f RELAY_EARLY cells on that circuit.
Nov 29 13:10:56.356 [Warning] relay_send_command_from_edge(): Bug: Uh-oh. We're sending a RELAY_COMMAND_EXTEND cell, but we have run out o
f RELAY_EARLY cells on that circuit.
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/880Parsing misuses -----END SIGNATURE----- tags2020-06-27T14:10:05ZNick MathewsonParsing misuses -----END SIGNATURE----- tagsSometimes[*] in parsing dir-spec documents, we look for the tag -----BEGIN SIGNATURE----- or -----END SIGNATURE-----
to find the end of the document or the boundary between two documents. This is wrong. There is nothing stopping a
perf...Sometimes[*] in parsing dir-spec documents, we look for the tag -----BEGIN SIGNATURE----- or -----END SIGNATURE-----
to find the end of the document or the boundary between two documents. This is wrong. There is nothing stopping a
perfectly valid document from containing an internal entity with an attached tag of type SIGNATURE.
We have two options:
- Change the spec so that signature objects are forbidden where not mandatory.
- Change the implementation so entries with signature objects are tolerated.
[*] We definitely do this for certificates and may do it for other things too.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/881stalled too much writing to 127.0.0.12020-06-27T14:10:05ZAndrew Lewmanstalled too much writing to 127.0.0.1I've seen this message twice, once while nothing was using Tor, another time while browsing the web via Tor.
[Notice] We stalled too much while trying to write 498 bytes to address "127.0.0.1". If this happens a lot, either som
ething ...I've seen this message twice, once while nothing was using Tor, another time while browsing the web via Tor.
[Notice] We stalled too much while trying to write 498 bytes to address "127.0.0.1". If this happens a lot, either som
ething is wrong with your network connection, or something is wrong with theirs. (fd 21, type Socks, state 11, marked at connection_edge.c:
99).
[Automatically added by flyspray2trac: Operating System: Other Linux]0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/882tor-devel crashes on startup2020-06-27T14:10:05ZTractor-devel crashes on startupThe latest test version of tor-devel-0.2.1.7-alpha is buggy on startup.
Because Linux users seems to have no problem, I assume this is a
special BSD bug.
Starting tor.
Dec 04 19:45:29.165 [notice] Tor v0.2.1.7-alpha (r17216). This is ex...The latest test version of tor-devel-0.2.1.7-alpha is buggy on startup.
Because Linux users seems to have no problem, I assume this is a
special BSD bug.
Starting tor.
Dec 04 19:45:29.165 [notice] Tor v0.2.1.7-alpha (r17216). This is experimental software. Do not rely on it for strong anonymity. (Running on FreeBSD i386)
Dec 04 19:45:29.168 [warn] You specified a public address '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.
Dec 04 19:45:29.172 [notice] Initialized libevent version 1.4.8-stable using method kqueue. Good.
Dec 04 19:45:29.173 [notice] Opening OR listener on 0.0.0.0:9001
Dec 04 19:45:29.173 [notice] Opening Socks listener on 0:9050
Dec 04 19:45:29.176 [warn] Error setting configured groups: Operation not permitted
Dec 04 19:45:29.177 [warn] Failed to parse/validate config: Problem with User value. See logs for details.
Dec 04 19:45:29.177 [err] Reading config failed--see warnings above.
In comparision to older versions of tor (e.g. 0.2.0.32, 0.2.1.5.alpha,
0.2.1.6.alpha) the last three lines never did occur.
Further, there are no 'logs for details' where I can see more infos. The
files debug.log and notices.log will be not created/touched.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: bsdtechiehttps://gitlab.torproject.org/tpo/core/tor/-/issues/883Tor doesn't publish the new IP address when it changes2020-06-27T14:10:05ZTracTor doesn't publish the new IP address when it changesI set up a Tor relay using "Tor v0.2.0.32 (r17346)" from Debian backports on Debian Etch (for some reason I can only
choose 0.2.0.31 from the menu above). This relay is running on a low end NAS on MIPSel hardware behind a NAT router
wh...I set up a Tor relay using "Tor v0.2.0.32 (r17346)" from Debian backports on Debian Etch (for some reason I can only
choose 0.2.0.31 from the menu above). This relay is running on a low end NAS on MIPSel hardware behind a NAT router
which gets a new IP address every 24h. It is configured not be an exit node and I don't have a directory server running.
I had no problems with the previous version 0.1.2.19 I compiled myself, that one worked and filled the assigned
bandwidth.
But with the current version the daemon does recognize that it is reachable with a new IP address, but it doesn't seem
to publish it. The port 9001 is reachable from the outside, the logfiles say so and I tested it with telnet. From the
logs I get:
Dec 03 06:28:15.017 [notice] Tor 0.2.0.32 (r17346) opening new log file.
Dec 03 17:23:38.755 [notice] Performing bandwidth self-test...done.
Dec 04 05:00:57.797 [notice] Your IP address seems to have changed to 92.227.177.214. Updating.
Dec 04 05:01:09.459 [notice] I learned some more directory information, but not enough to build a circuit: We have only 269/1132 usable descriptors.
Dec 04 05:01:10.668 [notice] We now have enough directory information to build circuits.
Dec 04 05:01:29.227 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 04 05:01:47.985 [notice] Performing bandwidth self-test...done.
Dec 04 06:28:15.747 [notice] Received reload signal (hup). Reloading config.
But although the log says "updating", it doesn't do so. Status pages like https://torstatus.blutmagie.de/ don't list
the server after a change of ip address. In the config file I used a CNAME for my dyndns hostname which does work and
resolves to the IP address that Tor detects.
When I restart the Tor service, evrerything is fine again, at startup it publishes the correct IP address, the Status
pages pick that up and I get the traffic according to the bandwith setting in my torrc.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: ultravelours0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/884NumCPUs not working2020-06-27T14:10:05ZTracNumCPUs not workingthe Version I use can't be selected here. Its 0.2.0.32 (r17346) (downloaded today on http://www.torproject.org/download-unix.html.de)
I tryed it 2 ways. First by installing Tor via Debian apt and setting "NumCPUs 4" and second by manual...the Version I use can't be selected here. Its 0.2.0.32 (r17346) (downloaded today on http://www.torproject.org/download-unix.html.de)
I tryed it 2 ways. First by installing Tor via Debian apt and setting "NumCPUs 4" and second by manualy building tor from the sources.
No way brings tor to spawn workers and use the cpu power for the other cores.
I think this is a heavy Performance Problem because today there are only multicore cpus for sale! Because of this
problem I have to start 4 instances of TOR in order to get the ressurces used.
Kernel Version: 2.6.27.4 x86_64
[Automatically added by flyspray2trac: Operating System: Other]
**Trac**:
**Username**: Mavehttps://gitlab.torproject.org/tpo/core/tor/-/issues/885Can't run more than 9 copies of TOR2020-06-27T14:10:04ZTracCan't run more than 9 copies of TORFirst 9 copies of tor running correctly (every copy have an own torrc file and TCP ports). But 10th running copy (and next) reporting an error:
... [warn] Error replacing old router store: Permission denied
... [err] Bug: routerlist.c:20...First 9 copies of tor running correctly (every copy have an own torrc file and TCP ports). But 10th running copy (and next) reporting an error:
... [warn] Error replacing old router store: Permission denied
... [err] Bug: routerlist.c:2093: signed_descriptor_get_body_impl: Assertion r failed; aborting.
routerlist.c:2093 signed_descriptor_get_body_impl: Assertion r failed; aborting.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: somenamehttps://gitlab.torproject.org/tpo/core/tor/-/issues/886Tor doesn't find any dns server address and dies.2020-06-27T14:10:04ZTracTor doesn't find any dns server address and dies.I am using Tor on Debian Etch.
By default the daemon is configured to start in runlevel 2 with S20tor.
When the system starts, there is a race condition of the daemons on the same run-level and if the daemon which is
responsible to updat...I am using Tor on Debian Etch.
By default the daemon is configured to start in runlevel 2 with S20tor.
When the system starts, there is a race condition of the daemons on the same run-level and if the daemon which is
responsible to update resolv.conf hasn't yet updated the file with the right dns ip addresses- this is
probably due to delay in polling the router for nameservers address and to race conditions,
tor dies.
At the moment I don't remember the name of the program which is responsible to update the above-mentioned file.
This is very annoying,because I often start the system and then I don't find the expected instance of tor running,
even if the resolv.conf is always correctly updated
For me it's better if the started instance of tor,keep polling the resolv.conf file at some rate,
and then after say 20 times,it dies.
Also moving the name of the file to something like S50tor seems to help partially as the problem seems just to slightly
decrease.(this confirm the race condition problem)
I attach the log output.
Output of tor --version: Tor version 0.2.0.31 (r16744).
Log:Dec 08 14:30:35.125 [notice] Tor 0.2.0.31 (r16744) opening log file.
Dec 08 14:30:35.168 [warn] eventdns: Unable to add nameserver 208.67.222.222: error 2
Dec 08 14:30:35.169 [warn] eventdns: Unable to add nameserver 208.67.220.220: error 2
Dec 08 14:30:35.169 [warn] Unable to parse '/etc/resolv.conf', or no nameservers in '/etc/resolv.conf' (6)
Dec 08 14:30:35.169 [err] Error initializing dns subsystem; exiting
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: maviorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/887relay starting with old consensus doesn't bootstrap for a long time2020-06-27T14:10:04ZRoger Dingledinerelay starting with old consensus doesn't bootstrap for a long timeI ran moria5 for a while in October. It worked fine then as a fast relay.
Now I start it up in December, and it can't bootstrap. It looks like it's
believing the IP addresses it found in the consensus.
It was missing ides's cert, so it...I ran moria5 for a while in October. It worked fine then as a fast relay.
Now I start it up in December, and it can't bootstrap. It looks like it's
believing the IP addresses it found in the consensus.
It was missing ides's cert, so it kept trying to fetch that, from random
relays listed in the consensus that were pretty much long dead.
Eventually it did bootstrap. It took 20 minutes or so. I'm not sure why;
I speculate it's because it found a working mirror.
I put the offending datadir in http://freehaven.net/~arma/moria5-broken-datadir.tar.gz
It would be good if somebody could pull that down and see if their svn trunk
also gets stuck at
Dec 16 19:50:06.089 [notice] Bootstrapped 10%: Finishing handshake with directory server.
Dec 16 19:50:06.732 [notice] Bootstrapped 15%: Establishing an encrypted directory connection.
Dec 16 19:52:07.098 [notice] No current certificate known for authority ides; launching request.
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/888Notice log flood on directory authority.2020-06-27T14:10:04ZJacob AppelbaumNotice log flood on directory authority.When attempting to start my new V3DirectoryAuthority, I have a flood of messages. I get about 700 lines that look like this (~10 per second):
Dec 17 03:14:05.954 [notice] I learned some more directory information, but not enough to buil...When attempting to start my new V3DirectoryAuthority, I have a flood of messages. I get about 700 lines that look like this (~10 per second):
Dec 17 03:14:05.954 [notice] I learned some more directory information, but not enough to build a circuit: We have only 217/1091 usable descriptors.
[Automatically added by flyspray2trac: Operating System: BSD]0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/889Race condition when freeing RSA keys.2020-06-27T14:10:04ZNick MathewsonRace condition when freeing RSA keys.There is no lock protecting the refcnt field of crypto_pk_env_t; this can cause keys to not get freed from within
cpuworker.c, or worse.
There are two ways to fix this: add a lock to each key that needs to be held when the key is modifi...There is no lock protecting the refcnt field of crypto_pk_env_t; this can cause keys to not get freed from within
cpuworker.c, or worse.
There are two ways to fix this: add a lock to each key that needs to be held when the key is modified, or add a
function to make a real honest-to-god copy of the key if we're going to be messing with the key's reference count
in two threads at once.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/891Uncertainty and redundant connections, if not actual router descriptor.2020-06-27T14:10:04ZTracUncertainty and redundant connections, if not actual router descriptor.Reported version: r17628
Relay does not always know the latest information on all relays of the network.
(And that's OK by itself)
If it serves as a cache, then delays to updating of information
is minimal.
Otherwise, they may be sub...Reported version: r17628
Relay does not always know the latest information on all relays of the network.
(And that's OK by itself)
If it serves as a cache, then delays to updating of information
is minimal.
Otherwise, they may be substantial, until the end update
because no builds of origin circuits. In a situation
use not up-to-date information within 48 hours
until removal from routerlist.
But uses non relevant information to create new
connections to replace the existing, can lead to creation of a
permanently redundant connection as well as uncertainty in the choice of
long-term connections between relays.
r17628, creates the conditions under which used non relevant information
and relays with dynamic ip-addresses, plus the use of v1 protocol
("certificates up-front") can lead to difficult detected problems, described
above.
To have to submit why this happens, we must take into account of clients,
which sends cell-extend. Those are also unable to synchronously download up-to-date
information. (and that's OK by itself)
(Here must be a description as can occur within minutes or hours
a continuous series of changes of conns, or simply one redudant)
(This is all really very simple to describe, but requires too many words
if no graphics, at least to my mind)
(If needed, I will still try to do it)
(Recorded and reported upon request by forest.)
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: rovv0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/893duplicate mark-for-close, connection_edge:4392020-06-27T14:10:04ZRoger Dingledineduplicate mark-for-close, connection_edge:439See http://freehaven.net/~arma/bug.gif
Reported by cswxcr on tor-volunteer on Nov 24.
[Automatically added by flyspray2trac: Operating System: All]See http://freehaven.net/~arma/bug.gif
Reported by cswxcr on tor-volunteer on Nov 24.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.33Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/894Tor behaves arrogant (ControlListenAddress)2020-06-27T14:10:04ZTracTor behaves arrogant (ControlListenAddress)When I set in torrc:
--
ControlPort 9051
ControlListenAddress 192.168.14.1:9051
--
Tor says:
--
Dec 25 17:57:38.866 [notice] Tor v0.2.0.31 (r16744). This is experimental software. Do not rely on it for strong anonymity. (Running on Linu...When I set in torrc:
--
ControlPort 9051
ControlListenAddress 192.168.14.1:9051
--
Tor says:
--
Dec 25 17:57:38.866 [notice] Tor v0.2.0.31 (r16744). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux i686)
Dec 25 17:57:38.897 [warn] You have a ControlListenAddress set to accept connections from a non-local address. This means that any program on the internet can reconfigure your Tor. That's so bad that I'm closing your ControlPort for you.
--
That's wrong.
1. 192.168.* is not the internet.
2. I am root. Programs do, what I want. Even if I decide to open a ControlPort on 0.0.0.0, tor has to follow my command. I am the almighty operator. Period. :-)
You could ask, why somebody would set the ControlListenAddress to a local network. The answer is simple: I am running some virtual machines on 192.168.14.*, they only see the host computer as 192.168.14.1 and nothing else. On these machines I want to use trans-proxy-tor, which needs to connect to the control port to work.
I have attached a patch.
Patch:
--- src/or/config.c.orig 2008-12-25 18:18:13.000000000 +0100
+++ src/or/config.c 2008-12-25 18:19:39.000000000 +0100
@@ -3216,8 +3216,7 @@
log_warn(LD_CONFIG, "You have a ControlListenAddress set to accept "
"connections from a non-local address. This means that "
"any program on the internet can reconfigure your Tor. "
- "That's so bad that I'm closing your ControlPort for you.");
- options->ControlPort = 0;
+ "That's pretty bad.");
} else {
log_warn(LD_CONFIG, "You have a ControlListenAddress set to accept "
"connections from a non-local address. This means that "
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: iblueNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/897crash when compiled with libevent 1.3e2020-06-27T14:10:03ZTraccrash when compiled with libevent 1.3ethe Tor process exits without a core dump or message in the log
if i compile it with libevent 1.3e
but works fine if i compile with libevent 1.4.8
software: tor-0.2.1.9-alpha
OS: xubuntu linux 8.10
hardware: Celeron 1.7GHz, 512MB RAM
co...the Tor process exits without a core dump or message in the log
if i compile it with libevent 1.3e
but works fine if i compile with libevent 1.4.8
software: tor-0.2.1.9-alpha
OS: xubuntu linux 8.10
hardware: Celeron 1.7GHz, 512MB RAM
configure line:
./configure --disable-iphone --enable-instrument-downloads --disable-largefile --enable-geoip-stats --enable-debug
log file:
Dec 27 21:41:24.804 [notice] Tor 0.2.1.9-alpha (r17777) opening log file.
Dec 27 21:41:24.852 [notice] Parsing GEOIP file.
Dec 27 21:41:25.843 [notice] Your Tor server's identity key fingerprint is 'cyblings01 A309 1FF0 545C 24A9 EA0D 87F5 FB7E 4098 DED0 C4FF'
Dec 27 21:41:36.432 [notice] We now have enough directory information to build circuits.
Dec 27 21:41:36.432 [notice] Bootstrapped 80%: Connecting to the Tor network.
Dec 27 21:41:36.610 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Dec 27 21:41:37.198 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 27 21:41:37.433 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Dec 27 21:41:38.988 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Dec 27 21:41:38.988 [notice] Bootstrapped 100%: Done.
i can attach a debug log and torrc file also if needed.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: kebhttps://gitlab.torproject.org/tpo/core/tor/-/issues/900Tor can't detect right IP2020-06-27T14:10:03ZTracTor can't detect right IPHi,
Tor sometimes cannot figure out the right IP address.
Below two extracts of the logfile.
I don't know when the IP usually changes but the manual of my provider says the IP will change once a day.
Setting:
- In my torrc I don't have...Hi,
Tor sometimes cannot figure out the right IP address.
Below two extracts of the logfile.
I don't know when the IP usually changes but the manual of my provider says the IP will change once a day.
Setting:
- In my torrc I don't have set the property "Address". (Didn't use it due to my misconfigured local caching DNS service.)
- OS is Ubuntu 8.04
The IP in line 1 is the correct one. The other IP is an old one which was given from my provider yesterday evening:
---snip---
Jan 01 18:01:05.463 [notice] Guessed our IP address as 84.189.106.167.
Jan 01 18:01:11.270 [notice] Our IP Address has changed from 84.189.106.167 to 84.189.109.75; rebuilding descriptor.
Jan 01 18:01:11.573 [notice] Our IP Address has changed from 84.189.109.75 to 84.189.106.167; rebuilding descriptor.
Jan 01 18:01:13.102 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jan 01 18:01:13.102 [notice] Now checking whether ORPort 84.189.106.167:65001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Jan 01 18:01:17.021 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jan 01 18:01:17.728 [notice] Our IP Address has changed from 84.189.106.167 to 84.189.109.75; rebuilding descriptor.
Jan 01 18:21:17.681 [warn] Your server (84.189.109.75:65001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.
---snap---
(I deleted some text from the logfile to make it short.)
Yesterday Tor "detected" also IP changes (which didn't occurr).
But yesterday the last detected change was the right one:
---snip---
Dec 31 21:35:31.981 [notice] Guessed our IP address as 84.189.109.75.
Dec 31 21:35:37.695 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Dec 31 21:35:37.695 [notice] Now checking whether ORPort 84.189.109.75:65001 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Dec 31 21:35:50.928 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 31 21:36:33.666 [notice] Our IP Address has changed from 84.189.109.75 to 84.189.64.90; rebuilding descriptor.
Dec 31 21:36:34.298 [notice] Our IP Address has changed from 84.189.64.90 to 84.189.109.75; rebuilding descriptor.
Dec 31 21:37:40.280 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 31 21:38:39.613 [notice] Performing bandwidth self-test...done.
Dec 31 21:56:53.884 [notice] Our IP Address has changed from 84.189.109.75 to 84.189.64.90; rebuilding descriptor.
Dec 31 21:57:40.471 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 31 22:08:04.792 [notice] Our IP Address has changed from 84.189.64.90 to 84.189.109.75; rebuilding descriptor.
Dec 31 22:08:07.394 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 31 22:09:06.998 [notice] Our IP Address has changed from 84.189.109.75 to 84.189.64.90; rebuilding descriptor.
Dec 31 22:10:08.520 [notice] Our IP Address has changed from 84.189.64.90 to 84.189.109.75; rebuilding descriptor.
Dec 31 22:10:10.362 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 31 22:10:11.790 [notice] Our IP Address has changed from 84.189.109.75 to 84.189.64.90; rebuilding descriptor.
Dec 31 22:21:00.810 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Dec 31 22:32:31.874 [notice] Our IP Address has changed from 84.189.64.90 to 84.189.109.75; rebuilding descriptor.
Dec 31 22:32:56.426 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
---snap---
Regards, Jörg
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: bonito0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/902It appears there is a bug in the intersection of the bandwidthrate and accoun...2020-06-27T14:10:03ZTracIt appears there is a bug in the intersection of the bandwidthrate and accountingmaxIt appears there is a bug in the intersection of the bandwidthrate and
accountingmax when set to ridiculously high levels (999 TB).
But perhaps also at lower settings (9 GB).
Jan 05 19:10:54.773 [notice] Configured hibernation. This ...It appears there is a bug in the intersection of the bandwidthrate and
accountingmax when set to ridiculously high levels (999 TB).
But perhaps also at lower settings (9 GB).
Jan 05 19:10:54.773 [notice] Configured hibernation. This interval began at 2009-01-05 12:21:00; the scheduled
wake-up time was 2009-01-05 12:21:00; we expect to exhaust our quota for this interval around 2009-01-06 12:21:00;
the next interval begins at 2009-01-06 12:21:00 (all times local)
Jan 05 19:12:10.984 [notice] Received reload signal (hup). Reloading config.
Jan 05 19:12:10.988 [notice] Tor 0.2.0.32 (r17346) opening log file.
AccountingStart day 12:21
AccountingMax 5 GB
BandwidthRate 20000
BandwidthBurst 21000
`Low traffic` is the result
20000*3600*24 is less than 5 GB?
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: udohttps://gitlab.torproject.org/tpo/core/tor/-/issues/903Crash when runnig as Service2020-06-27T14:10:03ZTracCrash when runnig as ServiceWhen used as a service it terminates unexpectantly with either error 1064 or 1067 without any warning.
This happends as the service tries to start, everytime.
Torrc found here : http://pastebin.com/f514929fb
When run as a regular progr...When used as a service it terminates unexpectantly with either error 1064 or 1067 without any warning.
This happends as the service tries to start, everytime.
Torrc found here : http://pastebin.com/f514929fb
When run as a regular program it doesn't get any errors.
The regular program and service uses the same torrc.
OS: win XP.
memory : 1GB
no other errors are registerd at or near the time the service stops.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: zerakhttps://gitlab.torproject.org/tpo/core/tor/-/issues/904When we fail to decrypt an onionskin, we never reply2020-06-27T14:10:03ZRoger DingledineWhen we fail to decrypt an onionskin, we never replyOn my bridge:
Jan 06 13:06:06.447 [debug] router_set_status(): Marking router 'moria1/128.31.0
.34' as up.
Jan 06 13:06:06.447 [debug] circuit_n_conn_done(): or_conn to moria1/128.31.0.34
, status=1
Jan 06 13:06:06.447 [debug] circuit_n...On my bridge:
Jan 06 13:06:06.447 [debug] router_set_status(): Marking router 'moria1/128.31.0
.34' as up.
Jan 06 13:06:06.447 [debug] circuit_n_conn_done(): or_conn to moria1/128.31.0.34
, status=1
Jan 06 13:06:06.447 [debug] circuit_n_conn_done(): Found circ, sending create ce
ll.
Jan 06 13:06:06.447 [debug] circuit_send_next_onion_skin(): First skin; sending
create cell.
Jan 06 13:06:06.449 [debug] circuit_deliver_create_cell(): Chosen circID 23991.
Jan 06 13:06:06.449 [debug] append_cell_to_circuit_queue(): Made a circuit activ
e.
Jan 06 13:06:06.449 [info] circuit_send_next_onion_skin(): First hop: finished s
ending CREATE cell to 'moria1'
Jan 06 13:06:06.449 [info] command_process_netinfo_cell(): Got good NETINFO cell
from 128.31.0.34; OR connection is now open, using protocol version 2
...
Jan 06 13:06:36.449 [info] circuit_expire_building(): Abandoning circ 128.31.0.3
4:9001:23991 (state 0:doing handshakes, purpose 5)
Jan 06 13:06:36.449 [info] exit circ (length 1, exit moria1): $FFCB46DB1339DA846
74C70D7CB586434C4370441(waiting for keys)
Jan 06 13:06:36.449 [info] circuit_build_failed(): Our circuit failed to get a r
esponse from the first hop (128.31.0.34:9001). I'm going to try to rotate to a b
etter connection.
Jan 06 13:06:36.449 [info] connection_ap_fail_onehop(): Closing onehop stream to
'$FFCB46DB1339DA84674C70D7CB586434C4370441/128.31.0.34' because the OR conn jus
t failed.
On moria1 at the same time:
Jan 06 13:06:06.447 [info] tor_tls_read(): Got a TLS renegotiation from "128.31.
0.34"
Jan 06 13:06:06.447 [info] command_process_versions_cell(): Negotiated version 2
with 128.31.0.34; sending NETINFO.
Jan 06 13:06:06.449 [info] command_process_netinfo_cell(): Got good NETINFO cell
from 128.31.0.34; OR connection is now open, using protocol version 2
Jan 06 13:06:06.491 [info] onion_skin_server_handshake(): Couldn't decrypt onion
skin: client may be using old onion key
Shouldn't moria1 be sending something back to indicate failure?
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/905ServerDNSRandomizeCase config option without effect2020-06-27T14:10:03ZTracServerDNSRandomizeCase config option without effectMy Tor exit gw always randomizes cases in dns queries. Setting "ServerDNSRandomizeCase 0" has no effect. I checked with
v0.2.1.8-alpha (r17523) and v0.2.1.10-alpha (r17969).
[Automatically added by flyspray2trac: Operating System: All]...My Tor exit gw always randomizes cases in dns queries. Setting "ServerDNSRandomizeCase 0" has no effect. I checked with
v0.2.1.8-alpha (r17523) and v0.2.1.10-alpha (r17969).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Falo0.2.1.11-alphaNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/906crash in getinfo_helper_dir <- handle_control_getinfo <- connection_control_p...2020-06-27T14:10:03ZTraccrash in getinfo_helper_dir <- handle_control_getinfo <- connection_control_process_inbufin version 0.1.2.19 (btw, please add more versions to the input box?)
(ubuntu 8.04 amd64, tor 0.1.2.19-2)
tor crashed:
#0 0x000000000042ba6f in getinfo_helper_dir (control_conn=<value optimized out>,
question=0x139a7f0 "dir/serve...in version 0.1.2.19 (btw, please add more versions to the input box?)
(ubuntu 8.04 amd64, tor 0.1.2.19-2)
tor crashed:
#0 0x000000000042ba6f in getinfo_helper_dir (control_conn=<value optimized out>,
question=0x139a7f0 "dir/server/fp/DCA644B81B06B83F86F6A76EC6974627380C6865", answer=0x7fff6a16a990) at control.c:1281
1281 control.c: No such file or directory.
in control.c
(gdb) bt
#0 0x000000000042ba6f in getinfo_helper_dir (control_conn=<value optimized out>,
question=0x139a7f0 "dir/server/fp/DCA644B81B06B83F86F6A76EC6974627380C6865", answer=0x7fff6a16a990) at control.c:1281
#1 0x0000000000430a1f in handle_control_getinfo (conn=0xc48730, len=<value optimized out>, body=<value optimized out>) at control.c:1618
legacy/trac#2 0x0000000000431cd1 in connection_control_process_inbuf (conn=0xc48730) at control.c:2449
legacy/trac#3 0x000000000042261f in connection_handle_read (conn=0xc48730) at connection.c:1465
legacy/trac#4 0x00000000004460a0 in conn_read_callback (fd=<value optimized out>, event=<value optimized out>, _conn=<value optimized out>) at main.c:422
legacy/trac#5 0x00007f416113bf41 in event_base_loop (base=0x6d5de0, flags=<value optimized out>) at event.c:331
legacy/trac#6 0x0000000000445ceb in tor_main (argc=1, argv=<value optimized out>) at main.c:1270
legacy/trac#7 0x00007f4160df11c4 in __libc_start_main () from /lib/libc.so.6
legacy/trac#8 0x00000000004068f9 in _start ()
I have the core file, if you need more info tell me what to write in gdb -c core etc
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: limcoretorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/907HardwareAccel isn't used2020-06-27T14:10:02ZTracHardwareAccel isn't usedLog shows me:
[info] crypto_global_init(): Initializing OpenSSL via tor_tls_init().
but crypto.c says:
if (useAccel < 0) {
log_info(LD_CRYPTO, "Initializing OpenSSL via tor_tls_init().");
}
if (useAccel > 0) {
l...Log shows me:
[info] crypto_global_init(): Initializing OpenSSL via tor_tls_init().
but crypto.c says:
if (useAccel < 0) {
log_info(LD_CRYPTO, "Initializing OpenSSL via tor_tls_init().");
}
if (useAccel > 0) {
log_info(LD_CRYPTO, "Initializing OpenSSL engine support.");
ENGINE_load_builtin_engines();
if (!ENGINE_register_all_complete())
return -1;
So no HardwareAccel even though torrc says:
HardwareAccel 1
This is Fedora 10 on VIA EK8000. Tor 0.2.0.32, built with source and spec from tor.eff site.
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]
**Trac**:
**Username**: udohttps://gitlab.torproject.org/tpo/core/tor/-/issues/911Authorities assign Running flag to hibernating relays?2020-06-27T14:10:02ZRoger DingledineAuthorities assign Running flag to hibernating relays?Mikeperry noted that it looks like authorities are assigning the Running
flag if a relay has been reachable within the past however many minutes,
even if the relay published its latest descriptor with "hibernating 1"
in it.
Even if so, ...Mikeperry noted that it looks like authorities are assigning the Running
flag if a relay has been reachable within the past however many minutes,
even if the relay published its latest descriptor with "hibernating 1"
in it.
Even if so, it isn't a big deal, since those latest descriptors will claim
a bandwidth of 0, and so clients will avoid them. But still, worth fixing
at some point.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/912Tor says "data cell dropped, unknown stream", no furter usage of Tor possible2020-06-27T14:10:02ZTracTor says "data cell dropped, unknown stream", no furter usage of Tor possibleIt is the third time this happens to me on this computer.
Tor was running all smooth on the computer, but today I am not able to connect to any website through Tor.
It looks pretty normal and Firefox already shows the favicon when out o...It is the third time this happens to me on this computer.
Tor was running all smooth on the computer, but today I am not able to connect to any website through Tor.
It looks pretty normal and Firefox already shows the favicon when out of nowhere Firefox acts
like someone pressed the reload button. The connection to the site is halted and then Firefox tries to reconnect.
This happens before the page content is rendered in the browser so I don't know how much data was already processed
till the reconnection happens.
At the same time this "reconnect" happens, the Tor log says:
[Info] connection_edge_process_relay_cell(): data cell dropped, unknown stream.
(about 30 times in a row on [Info] verbosity.
I've attached 2 logs. One at [Info] and one at [Debug]. In both cases, Tor was started through Vidalia.
After the onion went green (Tor was connected) I waited some seconds and tried to open blog.fefe.de in
Firefox (Fefes Blog was chosen because it consists of one large html page without pictures - beside the favicon).
Last time this problem occurred I had to do a clean reinstall of the Vidalia Bundle to make it disappear.
The problem occurred with different versions of the 2.1.x branch.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: knappohttps://gitlab.torproject.org/tpo/core/tor/-/issues/913panther compile warnings 0.2.1.11-alpha2020-06-27T14:10:02ZRoger Dingledinepanther compile warnings 0.2.1.11-alphaIn file included from container.c:14:
compat.h:257: warning: duplicate `const'
The line in question is DECLARE_CTYPE_FN()
Perhaps it is looking at this?
extern const uint32_t const TOR_##name##_TABLE[];
[Automatically added by flyspr...In file included from container.c:14:
compat.h:257: warning: duplicate `const'
The line in question is DECLARE_CTYPE_FN()
Perhaps it is looking at this?
extern const uint32_t const TOR_##name##_TABLE[];
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/915Directory authority retries parsing incorrect vote infinitely2020-06-27T14:10:02ZKarsten LoesingDirectory authority retries parsing incorrect vote infinitelyThis morning, I found gabelmoo filling its logs with these warnings
(info-level logs only included where it seemed useful):
Jan 22 11:19:46.397 [notice] Tor 0.2.1.11-alpha (r18193) opening log file.
[...]
Jan 23 01:50:01.080 [notice] Ti...This morning, I found gabelmoo filling its logs with these warnings
(info-level logs only included where it seemed useful):
Jan 22 11:19:46.397 [notice] Tor 0.2.1.11-alpha (r18193) opening log file.
[...]
Jan 23 01:50:01.080 [notice] Time to vote.
Jan 23 01:50:01.108 [notice] Choosing valid-after time in vote as 2009-01-23 01:00:00:
consensus_set=1, last_interval=3600
Jan 23 01:50:01.359 [notice] Vote posted.
Jan 23 01:50:19.559 [warn] Got a vote from an authority (nickname rgnx, address
208.83.223.34) with authority key ID 0F06AD141
ABB617AEA5A51663BB2F295DCB13521. This key ID is not recognized. Known v3 key IDs are: E2A2AF570166665D738736D0DD58169CC61D8A8B, 14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4, E8A9C45EDE6D711294FADF8E7951F4DE6CA56B58, 27B6B5996C426270A5C95488AA5BCEB6BCC86956, 81349FC1F2DBA2C2C11B45CB9706637D480AB913, 585769C78764D58426B8B52B6651A5A71137189A
Jan 23 01:50:59.743 [notice] Uploaded a vote to dirserver 80.190.246.100:80
Jan 23 01:50:59.866 [notice] Uploaded a vote to dirserver 194.109.206.212:80
Jan 23 01:51:00.072 [notice] Uploaded a vote to dirserver 128.31.0.34:9031
Jan 23 01:51:00.161 [notice] Uploaded a vote to dirserver 216.224.124.114:9030
Jan 23 01:51:12.885 [notice] Uploaded a vote to dirserver 86.59.21.38:80
Jan 23 01:52:31.246 [notice] Time to fetch any votes that we're missing.
Jan 23 01:52:31.246 [notice] We're missing votes from 2 authorities. Asking every other
authority for a copy.
Jan 23 01:52:31.452 [info] connection_dir_client_reached_eof(): Got votes (size 913169)
from server 86.59.21.38:80
Jan 23 01:52:31.508 [warn] Error decoding descriptor digest "UpcKF+KfBAgnHr+IyNP009-01-2"
Jan 23 01:52:31.522 [warn] Error reading network-status vote: signature does not match.
Jan 23 01:52:31.524 [warn] Couldn't parse vote: length was 457268
Jan 23 01:52:31.533 [warn] Error decoding descriptor digest "UpcKF+KfBAgnHr+IyNP009-01-2"
Jan 23 01:52:31.547 [warn] Error reading network-status vote: signature does not match.
Jan 23 01:52:31.548 [warn] Couldn't parse vote: length was 457268
Jan 23 01:52:31.557 [warn] Error decoding descriptor digest "UpcKF+KfBAgnHr+IyNP009-01-2"
Jan 23 01:52:31.571 [warn] Error reading network-status vote: signature does not match.
Jan 23 01:52:31.572 [warn] Couldn't parse vote: length was 457268
[...]
Jan 23 12:03:23.635 [warn] Error decoding descriptor digest "UpcKF+KfBAgnHr+IyNP009-01-2"
Jan 23 12:03:23.648 [warn] Error reading network-status vote: signature does not match.
Jan 23 12:03:23.650 [warn] Couldn't parse vote: length was 457268
This problem recurred at a rate of about 42 times per second (!) until I
killed it at 12:03. gabelmoo was unresponsive at that time: Tor weather
reported it couldn't ping it, gabelmoo didn't vote, and the Tor process had
to be killed with -9.
In the last votes that gabelmoo wrote (at 00:55), there is the correct line
that probably should have been parsed:
r Unnamed St3/Fe5maZRmmctLe/Mh9jU0rYk UpcKF+KfBAgnHr+IyNPOYbOzMCA 2009-01-22 13:10:15
99.21.76.207 9001 9030
The first question is where the ten characters # in
"UpcKF+KfBAgnHr+IyNP#########legacy/trac#9-01-2" went missing.
The second, and more important question is why gabelmoo tries to re-parse
the incorrect vote over and over again.
[Automatically added by flyspray2trac: Operating System: Other Linux]https://gitlab.torproject.org/tpo/core/tor/-/issues/9160.2.0.33 doesn't compile on FC8 64-bit2020-06-27T14:10:02ZRoger Dingledine0.2.0.33 doesn't compile on FC8 64-bitReported by John Thompson:
It won't compile for me here (Fedora8 64bit). tor-0.2.32 compiled fine,
however, and 0.2.0.33 built fine on my NetBSD box. See attached log.
In file included from buffers.c:17:
or.h: In function 'TO_OR_CONN'...Reported by John Thompson:
It won't compile for me here (Fedora8 64bit). tor-0.2.32 compiled fine,
however, and 0.2.0.33 built fine on my NetBSD box. See attached log.
In file included from buffers.c:17:
or.h: In function 'TO_OR_CONN':
or.h:1102: warning: implicit declaration of function 'log'
or.h:1102: warning: incompatible implicit declaration of built-in function 'log'
or.h:1102: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1102: error: (Each undeclared identifier is reported only once
or.h:1102: error: for each function it appears in.)
or.h:1102: error: 'LD_BUG' undeclared (first use in this function)
or.h:1102: error: too many arguments to function 'log'
or.h: In function 'TO_DIR_CONN':
or.h:1107: warning: incompatible implicit declaration of built-in function 'log'
or.h:1107: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1107: error: 'LD_BUG' undeclared (first use in this function)
or.h:1107: error: too many arguments to function 'log'
or.h: In function 'TO_EDGE_CONN':
or.h:1112: warning: incompatible implicit declaration of built-in function 'log'
or.h:1112: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1112: error: 'LD_BUG' undeclared (first use in this function)
or.h:1112: error: too many arguments to function 'log'
or.h: In function 'TO_CONTROL_CONN':
or.h:1117: warning: incompatible implicit declaration of built-in function 'log'
or.h:1117: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1117: error: 'LD_BUG' undeclared (first use in this function)
or.h:1117: error: too many arguments to function 'log'
or.h: In function 'TO_OR_CIRCUIT':
or.h:1945: warning: incompatible implicit declaration of built-in function 'log'
or.h:1945: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1945: error: 'LD_BUG' undeclared (first use in this function)
or.h:1945: error: too many arguments to function 'log'
or.h: In function 'TO_ORIGIN_CIRCUIT':
or.h:1950: warning: incompatible implicit declaration of built-in function 'log'
or.h:1950: error: 'LOG_ERR' undeclared (first use in this function)
or.h:1950: error: 'LD_BUG' undeclared (first use in this function)
or.h:1950: error: too many arguments to function 'log'
buffers.c: In function 'chunk_new_with_alloc_size':
buffers.c:174: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:174: error: 'LOG_ERR' undeclared (first use in this function)
buffers.c:174: error: 'LD_BUG' undeclared (first use in this function)
buffers.c:174: error: too many arguments to function 'log'
buffers.c: In function 'chunk_grow':
buffers.c:226: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:226: error: 'LOG_ERR' undeclared (first use in this function)
buffers.c:226: error: 'LD_BUG' undeclared (first use in this function)
buffers.c:226: error: too many arguments to function 'log'
buffers.c: In function 'buf_shrink_freelists':
buffers.c:271: warning: implicit declaration of function 'log_info'
buffers.c:271: error: 'LD_MM' undeclared (first use in this function)
buffers.c:275: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:275: error: 'LOG_ERR' undeclared (first use in this function)
buffers.c:275: error: 'LD_BUG' undeclared (first use in this function)
buffers.c:275: error: too many arguments to function 'log'
buffers.c:288: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:288: error: too many arguments to function 'log'
buffers.c: In function 'buf_dump_freelist_sizes':
buffers.c:306: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:306: error: 'LD_MM' undeclared (first use in this function)
buffers.c:306: error: too many arguments to function 'log'
buffers.c:317: error: too many arguments to function 'log'
buffers.c:320: error: too many arguments to function 'log'
buffers.c: In function 'buf_pullup':
buffers.c:373: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:373: error: 'LOG_ERR' undeclared (first use in this function)
buffers.c:373: error: 'LD_BUG' undeclared (first use in this function)
buffers.c:373: error: too many arguments to function 'log'
buffers.c:381: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:381: error: too many arguments to function 'log'
buffers.c:393: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:393: error: too many arguments to function 'log'
buffers.c:406: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:406: error: too many arguments to function 'log'
buffers.c:411: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:411: error: too many arguments to function 'log'
buffers.c: In function 'buf_remove_from_front':
buffers.c:431: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:431: error: 'LOG_ERR' undeclared (first use in this function)
buffers.c:431: error: 'LD_BUG' undeclared (first use in this function)
buffers.c:431: error: too many arguments to function 'log'
buffers.c:433: warning: incompatible implicit declaration of built-in function '
log'
buffers.c:433: error: too many arguments to function 'log'
...
[Automatically added by flyspray2trac: Operating System: Fedora Core Linux]0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/917Nameserver probes can give strange results2020-06-27T14:10:02ZNick MathewsonNameserver probes can give strange resultsWe should not actually retry nameserver probes, nor should we _ever_ reattach them to a new nameserver after
clear and resume.
Fortunately, the worst that happens here now is that we erroneously mark a down nameserver as up, retry it,
...We should not actually retry nameserver probes, nor should we _ever_ reattach them to a new nameserver after
clear and resume.
Fortunately, the worst that happens here now is that we erroneously mark a down nameserver as up, retry it,
fail, and mark it down again. Still, that's pretty ugly.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/tpo/core/tor/-/issues/918bind to port 443 + wake from hibernation = exit2020-06-27T14:10:01ZRoger Dingledinebind to port 443 + wake from hibernation = exit<ioerror> Jan 28 22:05:50.644 [notice] Opening OR listener on 80.68.85.45:443
<ioerror> Jan 28 22:05:50.644 [warn] Could not bind to 80.68.85.45:443:
+Permission denied
<ioerror> Jan 28 22:05:50.645 [warn] Failed to parse/validate config...<ioerror> Jan 28 22:05:50.644 [notice] Opening OR listener on 80.68.85.45:443
<ioerror> Jan 28 22:05:50.644 [warn] Could not bind to 80.68.85.45:443:
+Permission denied
<ioerror> Jan 28 22:05:50.645 [warn] Failed to parse/validate config: Failed
+to bind one of the listener ports.
Basically if you bind to port 443 directly, and then drop privs, that's fine.
When you hup, Tor will (should) correctly decide to leave that port alone since
it hasn't changed and it wouldn't be able to bind it again anyway.
But when we hibernate, and then come back, we can't bind it. Currently we die.
Option one, never close it in this case. Not great, since we want to be hibernating,
but not awful.
Option two, keep a separate root process around that can jumpstart Tor again. Ugh.
Option three, warn if this configuration is used, so the user can at least know.
How do we auto detect that it's a privileged port? Just "port < 1024"?
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/919If you hup tor while it's hibernating, it rebinds its ports2020-06-27T14:10:01ZRoger DingledineIf you hup tor while it's hibernating, it rebinds its portsIt looks like retry_listeners() and retry_all_listeners() do not care
whether we're hibernating. In main.c, retry-all-listeners is only called if
if (!we_are_hibernating() && time_to_check_listeners < now) {
whereas in config.c it do...It looks like retry_listeners() and retry_all_listeners() do not care
whether we're hibernating. In main.c, retry-all-listeners is only called if
if (!we_are_hibernating() && time_to_check_listeners < now) {
whereas in config.c it does not check if we_are_hibernating. Sounds like that's
the place to fix it.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/920don't bundle libevent with Tor2020-06-27T14:10:01ZTracdon't bundle libevent with TorHi,
I am the maintainer of Tor in Gentoo Linux and we have an open report in our issues tracker: http://bugs.gentoo.org/show_bug.cgi?id=206969
The report states that the asynchronous DNS part of libevent is bundled with Tor, which is t...Hi,
I am the maintainer of Tor in Gentoo Linux and we have an open report in our issues tracker: http://bugs.gentoo.org/show_bug.cgi?id=206969
The report states that the asynchronous DNS part of libevent is bundled with Tor, which is true (see src/or/evendns.{c,h}). This gives our security team and myself a headache as a security problem found in libevent has to be tracked in all messages that bundle it or just only parts. Please remove that bit and try to bring your modifications upstream to libevent if needed.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: V-Lipost 0.2.1.xhttps://gitlab.torproject.org/tpo/core/tor/-/issues/921clients avoid *all* authority types when avoiding any2020-06-27T14:10:01ZRoger Dingledineclients avoid *all* authority types when avoiding anyClients doing directory fetches avoid authorities of all types when trying
to avoid authorities of any type. So a client asking for a v3 consensus will
never ask moria2, because moria2 is an authority of some type. Similarly,
caches want...Clients doing directory fetches avoid authorities of all types when trying
to avoid authorities of any type. So a client asking for a v3 consensus will
never ask moria2, because moria2 is an authority of some type. Similarly,
caches wanting a v3 consensus won't ask moria2, because it's not a v3
authority. Same goes for Tonga, our bridge authority.
See
is_trusted = router_digest_is_trusted_dir(status->identity_digest);
in router_pick_directory_server_impl() in routerlist.c
We should instead ask if it's a trusted dir for the type of authority
we're wondering about.
[Automatically added by flyspray2trac: Operating System: All]post 0.2.1.xhttps://gitlab.torproject.org/tpo/core/tor/-/issues/922Problem upgrading to Tor stable Version 0.2.0.332020-06-27T14:10:01ZTracProblem upgrading to Tor stable Version 0.2.0.33I need some assistance please. I am a basic computer user but I have been
able to install Tor which I have been using daily for months now. My OS is
MacOsx Panther 10.3.9 and the Tor bundle installed is 0.2.0.31. The OS is
being operat...I need some assistance please. I am a basic computer user but I have been
able to install Tor which I have been using daily for months now. My OS is
MacOsx Panther 10.3.9 and the Tor bundle installed is 0.2.0.31. The OS is
being operated from an external HD.
I am no longer able to upgrade to the latest Tor versions (0.2.0.33) because
as soon as I open the installer package of the new version I get the error
message:
The Installer package "vidalia-bundle - 0.2.0.33-0.10-ppc" cannot be
opened.
The Bill of Materials for this package was not found.
I have tried several times with the same result. I have tried
deleting the previous Tor, Privoxy and Vidalia (0.2.0.31) before
I install the new version but I still get the error message.In
another Tor forum I was advised to report this as a possible bug.
I have always upgraded to new stable versions of Tor this way.
The install.log shows only:
Feb 5 08:08:25 localhost : Vidalia - Tor - Privoxy - Torbutton Bundle Installation Log
Feb 5 08:08:25 localhost : Opened from: /Volumes/vidalia-bundle-0.2.0.33-0.1.10-ppc/vidalia-bundle-0.2.0.33-0.1.10-ppc.mpkg
Feb 5 08:08:25 localhost : Hardware Model: PowerMac6,4 @ 1249 MHz, 1024 MB
Feb 5 08:08:25 localhost : Running OS Build: 7W98
Feb 5 08:08:25 localhost : Installer Language: English
Thank you
Louis
[Automatically added by flyspray2trac: Operating System: OSX 10.3 Panther]
**Trac**:
**Username**: LouisAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/923Tor software exited unexpectedly2020-06-27T14:10:01ZTracTor software exited unexpectedlyTor does not start
Vadilia detected that the Tor software exited unexpectedly
Error from libevent: evsignal_init: socketpair: No error
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: serbaTor does not start
Vadilia detected that the Tor software exited unexpectedly
Error from libevent: evsignal_init: socketpair: No error
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: serbahttps://gitlab.torproject.org/tpo/core/tor/-/issues/925Tor fails badly when accept(2) returns EMFILE or ENFILE2022-10-11T23:41:00ZriastradhTor fails badly when accept(2) returns EMFILE or ENFILEIf accept(2) in connection_handle_listener_read returns EMFILE or
ENFILE, Tor logs a failure and returns to the event loop. The
listening socket remains ready for reading, however, so that Tor again
tries to accept a connection. This l...If accept(2) in connection_handle_listener_read returns EMFILE or
ENFILE, Tor logs a failure and returns to the event loop. The
listening socket remains ready for reading, however, so that Tor again
tries to accept a connection. This leads to tens of thousands of
logged failures per second. Here is an excerpt from my syslog:
Feb 11 05:57:36 Tor[20415]: accept failed: Too many open files. Dropping incoming connection.
Feb 11 05:57:54 last message repeated 301536 times
Feb 11 05:57:54 Tor[20415]: Failing because we have 1765 connections already. Please raise your ulimit -n.
Feb 11 05:57:54 Tor[20415]: accept failed: Too many open files. Dropping incoming connection.
Feb 11 05:58:05 last message repeated 184158 times
Feb 11 05:58:05 Tor[20415]: Failing because we have 1765 connections already. Please raise your ulimit -n.
Feb 11 05:58:05 Tor[20415]: accept failed: Too many open files. Dropping incoming connection.
Feb 11 05:58:13 last message repeated 127556 times
Feb 11 05:58:13 Tor[20415]: Failing because we have 1765 connections already. Please raise your ulimit -n.
Feb 11 05:58:13 Tor[20415]: accept failed: Too many open files. Dropping incoming connection.
Feb 11 05:58:26 last message repeated 223556 times
Feb 11 05:58:26 Tor[20415]: Failing because we have 1765 connections already. Please raise your ulimit -n.
I don't know what the right thing to do here is, but spiking the CPU
and spraying log messages is not a very graceful mode of failure. One
way to mitigate the damage might be to close the listening socket,
which I believe won't be reopened until a minute later. This is no
worse for the Tor network than just wedging, and perhaps better, since
prospective connectors would be refused rather than silently forgotten
in a flurry of furious logging.
Also, it would be nice to document the number of file descriptors
generally required by a Tor relay, or a formula for computing it. For
example, is it proportional to the bandwidth and to the number of
relays in the Tor network? Or to the bandwidth and to the number of
users in the Tor network? This way, prospective operators of Tor
relays would not need to repeatedly restart their relays as they test
incremental bumps in the file descriptor ulimits, unless there is some
way to bump them without restarting the relay (but I doubt whether
there is).
(Apologies if this is duplicated: I hit !^A while editing this, in order
to move to the beginning of the line, but the obnoxious !@#!^%&%!^& web
form [and my obnoxiously colluding web browser] interpreted it to mean
something else for which I quickly hit the stop button. I don't know
what hitting !^A actually did.)
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/927Tor silently dies since v0.2.0.332020-06-27T14:10:00ZTracTor silently dies since v0.2.0.33Tor worked just fine for ages, but unfortunately v0.2.0.32 was last version to work at all.
After upgrading to v0.2.0.33 and later to v0.2.0.34 tor just silently dies. So i forced to roll back to v0.2.0.32
All versions was installed as ...Tor worked just fine for ages, but unfortunately v0.2.0.32 was last version to work at all.
After upgrading to v0.2.0.33 and later to v0.2.0.34 tor just silently dies. So i forced to roll back to v0.2.0.32
All versions was installed as vidalia bundle on Windows 2000 Service Pack 4 server. Application log shows nothing about tor.
And tor own log dosn't help either. Below is two tor versions outputs, started from cmd line, so bundle config is not used.
v0.2.0.32 :
16:29:12
%%>>>H:\WinApp\TOR\Tor\tor
Feb 15 16:29:20.139 [notice] Tor v0.2.0.32 (r17346). This is experimental softwa
re. Do not rely on it for strong anonymity. (Running on Windows 2000 Service Pac
k 4 [server] {enterprise})
Feb 15 16:29:20.239 [notice] Configuration file "G:\Documents and Settings\Admin
istrator\Application Data\tor\torrc" not present, using reasonable defaults.
Feb 15 16:29:20.259 [notice] Initialized libevent version 1.4.7-stable using met
hod win32. Good.
Feb 15 16:29:20.259 [notice] Opening Socks listener on 127.0.0.1:9050
Feb 15 16:29:22.342 [warn] Please upgrade! This version of Tor (0.2.0.32) is obs
olete, according to the directory authorities. Recommended versions are: 0.2.0.3
3,0.2.0.34,0.2.1.11-alpha,0.2.1.12-alpha
Feb 15 16:29:25.236 [notice] We now have enough directory information to build c
ircuits.
Feb 15 16:29:30.974 [notice] Tor has successfully opened a circuit. Looks like c
lient functionality is working.
v0.2.0.32 :
16:30:10
%%>>>H:\WinApp\TOR\Tor\tor
Feb 15 16:31:07.153 [notice] Tor v0.2.0.34 (r18423). This is experimental softwa
re. Do not rely on it for strong anonymity. (Running on Windows 2000 Service Pac
k 4 [server] {enterprise})
Feb 15 16:31:07.243 [notice] Configuration file "G:\Documents and Settings\Admin
istrator\Application Data\tor\torrc" not present, using reasonable defaults.
Feb 15 16:31:07.293 [notice] Initialized libevent version 1.4.9-stable using met
hod win32. Good.
Feb 15 16:31:07.293 [notice] Opening Socks listener on 127.0.0.1:9050
16:31:08
%%>>>H:\WinApp\TOR\Tor\
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Pheamaphhttps://gitlab.torproject.org/tpo/core/tor/-/issues/928With BridgeRelay 1 and ORPort 0, things go bad2020-06-27T14:10:00ZRoger DingledineWith BridgeRelay 1 and ORPort 0, things go badA while ago Vidalia set my BridgeRelay to 1 but left my ORPort off. This
caused my Tor to make all sorts of weird decisions about what it would
contact, what it would fetch, etc. After a while my Tor became useless
because it didn't have...A while ago Vidalia set my BridgeRelay to 1 but left my ORPort off. This
caused my Tor to make all sorts of weird decisions about what it would
contact, what it would fetch, etc. After a while my Tor became useless
because it didn't have enough descriptors to make a circuit, and it didn't
care to get any more.
We fixed the Vidalia bug (I think), but if a user sets their config this
way they will end up sad. We should explore why this is, and tighten up
the checks inside Tor.
[Automatically added by flyspray2trac: Operating System: All]Tor: 0.2.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/929FAILURE to event_del (ev=0x9376e48) at event.c:8062020-06-27T14:10:00ZTracFAILURE to event_del (ev=0x9376e48) at event.c:806Feb 21 08:50:09.922 [notice] Tor v0.2.1.12-alpha-dev (r18582).
Crash on failure with event_del (event.c 806) involvement.
# gdb /usr/bin/tor /var/lib/tor/data/core.25599
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
L...Feb 21 08:50:09.922 [notice] Tor v0.2.1.12-alpha-dev (r18582).
Crash on failure with event_del (event.c 806) involvement.
# gdb /usr/bin/tor /var/lib/tor/data/core.25599
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /lib/libz.so.1...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /usr/lib/libevent-1.4.so.2...done.
Loaded symbols for /usr/lib/libevent-1.4.so.2
Reading symbols from /usr/lib/libssl.so.0.9.8...done.
Loaded symbols for /usr/lib/libssl.so.0.9.8
Reading symbols from /usr/lib/libcrypto.so.0.9.8...done.
Loaded symbols for /usr/lib/libcrypto.so.0.9.8
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/librt.so.1...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnss_nis.so.2...done.
Loaded symbols for /lib/libnss_nis.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `/usr/bin/tor --runasdaemon 1'.
Program terminated with signal 11, Segmentation fault.
[New process 25599]
[New process 25612]
#0 event_del (ev=0x9376e48) at event.c:806
806 event.c: No such file or directory.
in event.c
(gdb) bt
#0 event_del (ev=0x9376e48) at event.c:806
#1 0x080e2741 in request_finished (req=0x9376e10, head=<value optimized out>) at eventdns.c:616
legacy/trac#2 0xb7ea53ce in event_base_loop (base=0x81430a0, flags=0) at event.c:387
legacy/trac#3 0xb7ea55b4 in event_loop (flags=0) at event.c:463
legacy/trac#4 0x080a9d75 in do_main_loop () at main.c:1435
legacy/trac#5 0x080aa00f in tor_main (argc=3, argv=0xbfe03114) at main.c:2060
legacy/trac#6 0x080e650e in main (argc=Cannot access memory at address 0x1b
) at tor_main.c:30
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: xiando0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/930router_parse_entry_from_string (s=0x135 <Address 0x135 out of bounds>2020-06-27T14:10:00ZAndrew Lewmanrouter_parse_entry_from_string (s=0x135 <Address 0x135 out of bounds>gdb bt below. tor 0.2.0.34-stable does not have this issue.
Feb 22 18:48:53.906 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fab760756e0 (LWP 18369)]
0x00007f...gdb bt below. tor 0.2.0.34-stable does not have this issue.
Feb 22 18:48:53.906 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fab760756e0 (LWP 18369)]
0x00007fab74d11015 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007fab74d11015 in raise () from /lib/libc.so.6
#1 0x00007fab74d12b83 in abort () from /lib/libc.so.6
legacy/trac#2 0x00007fab74d57a80 in ?? () from /lib/libc.so.6
legacy/trac#3 0x00000000004ad39d in memarea_drop_all (area=0x21a47f0) at memarea.c:102
legacy/trac#4 0x0000000000493c64 in router_parse_entry_from_string (s=0x135 <Address 0x135 out of bounds>, end=0x9a8 <Address 0x9a8 out of bounds>, cache_copy=1,
allow_annotations=295, prepend_annotations=0x135 <Address 0x135 out of bounds>) at routerparse.c:1438
legacy/trac#5 0x0000000000494eb4 in router_parse_list_from_string (s=0x7fff7e093e38, eos=0x7fab75ec6357 "", dest=0x21ecb10, saved_location=SAVED_NOWHERE,
want_extrainfo=0, allow_annotations=0, prepend_annotations=0x7fff7e093f70 "@downloaded-at 2009-02-22 23:48:56\n@source \"194.105.99.31\"\n")
at routerparse.c:1061
legacy/trac#6 0x000000000048cf05 in router_load_routers_from_string (
s=0x7fab75ebc614 "router che 81.233.224.95 443 0 80\nplatform Tor 0.2.0.33 (r18212) on Linux i686\nopt protocols Link 1 2 Circuit 1\npublished 2009-02-22 21:26:03\nopt fingerprint D5F2 C65F 4131 A146 8D5B 67A8 838A 9B7E D8"..., eos=0x0, saved_location=SAVED_NOWHERE, requested_fingerprints=0x2264440,
descriptor_digests=1, prepend_annotations=0x7fff7e093f70 "@downloaded-at 2009-02-22 23:48:56\n@source \"194.105.99.31\"\n") at routerlist.c:3500
legacy/trac#7 0x0000000000447b16 in connection_dir_client_reached_eof (conn=0x21a9440) at directory.c:1376
legacy/trac#8 0x00000000004486de in connection_dir_reached_eof (conn=0x21a9440) at directory.c:2041
legacy/trac#9 0x000000000042bde8 in connection_handle_read (conn=0x21a9440) at connection.c:2909
legacy/trac#10 0x0000000000461bc0 in conn_read_callback (fd=<value optimized out>, event=<value optimized out>, _conn=<value optimized out>) at main.c:456
legacy/trac#11 0x00007fab75a4e67d in event_base_loop () from /usr/lib/libevent-1.3e.so.1
legacy/trac#12 0x00000000004617a6 in do_main_loop () at main.c:1435
legacy/trac#13 0x00000000004619f5 in tor_main (argc=1, argv=<value optimized out>) at main.c:2060
legacy/trac#14 0x00007fab74cfc466 in __libc_start_main () from /lib/libc.so.6
legacy/trac#15 0x0000000000407469 in _start ()
[Automatically added by flyspray2trac: Operating System: Other Linux]0.2.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/932Bridges report unbelievable numbers of clients2020-06-27T14:10:00ZKarsten LoesingBridges report unbelievable numbers of clientsDuring the evaluation of extra-info documents published by bridges it was
found that some bridges report unbelievable numbers of clients. As an
example, two subsequently published extra-info documents of the same bridge
look are as follo...During the evaluation of extra-info documents published by bridges it was
found that some bridges report unbelievable numbers of clients. As an
example, two subsequently published extra-info documents of the same bridge
look are as follows (* denotes removed parts). Here, the first extra-info
document is the first such document that was published by this bridge.
extra-info *
published 2008-10-28 17:20:32
geoip-start-time 2008-10-25 23:07:16
geoip-client-origins de=936,us=704,cn=664,it=288,fr=208,ru=192,gb=144,*
extra-info *
published 2008-10-29 09:20:33
geoip-start-time 2008-10-27 09:07:01
geoip-client-origins ae=8,bg=8,cn=8,cz=8,de=8,dk=8,es=8,hk=8,in=8,it=8,*
The same bridge was running as a relay before 2008-10-28 with the last
router descriptor published at around 2008-10-27 14:00:00.
A possible (and even likely) explanation for the high numbers of clients is
that these clients contacted the bridge back when it was running as a
relay. When being reconfigured to run as a bridge, the bridge did not clear
its geoip cache and counted the relay clients as bridge clients. Only when
clearing the cache on 2008-10-27 09:07:01, the relay clients were removed
from the cache.
A solution to the described problem is that bridges do not include geoip
information in their extra-info documents if they have published a router
descriptor within the past few days, e.g., 3 days. These 3 (or whatever
fits here) days ensure that clients do not know about the bridge as a relay
anymore, but only as a bridge. This prevents both overcounting and
unwantedly revealing information about relay usage.
There is another phenomenon of a bridge that publishes both router
descriptors and bridge descriptors at the same time. In fact, it's not
forbidden to set 'PublishServerDescriptor v2,v3,bridge'. However, this
defeats the point of counting only bridge clients and including them in
extra-info documents. Should this behavior be changed, so that nodes can
publish either router descriptors or bridge descriptors, but not both?
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalKarsten LoesingKarsten Loesing