Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:58:18Zhttps://gitlab.torproject.org/legacy/trac/-/issues/447Directory information not kept up to date2020-06-13T13:58:18ZTracDirectory information not kept up to dateJun 05 23:14:10.928 [notice] Tor 0.1.2.14 opening log file.
Jun 05 23:14:11.096 [notice] Your Tor server's identity key fingerprint is 'dragon E710 B7B1 BCC6 5FEC E5BA 345C EC8B 81BE A216 318F'
Jun 05 23:14:11.526 [notice] I learned some...Jun 05 23:14:10.928 [notice] Tor 0.1.2.14 opening log file.
Jun 05 23:14:11.096 [notice] Your Tor server's identity key fingerprint is 'dragon E710 B7B1 BCC6 5FEC E5BA 345C EC8B 81BE A216 318F'
Jun 05 23:14:11.526 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:14:15.555 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jun 05 23:14:24.607 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:14:54.738 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:03.791 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:08.821 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:09.798 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:09.805 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 05 23:15:13.852 [notice] We now have enough directory information to build circuits.
Jun 05 23:15:18.839 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jun 05 23:15:40.795 [notice] Performing bandwidth self-test...done.
Jun 07 19:51:15.879 [notice] Our directory information is no longer up-to-date enough to build circuits.
Jun 07 19:55:29.929 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 20:25:53.705 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 20:56:31.611 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 21:26:57.203 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 21:57:27.637 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 22:27:53.741 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 22:58:24.316 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:28:55.848 [notice] I learned some more directory information, but not enough to build a circuit.
It stays stuck here until I poke it:
Jun 07 23:51:32.901 [notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Jun 07 23:51:46.292 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:17.430 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:31.504 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:32.514 [notice] I learned some more directory information, but not enough to build a circuit.
Jun 07 23:52:33.512 [notice] We now have enough directory information to build circuits.
Restarting works too. The time delay is usually about the same, just under 2 days. I don't know when this started happening, so I can't tell you if it's due to 0.1.2.14 or not.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: taral0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/486Allow non-admin users to install OS-X2009-01-06T17:28:50ZTracAllow non-admin users to install OS-XMost applications allow the option to install for current user or all users. I only install applications
as a non-admin user for security reasons. Would it be possible to all non-admin users to install vidalia?
[Automatically added by f...Most applications allow the option to install for current user or all users. I only install applications
as a non-admin user for security reasons. Would it be possible to all non-admin users to install vidalia?
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: Dodger0.2.1.x-finalAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/legacy/trac/-/issues/526Eventdns.c crash after closing and reopening ORPort2020-06-13T13:58:45ZNick MathewsonEventdns.c crash after closing and reopening ORPort[Originally reported by Mike Gersten; moving here so I don't forget about it.]
See or-dev thread from September-October titled "Tor crash", especially:
http://archives.seul.org/or/dev/Sep-2007/msg00031.html (initial post)
http://a...[Originally reported by Mike Gersten; moving here so I don't forget about it.]
See or-dev thread from September-October titled "Tor crash", especially:
http://archives.seul.org/or/dev/Sep-2007/msg00031.html (initial post)
http://archives.seul.org/or/dev/Sep-2007/msg00040.html (stack trace)
The circumstances were:
"I first shut down the Or-port, to try to let all connections close.
When it was time to actually say "Time to stop", I re-enabled the
Or-port, and then sent a sigint. (If I send sigint without first
re-enabling the or-port, Tor assumes that it should stop immediately,
without notifying the clients).
Tor crashed about a minute later. I don't know if it was related or not.
This is 1.2.17."
The stack trace was:
0 tor 0x00087c04 event_del + 44 (event.c:697)
1 tor 0x0006cdd4 nameserver_up + 84 (eventdns.c:533)
2 tor 0x0006cee0 reply_callback + 112 (eventdns.c:648)
3 tor 0x0006fc6c reply_handle + 684 (eventdns.c:740)
4 tor 0x000714cc nameserver_ready_callback + 1564
(eventdns.c:925)
5 tor 0x00087364 event_process_active + 240 (event.c:332)
6 tor 0x00087634 event_base_loop + 340 (event.c:448)
7 tor 0x000874cc event_loop + 40 (event.c:382)
8 tor 0x000873d0 event_dispatch + 20 (event.c:346)
9 tor 0x0004b8b0 tor_main + 656 (main.c:1270)
10 tor 0x0000277c _start + 760
11 tor 0x00002480 start + 48
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/532Do we use non-Running routers in scary places?2020-06-13T13:58:49ZRoger DingledineDo we use non-Running routers in scary places?Bringing this over from bug 529:
If we clear the flags for a given router yet don't delete the routerstatus
entry when we get a new consensus that doesn't list that router, is that
sufficient to make the client not use that router?
For...Bringing this over from bug 529:
If we clear the flags for a given router yet don't delete the routerstatus
entry when we get a new consensus that doesn't list that router, is that
sufficient to make the client not use that router?
For example, we ignore Running when posting to dir authorities.
For example, we might ignore Running when the client specifically asks for
a server, e.g. with the .exit notation.
(The original discussion also discussed the Valid flag, and wanted to make it
so you needed a Valid flag before you'd get used, on the theory that there
might be bugs with looking at the Running flag. But I think that's just
turtles all the way down. If there are bugs, we should fix them, not require
a second flag that might also have bugs.)
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/633Tor retries download for unparseable descriptors2020-06-13T13:59:32ZNick MathewsonTor retries download for unparseable descriptors15:14 <@diseasearma> hm. moria1 is starting to complain
15:14 <@diseasearma> Mar 18 15:00:15.261 [warn] Invalid uptime "-29903"
15:14 <@diseasearma> so is moria2, and my bridge relay.
15:15 <@diseasearma> that's not a very useful warning...15:14 <@diseasearma> hm. moria1 is starting to complain
15:14 <@diseasearma> Mar 18 15:00:15.261 [warn] Invalid uptime "-29903"
15:14 <@diseasearma> so is moria2, and my bridge relay.
15:15 <@diseasearma> that's not a very useful warning message.
15:15 <@diseasearma> Mar 18 15:15:35.895 [info]
connection_dir_client_reached_eof(): Received server
15:15 <@diseasearma> info (size 2471) from server '194.109.206.212:80'
15:16 <@diseasearma> is what prefaces it.
15:16 < nickm> seeing that on peacetime too
15:16 <@diseasearma> looks like my relays are going to dizum to get a
descriptor they don't have,
15:16 <@diseasearma> and it's a descriptor they don't want,
15:16 <@diseasearma> but then they go back again and get it again.
15:17 <@diseasearma> they go back once a minute
15:17 < nickm> looks like they're counting it as a download failure.
15:17 < nickm> there should be some way to mark it as perma-failed.
15:18 * nickm restarts peacetime on the 0.2.0 branch.
15:19 <@diseasearma> ok. we're going to see this come up on or-talk shortly.
15:20 <@diseasearma> i guess i could preemptively post saying it's a known
problem and will be solved 'later'.
15:20 < nickm> s/later/soon/
15:20 < nickm> we can even add a flyspray entry.
15:20 < nickm> s/we/I/
In summary, when we download a descriptor and then can't parse it, we need to remember to never try to download
it again. Also, our log message could be better.
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/691Tor relay fails on startup if network not up yet2020-06-13T13:59:58ZTracTor relay fails on startup if network not up yetThis applies to 0.2.0.26.
On Windows XP Home Edition, if the Tor Service is started while no network adapters are physically connected,
Tor will immediately crash.
szAppName: tor.exe
szModName: unknown
offset: 0022e7d0
Crash Dump Atta...This applies to 0.2.0.26.
On Windows XP Home Edition, if the Tor Service is started while no network adapters are physically connected,
Tor will immediately crash.
szAppName: tor.exe
szModName: unknown
offset: 0022e7d0
Crash Dump Attached.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: HANtwister0.2.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/727Bridges: tunnel to dirservers fail and Requested exit points not known closin...2020-06-13T14:00:05ZTracBridges: tunnel to dirservers fail and Requested exit points not known closing error messagesWhen running tor client 0.2.0.28-rc with Bridges enabled in torrc with the following modifed addtions to torrc:
TunnelDirConns 1
PreferTunneledDirConns 1
SafeLogging 0
UseBridges 1
(several bridge entries here, added from official tor ...When running tor client 0.2.0.28-rc with Bridges enabled in torrc with the following modifed addtions to torrc:
TunnelDirConns 1
PreferTunneledDirConns 1
SafeLogging 0
UseBridges 1
(several bridge entries here, added from official tor list of bridges at torproject dot org)
UpdateBridgesFromAuthority 1
I receive the following errors which repeat:
[warn] Making tunnel to dirserver failed.
Requested exit point '($fingerprint without brackets)' is not known. Closing.
While tor works with the torrc lines above using Bridges, I'm curious if tunneling dir connections is not working with
tor and bridges? When I use tor without bridge options enabled, the dirconections are tunneled, but I don't know if they
are or not with bridges and this error. I noticed this error in previous versions of tor (rc's) but I haven't reported it
until now, as I was unsure this was a bug and the kind people in #tor @ oftc.net IRC suggested I file a bug about this.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: toruser5550.2.1.x-finalRoger DingledineRoger Dingledinehttps://gitlab.torproject.org/legacy/trac/-/issues/752Unable to Specify Exit without Exit-flag in Domain Name2020-06-13T14:00:11ZTracUnable to Specify Exit without Exit-flag in Domain NameWhen attempting to access http://barkerjr.net.barkerjrhttp.exit , because:
[warn] Requested exit point 'barkerjrhttp' would refuse request. Closing.
This is in err, because the router's exit policy explicitly allows exiting to that host...When attempting to access http://barkerjr.net.barkerjrhttp.exit , because:
[warn] Requested exit point 'barkerjrhttp' would refuse request. Closing.
This is in err, because the router's exit policy explicitly allows exiting to that hostname's IP. However, because it
doesn't allow exits on *:80, it's rejected. Considering that the user thinks that exit will accept it, we should give
it a try even though it returns ADDR_POLICY_PROBABLY_REJECTED.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: BarkerJr0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/789Improperly bound listen addresses2020-06-13T14:00:19ZgrarpampImproperly 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 #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/legacy/trac/-/issues/794Another minor leak2020-06-13T14:00:21ZRoger 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/legacy/trac/-/issues/805choice of the best OR connection2020-06-13T14:00:26ZTracchoice 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/legacy/trac/-/issues/813Tor is unable to find my DNS and exits on startup2020-06-13T14:00:30ZTracTor 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/legacy/trac/-/issues/827Tor detects imaginary IP change2020-06-13T14:13:27ZTracTor 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/legacy/trac/-/issues/863Relay crashes OSX 10.3.92020-06-13T14:00:47ZTracRelay 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/legacy/trac/-/issues/878Running out of RELAY_EARLY cells.2020-06-13T14:00:54ZAndrew 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/legacy/trac/-/issues/881stalled too much writing to 127.0.0.12020-06-13T14:00:55ZAndrew 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/legacy/trac/-/issues/883Tor doesn't publish the new IP address when it changes2020-06-13T14:00:56ZTracTor 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/legacy/trac/-/issues/887relay starting with old consensus doesn't bootstrap for a long time2020-06-13T14:00:58ZRoger 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/legacy/trac/-/issues/888Notice log flood on directory authority.2020-06-13T14:00:58ZJacob 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/legacy/trac/-/issues/891Uncertainty and redundant connections, if not actual router descriptor.2020-06-13T14:00:59ZTracUncertainty 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/legacy/trac/-/issues/900Tor can't detect right IP2020-06-13T14:01:04ZTracTor 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/legacy/trac/-/issues/904When we fail to decrypt an onionskin, we never reply2020-06-13T14:01:06ZRoger 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/legacy/trac/-/issues/9160.2.0.33 doesn't compile on FC8 64-bit2020-06-13T14:01:11ZRoger 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/legacy/trac/-/issues/929FAILURE to event_del (ev=0x9376e48) at event.c:8062020-06-13T14:01:19ZTracFAILURE 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
#2 0xb7ea53ce in event_base_loop (base=0x81430a0, flags=0) at event.c:387
#3 0xb7ea55b4 in event_loop (flags=0) at event.c:463
#4 0x080a9d75 in do_main_loop () at main.c:1435
#5 0x080aa00f in tor_main (argc=3, argv=0xbfe03114) at main.c:2060
#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/legacy/trac/-/issues/930router_parse_entry_from_string (s=0x135 <Address 0x135 out of bounds>2020-06-13T14:01:22ZAndrew 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
#2 0x00007fab74d57a80 in ?? () from /lib/libc.so.6
#3 0x00000000004ad39d in memarea_drop_all (area=0x21a47f0) at memarea.c:102
#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
#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
#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
#7 0x0000000000447b16 in connection_dir_client_reached_eof (conn=0x21a9440) at directory.c:1376
#8 0x00000000004486de in connection_dir_reached_eof (conn=0x21a9440) at directory.c:2041
#9 0x000000000042bde8 in connection_handle_read (conn=0x21a9440) at connection.c:2909
#10 0x0000000000461bc0 in conn_read_callback (fd=<value optimized out>, event=<value optimized out>, _conn=<value optimized out>) at main.c:456
#11 0x00007fab75a4e67d in event_base_loop () from /usr/lib/libevent-1.3e.so.1
#12 0x00000000004617a6 in do_main_loop () at main.c:1435
#13 0x00000000004619f5 in tor_main (argc=1, argv=<value optimized out>) at main.c:2060
#14 0x00007fab74cfc466 in __libc_start_main () from /lib/libc.so.6
#15 0x0000000000407469 in _start ()
[Automatically added by flyspray2trac: Operating System: Other Linux]0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/932Bridges report unbelievable numbers of clients2020-06-13T14:01:23ZKarsten 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 Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/941circuit event lines sometimes miss verbose names2020-06-13T14:01:26ZRoger Dingledinecircuit event lines sometimes miss verbose namesIn my Vidalia logs
Mar 12 20:18:31.186 [notice] QtWarningMsg: torcontrol: Improperly formatted
circuit: '16 EXTENDED $5A583B838FDC22246E046E1D4E108F41EFBAD175'
edmanm:#vidalia> those circ events are spec compliant, but they're annoying
...In my Vidalia logs
Mar 12 20:18:31.186 [notice] QtWarningMsg: torcontrol: Improperly formatted
circuit: '16 EXTENDED $5A583B838FDC22246E046E1D4E108F41EFBAD175'
edmanm:#vidalia> those circ events are spec compliant, but they're annoying
since they don't include the nickname, even when you ask for verbose_names.
edmanm:#vidalia> i don't know why tor includes that with some circ events and
not others.
edmanm> when i say "usefeature verbose_names", tor gives me hops in circ
events as either "$id=nickname" for named relays or "$id~nickname" for
non-named relays.
edmanm> except in some cases, like the one you pasted above, all i get is
$id.
edmanm> that's the same format you get when you don't specify 'usefeature
verbose_names'. (i.e. just $id for non-named relays or just the nickname for
named relays)
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/948Crash on rendcommon.c:332020-06-13T14:01:28ZTracCrash on rendcommon.c:33Revision 19068. Crash. No log (latest "[notice] Performing bandwidth self-test...done.")
Core was generated by `/usr/bin/tor --runasdaemon 1'.
Program terminated with signal 11, Segmentation fault.
[New process 8760]
[New process 8775]
...Revision 19068. Crash. No log (latest "[notice] Performing bandwidth self-test...done.")
Core was generated by `/usr/bin/tor --runasdaemon 1'.
Program terminated with signal 11, Segmentation fault.
[New process 8760]
[New process 8775]
#0 0x080b89e3 in rend_service_descriptor_free (desc=0x86c9040) at rendcommon.c:33
33 SMARTLIST_FOREACH(desc->successful_uploads, char *, c, tor_free(c););
(gdb) bt
#0 0x080b89e3 in rend_service_descriptor_free (desc=0x86c9040) at rendcommon.c:33
#1 0x080bef73 in rend_consider_services_upload (now=1237319764) at rendservice.c:545
#2 0x080a9774 in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1086
#3 0xb7f1c3ce in event_base_loop (base=0x81430b0, flags=0) at event.c:387
#4 0xb7f1c5b4 in event_loop (flags=0) at event.c:463
#5 0x080a9db5 in do_main_loop () at main.c:1435
#6 0x080aa04f in tor_main (argc=3, argv=0xbfd7b284) at main.c:2060
#7 0x080e67e6 in main (argc=Cannot access memory at address 0x11
) at tor_main.c:30
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: xiando0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/957v0.2.1.13-alpha crashing2020-06-13T14:01:36ZTracv0.2.1.13-alpha crashingTor v0.2.1.13-alpha (r18828) on Debian Lenny x86_64
My Blutmagie server process died dumping a core file. gdb backtrace output refers to eventdns.
anonymizer2:~# gdb /usr/sbin/tor ~debian-tor/.tor/core.20793
GNU gdb 6.8-debian
Copyrigh...Tor v0.2.1.13-alpha (r18828) on Debian Lenny x86_64
My Blutmagie server process died dumping a core file. gdb backtrace output refers to eventdns.
anonymizer2:~# gdb /usr/sbin/tor ~debian-tor/.tor/core.20793
GNU gdb 6.8-debian
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 "x86_64-linux-gnu"...
warning: core file may not match specified executable file.
warning: Can't read pathname for load map: Input/output error.
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /usr/lib/libevent-1.3e.so.1...done.
Loaded symbols for /usr/lib/libevent-1.3e.so.1
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/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
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
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 6, Aborted.
[New process 20793]
[New process 20803]
[New process 20802]
[New process 20801]
[New process 20800]
[New process 20799]
[New process 20798]
[New process 20797]
[New process 20796]
[New process 20795]
[New process 20794]
#0 0x00007f99debe8ed5 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007f99debe8ed5 in raise () from /lib/libc.so.6
#1 0x00007f99debea3f3 in abort () from /lib/libc.so.6
#2 0x00007f99debe1dc9 in __assert_fail () from /lib/libc.so.6
#3 0x00007f99df91c453 in ?? () from /usr/lib/libevent-1.3e.so.1
#4 0x00007f99df91c734 in event_add () from /usr/lib/libevent-1.3e.so.1
#5 0x0000000000496922 in evdns_request_transmit (req=0x7f99d0acee00)
at eventdns.c:482
#6 0x000000000049716a in evdns_requests_pump_waiting_queue ()
at eventdns.c:2168
#7 0x000000000049769a in reply_handle (req=0x7f99d36b3c00,
flags=<value optimized out>, ttl=<value optimized out>,
reply=<value optimized out>) at eventdns.c:826
#8 0x0000000000497f47 in nameserver_read (ns=0x7f99dff4e800)
at eventdns.c:1031
#9 0x00007f99df91cec1 in event_base_loop () from /usr/lib/libevent-1.3e.so.1
#10 0x000000000045f606 in do_main_loop () at main.c:1435
#11 0x000000000045f855 in tor_main (argc=1, argv=<value optimized out>)
at main.c:2060
#12 0x00007f99debd51a6 in __libc_start_main () from /lib/libc.so.6
#13 0x0000000000407689 in _start ()
(gdb)
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: Falo0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/984Tor using forbidden nodes2020-06-13T14:01:56ZTracTor using forbidden nodesHello.
I have this in my torcc:
ExcludeNodes {us},{gb},{cn},{au}
but my log is showing this kind of lines:
[Warning] Requested exit node 'thegoddamnpenisblue' is in ExcludeNodes, or ExcludeExitNodes, using anyway.
[Warning] Requested exi...Hello.
I have this in my torcc:
ExcludeNodes {us},{gb},{cn},{au}
but my log is showing this kind of lines:
[Warning] Requested exit node 'thegoddamnpenisblue' is in ExcludeNodes, or ExcludeExitNodes, using anyway.
[Warning] Requested exit node 'userbw20prfpis' is in ExcludeNodes, or ExcludeExitNodes, using anyway.
I'm also running as a relay, but this happened also when I was running Tor as client-only.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: G-Lo0.2.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/1013DirPortFrontPage gets rate limited and goes silent2020-06-13T14:02:14ZRoger DingledineDirPortFrontPage gets rate limited and goes silenthttp://tor.sebastianhahn.net:443/ should say 'test', but instead it fails quietly
because the relay has hit its rate limits recently and doesn't want to waste any
bytes on frivolous directory stuff.
I think this is a bug, since people i...http://tor.sebastianhahn.net:443/ should say 'test', but instead it fails quietly
because the relay has hit its rate limits recently and doesn't want to waste any
bytes on frivolous directory stuff.
I think this is a bug, since people intentionally set DirPortFrontPage, so they
really do want their relay to serve that page when it's asked for. Having it
appear only sometimes (or roughly never in Sebastian's case) makes it way less
useful.
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-final