Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-16T01:26:59Zhttps://gitlab.torproject.org/legacy/trac/-/issues/16651Tor fails to build on OpenBSD 5.8 due to libevent config options2020-06-16T01:26:59ZteorTor fails to build on OpenBSD 5.8 due to libevent config optionsCan we apply the patch in this thread?
http://lists.nycbug.org/pipermail/tor-bsd/2015-July/000328.htmlCan we apply the patch in this thread?
http://lists.nycbug.org/pipermail/tor-bsd/2015-July/000328.htmlTor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/33056Tor relays fail to understand /etc/resolv.conf ipv6 lines with % in them2020-06-13T15:50:23ZRoger DingledineTor relays fail to understand /etc/resolv.conf ipv6 lines with % in themWe had a relay operator on irc just now who has this line in their /etc/resolv.conf:
```
nameserver fe80::7e2ebdff:fe99:4cb9%enp2s0
```
Apparently this is a totally normal thing: the % indicates a link local name server.
Two more hints...We had a relay operator on irc just now who has this line in their /etc/resolv.conf:
```
nameserver fe80::7e2ebdff:fe99:4cb9%enp2s0
```
Apparently this is a totally normal thing: the % indicates a link local name server.
Two more hints that % is a standard thing:
* https://bugs.launchpad.net/ubuntu/+source/wide-dhcpv6/+bug/1620221 "The link local name servers should be suffixed with the scope, e.g. "%eth0"."
* https://tools.ietf.org/html/rfc4007#section-11 "to specify an IPv6 non-global address without ambiguity, an intended scope zone should be specified as well."
Tor is unable to handle this % syntax in a resolv.conf line:
```
Jan 25 17:03:00.171 [warn] eventdns: Unable to parse nameserver address fe80::7e2ebdff:fe99:4cb9%enp2s0
```
It's not as bad as it could be, because Tor skips that line and uses whatever other lines there are. But (a) maybe we're not doing as well as we can do, and (b) maybe there are situations where that's the only configured nameserver and everything works on the host except Tor doesn't.
I think technically this might be a libevent bug (aka missing feature), since it's libevent's evdns_base_nameserver_ip_add() which calls evutil_parse_sockaddr_port() which helpfully explains that
```
/* recognized formats are:
* [ipv6]:port
* ipv6
* [ipv6]
* ipv4:port
* ipv4
*/
```
none of which are the % syntax. But I will file it here as a Tor ticket, since it's a Tor bug too, and then we can figure out where best to fix it.Tor: 0.4.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/8415Use event_set_mem_functions2020-06-13T15:31:02ZNick MathewsonUse event_set_mem_functionsWe should use event_set_mem_functions so that Libevent also uses our memory allocation functions, as we do for openssl when we call CRYPTO_set_mem_ex_functions.We should use event_set_mem_functions so that Libevent also uses our memory allocation functions, as we do for openssl when we call CRYPTO_set_mem_ex_functions.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/legacy/trac/-/issues/26469tor on SunOS: [err] Error from libevent: evport.c:425: Assertion evpd->ed_pen...2020-06-13T15:27:02ZTractor on SunOS: [err] Error from libevent: evport.c:425: Assertion evpd->ed_pending[i] == fd failed in evport_del
```
Tor 0.3.3.7 (git-035a35178c92da94) running on SunOS with Libevent 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
```
(this error was also observed under tor 0.3.3.6 for about two weeks, no change with updat...
```
Tor 0.3.3.7 (git-035a35178c92da94) running on SunOS with Libevent 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
```
(this error was also observed under tor 0.3.3.6 for about two weeks, no change with updating to 0.3.3.7)
every 10-20 minutes (sometimes longer) the process crashes with:
```
[err] Error from libevent: evport.c:425: Assertion evpd->ed_pending[i] == fd failed in evport_del
```
Contrary to tor crashes no libevent stacktrace is provided in default output.
The OS-Project under which the Service is running should have sufficent fd-ulimits:
```
ulimit -n
65536
```
Service privileges for the running User are pretty standard:
```
privileges='basic,net_privaddr'
```
**Trac**:
**Username**: ruebezahlTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/24279configure libevent leaks2020-06-13T15:22:55ZAlex Xuconfigure libevent leaksbreaks build with "CFLAGS=-fsanitize=address". probably be better just to use pkg-config, but...breaks build with "CFLAGS=-fsanitize=address". probably be better just to use pkg-config, but...Tor: 0.3.2.x-finalAlex XuAlex Xuhttps://gitlab.torproject.org/legacy/trac/-/issues/24594Protocol warning: Expiring stuck OR connection to fd...2020-06-13T15:18:46ZDavid Gouletdgoulet@torproject.orgProtocol warning: Expiring stuck OR connection to fd...So in theory, this is at protocol warning so shouldn't too problematic but I think this worth looking at it. I've been seeing many of these on a test relay I have (capped at 200KB/s) using KIST scheduler: (redacting the relay addr/port):...So in theory, this is at protocol warning so shouldn't too problematic but I think this worth looking at it. I've been seeing many of these on a test relay I have (capped at 200KB/s) using KIST scheduler: (redacting the relay addr/port):
```
Expiring stuck OR connection to fd 380 (IP:PORT). (3747888 bytes to flush; 3000 seconds since last write)
```
This is pretty big, 3.7MB stuck in the `outbuf` of a connection. The `3000` seconds since last write means that `connection_handle_write_impl()` hasn't been called which is *very* surprising in the first place.
There are currently two ways for the handle write function to be called, either through the libevent `write_event` which is fired everytime the socket is *ready* to write (see this as `POLLLOUT` from poll()). Or, it is directly called from KIST scheduler when cells are put in the outbuf.
This is worrying because it means that KIST did in fact put 3.7MB of cells on the outbuf thinking the socket had its TCP buffer stable enough to put that data in but somehow none got written on the socket.
On possibility is that KIST flushed cells on the connection then tried to write it to the network, that didn't work, the TCP information of the socket is still intact and because KIST doesn't check for errors (#24449), nothing happened. Then, somehow, after those 3.7MB were put in the outbuf, the channel was never scheduled again for a write because KIST had no idea that anything was left in the outbuf from previous flush on the network.
So then it comes down to the `write_event` to write those cells flushed by KIST. Without having a `POLLOUT` event on the socket, nothing will happen so the question I have is how can this event was never fired up for 50 minutes? I kind of feel that the TCP timeout would have kicked in by then if there was really a problem... ? But also, that is a _long_ time for an idle connection?Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/21016Build break with libevent on CentOS 6.82020-06-13T15:04:36ZTracBuild break with libevent on CentOS 6.8The following error occurs on CentOS 6.8 with tor-0.2.9.7-rc:
checking for libevent directory... configure: WARNING: We found the libraries for libevent, but we could not find the C header files. You may need to install a devel package...The following error occurs on CentOS 6.8 with tor-0.2.9.7-rc:
checking for libevent directory... configure: WARNING: We found the libraries for libevent, but we could not find the C header files. You may need to install a devel package.
configure: WARNING: On most Redhat-based systems, you can get headers for libevent by installing the libevent-devel RPM package
configure: error: Missing headers; unable to proceed.
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
The correct RPM is installed:
Package libevent-devel-1.4.13-4.el6.x86_64 already installed and latest version
CentOS 6.8 built tor-0.2.8.9 without errors.
**Trac**:
**Username**: cheekyrotterhttps://gitlab.torproject.org/legacy/trac/-/issues/16648Libevent configuration doesn't use pkg-config2020-06-13T14:47:35ZTracLibevent configuration doesn't use pkg-configThis interferes with some packages/ports (e.g. OpenBSD's) because the system's libevent CFLAGS and LIBS aren't used.
Pkg-config would probably make the dev's lives easier, too. Because the project is dropping support for older libevent ...This interferes with some packages/ports (e.g. OpenBSD's) because the system's libevent CFLAGS and LIBS aren't used.
Pkg-config would probably make the dev's lives easier, too. Because the project is dropping support for older libevent versions, now's a good time.
Thoughts? Would this break any non-Unixy platforms?
**Trac**:
**Username**: mmccTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/15248autoconf: drop workarounds for libevent <1.32020-06-13T14:44:17ZNick Mathewsonautoconf: drop workarounds for libevent <1.3All of our checks for u_int_* in configure.ac are unneeded, since Libevent stopped littering its headers with those in 1.3.
Similarly, there are functions that we're checking for which libevent probably has unconditionally in all the ve...All of our checks for u_int_* in configure.ac are unneeded, since Libevent stopped littering its headers with those in 1.3.
Similarly, there are functions that we're checking for which libevent probably has unconditionally in all the versions we support.Tor: 0.2.7.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/11600Strange nameserver fail warning in Tor log2020-06-13T14:35:44Zs7rStrange nameserver fail warning in Tor logI am running an exit relay on Linux, my Tor version is 0.2.4.21
I checked the log and found this strange warnings:
Apr 24 15:14:07.000 [notice] Circuit handshake stats since last time: 91698/91698 TAP, 15988/15988 NTor.
Apr 24 17:40:45....I am running an exit relay on Linux, my Tor version is 0.2.4.21
I checked the log and found this strange warnings:
Apr 24 15:14:07.000 [notice] Circuit handshake stats since last time: 91698/91698 TAP, 15988/15988 NTor.
Apr 24 17:40:45.000 [warn] eventdns: All nameservers have failed
Apr 24 17:40:45.000 [notice] eventdns: Nameserver <ISP-resolver1>:53 is back up
Apr 24 18:01:51.000 [warn] eventdns: All nameservers have failed
Apr 24 18:01:51.000 [notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
Apr 24 18:01:52.000 [warn] eventdns: All nameservers have failed
Apr 24 18:01:53.000 [notice] eventdns: Nameserver <ISP-resolver1>:53 is back up
Apr 24 18:02:00.000 [warn] eventdns: All nameservers have failed
Apr 24 18:02:01.000 [notice] eventdns: Nameserver <ISP-resolver1>:53 is back up
Apr 24 18:02:01.000 [warn] eventdns: All nameservers have failed
Apr 24 18:02:01.000 [notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
Apr 24 19:46:22.000 [warn] eventdns: All nameservers have failed
Apr 24 19:46:22.000 [notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
Apr 24 20:46:25.000 [warn] eventdns: All nameservers have failed
Apr 24 20:46:25.000 [notice] eventdns: Nameserver <ISP-resolver2>:53 is back up
Apr 24 21:14:07.000 [notice] Heartbeat: Tor's uptime is 8 days 12:00 hours, with 13940 circuits open. I've sent 549.49 GB and received 543.20 GB.
So I thought it's the fault of the nameservers provided by the ISP. Fair enough, I have configured my own resolver on localhost (where the relay is running) using BIND 9.10 (latest stable) with dnssec-validation and everything. I thought I fixed it. After some time, I checked the logs again and:
Apr 24 23:26:03.000 [warn] eventdns: All nameservers have failed
Apr 24 23:26:03.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Apr 25 02:04:02.000 [warn] eventdns: All nameservers have failed
Apr 25 02:04:02.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Apr 25 02:04:03.000 [warn] eventdns: All nameservers have failed
Apr 25 02:04:04.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Apr 25 02:04:04.000 [warn] eventdns: All nameservers have failed
Apr 25 02:04:05.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Apr 25 02:04:06.000 [warn] eventdns: All nameservers have failed
Apr 25 02:04:06.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Apr 25 02:04:08.000 [warn] eventdns: All nameservers have failed
Apr 25 02:04:08.000 [notice] eventdns: Nameserver 127.0.0.1:53 is back up
Looks like its something Tor related. Why do I get this warning? Does this have any penalty on the performance or over the users who are using this node as an exit point? Should I just leave it alone as it works fine? From what I see nameservers fail and get back online immediately, fail and back on have same timestamp. Advices? Thanks in advance.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/3056surprising dns responses received from hosts that aren't our resolver2020-06-13T14:10:16ZTracsurprising dns responses received from hosts that aren't our resolverThis is my first ticket, so bear with me pls. On IRC "Sebastian" asked me to file a bug report
I'm using tor 2.2.25-alpha, vidalia 0.2.12
debian squeeze/wheezy, Linux kernel 2.6.38-2-686
I run a relay and allow all exit policies normal...This is my first ticket, so bear with me pls. On IRC "Sebastian" asked me to file a bug report
I'm using tor 2.2.25-alpha, vidalia 0.2.12
debian squeeze/wheezy, Linux kernel 2.6.38-2-686
I run a relay and allow all exit policies normally.
Run from residential cable modem, timewarner/brighthouse/roadrunner.
iptables and guarddog firewall with many recommended ports open.
this is my torrc:
# This file was generated by Tor; if you edit it, comments will not be preserved
# The old torrc file was renamed to torrc.orig.1 or similar, and Tor will ignore it
ContactInfo xxx
ControlPort 9051
DirPort 9030
HashedControlPassword 16:C87CFFBB8A7A0E6C60762C632961A38C9528FF12E165B8D691F55BE104
Log notice stdout
Nickname freeeveryone4ever
ORPort 9001
RelayBandwidthBurst 393216
RelayBandwidthRate 196608
my error msgs:
"eventdns: Address mismatch on received DNS packet. Apparent source was 10.10.7.2xx:5300"
I also get this msg every 10-30 mins: "[Warning] eventdns: All nameservers have failed" they come backup within a min or 2
also get this, for what it's worth:
"DNS Hijacking Detected - Tor detected that your DNS provider is providing false responses for domains that do not exist. Some ISPs and other DNS providers, such as OpenDNS, are known to do this in order to display their own search or advertising pages."
Tor seems to keep working, I just thought you'd want to know about these messages.
Thanks, freeeveryone4ever (also my relay name)
ps. let me know if you need more info.
**Trac**:
**Username**: freeeveryone4everTor: 0.3.2.x-finalNick MathewsonNick Mathewson