The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:10:14Zhttps://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/800Add the ability to operate as an exit enclave exclusively2020-06-27T14:10:12Zmicahmicah@torproject.orgAdd the ability to operate as an exit enclave exclusivelyI would like to setup exit enclaves for all of the public facing services that I manage. However, I would like
these exit enclaves to just be exit enclaves, and not be routing other tor traffic through them as an intermediary.
I want t...I would like to setup exit enclaves for all of the public facing services that I manage. However, I would like
these exit enclaves to just be exit enclaves, and not be routing other tor traffic through them as an intermediary.
I want to contribute to the tor network by routing tor network traffic, providing a bridge and an exit node, but I prefer
to separate these logically and topologically in our network and not bundle them together. This is especially true
because I've got multiple services in the same rack that are all configured identically that I would like each to
exit enclave for their services that they provide to the public, but not each individually be routing tor traffic as
intermediaries.
I would like to route tor traffic for others, but on a different box (and on a different network in some cases), but
not when I am exit enclaving.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://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**: ecotea