Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:07:43Zhttps://gitlab.torproject.org/legacy/trac/-/issues/21899Address setting ignoring IPv62020-06-13T15:07:43ZTracAddress setting ignoring IPv6According to the torrc man page:
"Address: The IP address or fully qualified domain name of this server (e.g. moria.mit.edu)."
In torrc, set the Address to an IPv6 address and port using standard notation:
Address [1234:5678::01:1234]...According to the torrc man page:
"Address: The IP address or fully qualified domain name of this server (e.g. moria.mit.edu)."
In torrc, set the Address to an IPv6 address and port using standard notation:
Address [1234:5678::01:1234]
----
The tor server starts up, and doesn't appear to give any relevant warnings, but log output suggests tor is ignoring the address setting and guessing anyway.
Apr 09 15:50:52.000 [notice] Guessed our IP address as 1.2.3.4 (source: 5.6.7.8).
This server is configured only with IPv6 settings for tor, and the goal is to have it ignore any IPv4 addresses present on the host, so this behavior is undesirable.
**Trac**:
**Username**: ItsNannerpussTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/20003Sandbox causing crash when setting HidServAuth2020-06-13T15:00:46ZsegfaultSandbox causing crash when setting HidServAuthI'm working on Tails Server and I'm currently implementing client authentication for it. When I use SETCONF to set the HidServAuth, or set it in the torrc and reload Tor, Tor crashes with this error message:
```
========================...I'm working on Tails Server and I'm currently implementing client authentication for it. When I use SETCONF to set the HidServAuth, or set it in the torrc and reload Tor, Tor crashes with this error message:
```
============================================================ T= 1472233872
(Sandbox) Caught a bad syscall attempt (syscall chmod)
/usr/bin/tor(+0x13d8bc)[0xf76a28bc]
/lib/i386-linux-gnu/libc.so.6(chmod+0x11)[0xf7141361]
/lib/i386-linux-gnu/libc.so.6(chmod+0x11)[0xf7141361]
/usr/bin/tor(+0x583bf)[0xf75bd3bf]
/usr/bin/tor(rend_service_load_all_keys+0x7f)[0xf75bf21f]
/usr/bin/tor(set_options+0xcc1)[0xf762d1f1]
/usr/bin/tor(options_trial_assign+0xc4)[0xf762e8c4]
/usr/bin/tor(+0xe7c83)[0xf764cc83]
/usr/bin/tor(connection_control_process_inbuf+0x981)[0xf76509f1]
/usr/bin/tor(+0xcecdd)[0xf7633cdd]
/usr/bin/tor(+0xd75a8)[0xf763c5a8]
/usr/bin/tor(+0x2f0a9)[0xf75940a9]
/usr/lib/i386-linux-gnu/libevent-2.0.so.5(event_base_loop+0x73d)[0xf748136d]
/usr/bin/tor(do_main_loop+0x27d)[0xf7594b0d]
/usr/bin/tor(tor_main+0x176d)[0xf7598a8d]
/usr/bin/tor(main+0x35)[0xf7591b35]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf7092723]
/usr/bin/tor(+0x2cb94)[0xf7591b94]
```https://gitlab.torproject.org/legacy/trac/-/issues/19800After install, launching tor from shell results in segfault2020-06-13T14:59:51ZTracAfter install, launching tor from shell results in segfaultI installed tor on CentOS Linux release 7.2.1511 (Core) with the packages from epel-release.
I then proceeded to configure the /etc/tor/torrc file, but i was not aware there was a service active so i tried launching tor from shell - see...I installed tor on CentOS Linux release 7.2.1511 (Core) with the packages from epel-release.
I then proceeded to configure the /etc/tor/torrc file, but i was not aware there was a service active so i tried launching tor from shell - seeing the RunAsDaemon directive.
This is not the expected behaviour, i should have been told there was a service already running.
[root@server ~]# tor
Aug 02 10:51:24.202 [notice] Tor v0.2.7.6 running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1e-fips and Zlib 1.2.7.
Aug 02 10:51:24.202 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Aug 02 10:51:24.202 [notice] Read configuration file "/etc/tor/torrc".
Aug 02 10:51:24.204 [notice] You configured a non-loopback address '10.0.0.20:9100' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Aug 02 10:51:24.204 [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.
Aug 02 10:51:24.204 [notice] Based on detected system memory, MaxMemInQueues is set to 2843 MB. You can override this by setting MaxMemInQueues by hand.
Aug 02 10:51:24.204 [notice] You configured a non-loopback address '10.0.0.20:9100' for SocksPort. This allows everybody on your local network to use your machine as a proxy. Make sure this is what you wanted.
Aug 02 10:51:24.204 [notice] Opening Socks listener on 127.0.0.1:9050
============================================================ T= 1470127884
Tor 0.2.7.6 died: Caught signal 11
tor(+0x12bb28)[0x7f6405597b28]
tor(retry_all_listeners+0x689)[0x7f640554a009]
tor(retry_all_listeners+0x689)[0x7f640554a009]
tor(set_options+0x1889)[0x7f640553f9a9]
tor(options_init_from_string+0x2d9)[0x7f64055404c9]
tor(options_init_from_torrc+0x1d7)[0x7f64055407f7]
tor(tor_init+0x2d4)[0x7f64054aab84]
tor(tor_main+0x55)[0x7f64054acc75]
tor(main+0x19)[0x7f64054a7809]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f6403aa6b15]
tor(+0x3b85d)[0x7f64054a785d]
Aborted
**Trac**:
**Username**: dmirtilloTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19518Configure argument --without-tcmalloc causes linking with libtcmalloc library2020-06-13T14:59:03Zyurivict271Configure argument --without-tcmalloc causes linking with libtcmalloc libraryOnly --with-tcmalloc should link with the library.
Please make sure that this and other --with-xxxx flags don't malfunction this way.Only --with-tcmalloc should link with the library.
Please make sure that this and other --with-xxxx flags don't malfunction this way.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19374DNSPort broken on OpenBSD 5.92020-06-13T14:58:36ZcypherpunksDNSPort broken on OpenBSD 5.9Hello,
I am unable to use DNSPort on OpenBSD. The syslog says the port has opened correctly, and I see it in netstat:
```
udp 0 0 localhost.10000 *.*
```
However, there is no "LISTEN" as you can see. And when I us...Hello,
I am unable to use DNSPort on OpenBSD. The syslog says the port has opened correctly, and I see it in netstat:
```
udp 0 0 localhost.10000 *.*
```
However, there is no "LISTEN" as you can see. And when I use nslookup, I get:
```
Abort trap (core dumped)
```
Also when I run a second instance with only DNSPort set to the same, this is the output:
```
Jun 10 17:14:31.857 [notice] Tor v0.2.7.6 running on OpenBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.3.2 and Zlib 1.2.3.
Jun 10 17:14:31.857 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jun 10 17:14:31.857 [notice] Read configuration file "/home/user/config".
Jun 10 17:14:31.860 [notice] Opening Socks listener on 127.0.0.1:9050
Jun 10 17:14:31.860 [notice] Opening DNS listener on 127.0.0.1:10000
Jun 10 17:14:31.860 [warn] Could not bind to 127.0.0.1:10000: Address already in use. Is Tor already running?
Jun 10 17:14:31.860 [notice] Closing partially-constructed Socks listener on 127.0.0.1:9050
Jun 10 17:14:31.860 [warn] Failed to parse/validate config: Failed to bind one of the listener ports.
Jun 10 17:14:31.860 [err] Reading config failed--see warnings above.
```Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19209torrc: Comments Need Clarifying2020-06-13T14:58:06ZTractorrc: Comments Need ClarifyingI've written a guide on how to set up a Tor relay, but I ran into some confusion from readers on some initial drafts on a few areas which I clarified on the final guide (see: https://motherboard.vice.com/read/how-you-can-help-make-tor-fa...I've written a guide on how to set up a Tor relay, but I ran into some confusion from readers on some initial drafts on a few areas which I clarified on the final guide (see: https://motherboard.vice.com/read/how-you-can-help-make-tor-faster-for-10-a-month). However, it'd be great to see some clarifications in the comments in /etc/tor/torrc.
Specifically...
Update:
## Uncomment this if you run more than one Tor relay, and add the identity
## key fingerprint of each Tor relay you control, even if they're on
## different networks. Include the "$" with each key ID.
Update:
## Don't forget the < and >.
#ContactInfo Random Person <nobody AT example dot com>
Update:
## A handle for your relay, so people don't have to refer to it by key.
## Only alphanumeric characters, A-Z, a-z, 0-1 allowed. No unicode, no emoji.
I assume this might be easy, but that it might trigger some package management systems to bug the user into asking which config they want if they already have the tor package installed.
**Trac**:
**Username**: huertanixTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19167torrc parsing b0rks on carriage-return2020-06-13T14:57:55Zcypherpunkstorrc parsing b0rks on carriage-returnWindows still terminates text files with '\r\n' by default, this seems to break the handling of quoted values in torrc.
https://gitweb.torproject.org/tor.git/tree/src/common/util.c#n2899
It consumes the quoted string, then consumes any...Windows still terminates text files with '\r\n' by default, this seems to break the handling of quoted values in torrc.
https://gitweb.torproject.org/tor.git/tree/src/common/util.c#n2899
It consumes the quoted string, then consumes any trailing whitespace (tabs or spaces), then it expects either a comment '#' or an '\n'. However if a file edited through notepad.exe for example, the first character it encounters would be '\r', preceding the '\n'.
This results in tor throwing: "[warn] Error while parsing configuration: Excess data after quoted string" then erroring out.
Testing on 0.2.7.6.
Steps to reproduce:
`$ printf "SocksPort 54321\nDataDirectory \"/tmp/datadir\"\r\n" > /tmp/conf`
`$ tor -f /tmp/conf`
`...[notice] Tor v0.2.7.6 (git-605ae665009853bd) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.2h and Zlib 1.2.8`
`...[notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning`
`...[notice] Read configuration file "/tmp/conf".`
`...[warn] Error while parsing configuration: Excess data after quoted string`
`...[err] Reading config failed--see warnings above.`
`$`Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19166HS connections randomly fail2020-06-13T14:57:54ZTvdWHS connections randomly failFor the sake of checking whether my bridges are running properly, a regular nagios job tries to establish a tcp connection to a HS running on each bridge, every 5 minutes. This is done through 'torsocks check_ssh -H abcdef.onion -p 22' b...For the sake of checking whether my bridges are running properly, a regular nagios job tries to establish a tcp connection to a HS running on each bridge, every 5 minutes. This is done through 'torsocks check_ssh -H abcdef.onion -p 22' but the issue in this ticket is reproducible with 'torsocks nc abcdef.onion 22' as well.
Connections randomly fail, causing a lot of monitoring noise, though I bet that for other users this manifests as hosts being unavailable completely.
As a test, I restarted tor and waited for a nagios check to fail. I then stopped nagios completely, causing tor to be idle, and manually ran a single check. The tor debug log, trimmed to the rough timeframe in which I ran the check, can be found at https://tvdw.eu/tor-debug-20160524220000.log
torsocks says: [May 24 22:00:33] ERROR torsocks[28974]: General SOCKS server failure (in socks5_recv_connect_reply() at socks5.c:516)
(note the timestamp, this failure is visible in tor's logs)
In my test the client ran Tor 0.2.7.6, and the HS ran 0.2.8.2, though I have been able to reproduce this with various tor versions on the HS side.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/19151Looks like a memory leak?2020-06-13T14:57:46ZTracLooks like a memory leak?Exit relay named Libero (64.113.32.29) running on CentOS Linux, kernel 2.6.32-573.18.1.el6.x86_64 , Tor 0.2.7.6.
I started seeing crashes around the beginning of May, as so:
May 10 02:09:59 Libero-CentOS kernel: tor invoked oom-kille...Exit relay named Libero (64.113.32.29) running on CentOS Linux, kernel 2.6.32-573.18.1.el6.x86_64 , Tor 0.2.7.6.
I started seeing crashes around the beginning of May, as so:
May 10 02:09:59 Libero-CentOS kernel: tor invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0, oom_score_adj=0
May 10 02:09:59 Libero-CentOS kernel: [<ffffffff8112a9f2>] ? oom_kill_process+0x82/0x2a0
May 10 02:09:59 Libero-CentOS kernel: [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
May 10 02:09:59 Libero-CentOS kernel: tor invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0, oom_score_adj=0
May 10 02:09:59 Libero-CentOS kernel: [<ffffffff8112a9f2>] ? oom_kill_process+0x82/0x2a0
May 10 02:09:59 Libero-CentOS kernel: [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
May 11 14:57:58 Libero-CentOS kernel: tor invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0, oom_score_adj=0
May 11 14:57:58 Libero-CentOS kernel: [<ffffffff8112add2>] ? oom_kill_process+0x82/0x2a0
May 11 14:57:58 Libero-CentOS kernel: [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
May 11 14:57:58 Libero-CentOS kernel: tor invoked oom-killer: gfp_mask=0xd0, order=0, oom_adj=0, oom_score_adj=0
May 11 14:57:58 Libero-CentOS kernel: [<ffffffff8112add2>] ? oom_kill_process+0x82/0x2a0
May 11 14:57:58 Libero-CentOS kernel: [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
May 18 21:11:50 Libero-CentOS kernel: tor invoked oom-killer: gfp_mask=0x200da, order=0, oom_adj=0, oom_score_adj=0
May 18 21:11:50 Libero-CentOS kernel: [<ffffffff8112a9f2>] ? oom_kill_process+0x82/0x2a0
May 18 21:11:50 Libero-CentOS kernel: [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
I increased the memory of the virtual server to 4 gigs around May 11, saw it crash again on May 18.
I set up graphing on the memory after that, and it's not looking good. I'm going to try to attach an.odf file (libreoffice draw) that shows what I'm seeing.
It may have started shortly after an update.
If it helps you, I can get you into the vserver if you can get me an ssh public key to install. You can email me at tor@t-3.net if you want for that.
**Trac**:
**Username**: t-3.netTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19122Documentation for "User" option specifies wrong kind of argument2020-06-13T14:57:34ZTracDocumentation for "User" option specifies wrong kind of argumenthttps://www.torproject.org/docs/tor-manual.html.en
User UID
On startup, setuid to this user and setgid to their primary group.
A UID is an integer in unix speak, not a username. The description of
the value uses "uid" correctly in t...https://www.torproject.org/docs/tor-manual.html.en
User UID
On startup, setuid to this user and setgid to their primary group.
A UID is an integer in unix speak, not a username. The description of
the value uses "uid" correctly in the function names, but the option
should say "username" because that is the only value it supports.
**Trac**:
**Username**: chadmillerTor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/19108Anomally in inner window sizes2020-06-15T23:35:18ZTracAnomally in inner window sizes[[Image()]]Hi I am facing this problem for last few updates of tor bundle.I have gone back to ver 4.5 to use tor whenever reqd. I have tried all versions from 5.0 to 5.5.5 but the problem remains as it is.After install on first run the w...[[Image()]]Hi I am facing this problem for last few updates of tor bundle.I have gone back to ver 4.5 to use tor whenever reqd. I have tried all versions from 5.0 to 5.5.5 but the problem remains as it is.After install on first run the window appears with very large button of connect,configure,exit.The line spacing between lines of dialogue box is triple.The title bar,url bar and tool bar area each is 1 inch in height. In 4.5 everything appears at its correct size. I have tried insralling/uninstalling many times. see search box/menu bar/tab bar size in the attachement provided.I am on a clean install of windows 10 pro.
**Trac**:
**Username**: ynonahttps://gitlab.torproject.org/legacy/trac/-/issues/18819ORPort listening on one IP, but advertising on another2020-06-13T14:56:25ZTracORPort listening on one IP, but advertising on anotherWhen I tell Tor to listen on one IP it (according to the log) still advertises itself on a different IP.
I am running the following configuration. The only change are the x's on IPs. Nothing else was removed or changed. See how the IP e...When I tell Tor to listen on one IP it (according to the log) still advertises itself on a different IP.
I am running the following configuration. The only change are the x's on IPs. Nothing else was removed or changed. See how the IP ends with .81.
```
SocksPort 0
ORPort x.x.x.81:33075
BridgeRelay 1
Exitpolicy reject *:*
User _tor
Nickname xxx
ContactInfo xxx
# Logging
Log notice file /var/log/tor.log
# Enable the Extended ORPort
ExtORPort auto
ServerTransportPlugin obfs3 exec xxx/bin/obfs4proxy
ServerTransportPlugin obfs4 exec xxx/bin/obfs4proxy
ServerTransportListenAddr obfs3 x.x.x.81:33074
ServerTransportListenAddr obfs4 x.x.x.81:443
```
When starting Tor (nothing but status lines that have been replaced with ... removed) it correctly outputs the listening ip, but still advertises on another ip (.81 vs .172).
```
Apr 14 11:06:58.110 [notice] Tor v0.2.7.6 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL 1.0.2g and Zlib 1.2.8.
...
Apr 14 11:06:58.135 [notice] Opening OR listener on x.x.x.81:33075
Apr 14 11:06:58.135 [notice] Opening Extended OR listener on 127.0.0.1:0
Apr 14 11:06:58.136 [notice] Extended OR listener listening on port 22692.
...
Apr 14 11:06:59.000 [notice] Bootstrapped 0%: Starting
Apr 14 11:07:00.000 [notice] Bootstrapped 5%: Connecting to directory server
Apr 14 11:07:35.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Apr 14 11:07:35.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Apr 14 11:07:36.000 [notice] Registered server transport 'obfs3' at 'x.x.x.81:33074'
Apr 14 11:07:36.000 [notice] Registered server transport 'obfs4' at 'x.x.x.81:443'
Apr 14 11:07:37.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Apr 14 11:07:37.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Apr 14 11:07:37.000 [notice] Bootstrapped 100%: Done
Apr 14 11:07:37.000 [notice] Now checking whether ORPort x.x.x.172:33075 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
```
ifconfig output. See how the interface has two IP addresses. Tor appears to be looking at the first one for advertisement, despite ORPort being set to the second one.
```
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
ether xx:xx:xx:xx:xx:x
inet x.x.x.172 netmask 0xffffff00 broadcast x.x.x.255
inet x.x.x.81 netmask 0xffffff00 broadcast x.x.x.255
```
sockstat (similar to netstat) output:
```
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
_tor tor 12580 5 tcp4 x.x.x.81:33075 *:*
```
Command Line:
```
/usr/local/bin/tor -f /usr/local/etc/tor/torrc --PidFile /var/run/tor/tor.pid --RunAsDaemon 1 --DataDirectory /var/db/tor
```
Also Tor isn't running in a jail and there is nothing else I can think of affecting it.
**Trac**:
**Username**: reezerhttps://gitlab.torproject.org/legacy/trac/-/issues/18710dnsserv.c asserts when no supported questions are requested2020-06-13T14:55:59ZTracdnsserv.c asserts when no supported questions are requestedThe patch for #10268 has a simple crasher that is easily exploited from the network if DNSPort is open to a LAN (e.g., if you are transparent proxying).
As [ticket:10268 #comment:11 andrea] hinted at, the added "if (!q) q = req->questio...The patch for #10268 has a simple crasher that is easily exploited from the network if DNSPort is open to a LAN (e.g., if you are transparent proxying).
As [ticket:10268 #comment:11 andrea] hinted at, the added "if (!q) q = req->questions[i];" to the for loop ensures that "q" is always set to the first question, even if it's unsupported. In which case, the "if (!q)" check for NOTIMPL is dead code. Ultimately, you will eventually hit the "tor_assert" that was added to the "else" branch. Additionally, the "switch" block switches on "req->questions[i]->type", but the assignment to "supported_q" is "q" (which is always the first question) instead of "req->questions[i]", so it doesn't actually pick the first supported question -- it always picks the first question.
**Trac**:
**Username**: geekmugTor: 0.2.5.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18686tor port forwarding claims to kill long-dead forwarder2020-06-13T14:55:54ZTractor port forwarding claims to kill long-dead forwarderMar 30 09:36:07 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (.../bin/tor-fw-helper) with pid '5936'
Mar 30 09:36:09 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 5936 has exited; running callba...Mar 30 09:36:07 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (.../bin/tor-fw-helper) with pid '5936'
Mar 30 09:36:09 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 5936 has exited; running callback.
Mar 30 09:41:13 h Tor[1243]: Failed to terminate process with PID '5936' ('Success').
Mar 30 09:41:13 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (...bin/tor-fw-helper) with pid '5985'
Mar 30 09:41:15 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 5985 has exited; running callback.
Mar 30 09:46:19 h Tor[1243]: Failed to terminate process with PID '5985' ('Success').
Mar 30 09:46:19 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (.../bin/tor-fw-helper) with pid '6052'
Mar 30 09:46:21 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 6052 has exited; running callback.
Mar 30 09:51:25 h Tor[1243]: Failed to terminate process with PID '6052' ('Success').
Mar 30 09:51:25 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (.../bin/tor-fw-helper) with pid '8784'
Mar 30 09:51:27 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 8784 has exited; running callback.
Mar 30 09:56:31 h Tor[1243]: Failed to terminate process with PID '8784' ('Success').
Mar 30 09:56:31 h Tor[1243]: tor_check_port_forwarding(): Started port forwarding helper (.../bin/tor-fw-helper) with pid '8848'
Mar 30 09:56:33 h Tor[1243]: notify_waitpid_callback_by_pid(): Child process 8848 has exited; running callback.
Mar 30 10:01:37 h Tor[1243]: Failed to terminate process with PID '8848' ('Bad file descriptor').
tor_check_port_forwarding in util.c keeps a static process_handle_t . Before spawning the forwarder helper, it says it tries to kill previously-running instances.
The cause is that the killing function doesn't distinguish between between not needing to kill versus attempted and failed.
The resulting error message has a ugly, wrong error reason too.
**Trac**:
**Username**: chadmillerTor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/18656Relay publishing malformed 'dirreq-v3-reqs' line2020-06-13T14:56:57ZDamian JohnsonRelay publishing malformed 'dirreq-v3-reqs' lineStarting fourteen hours ago relay C871C91489886D5E2E94C13EA1A5FDC4B6DC5204 started publishing an extrainfo descriptor that has non-ascii content on its dirreq-v3-reqs line. This causes Stem (and possibly MetricsLib) to choke, and should ...Starting fourteen hours ago relay C871C91489886D5E2E94C13EA1A5FDC4B6DC5204 started publishing an extrainfo descriptor that has non-ascii content on its dirreq-v3-reqs line. This causes Stem (and possibly MetricsLib) to choke, and should be getting rejected by the DirAuths.
This descriptor can presently be fetched with...
```
% curl http://193.23.244.244:80/tor/extra/fp/C871C91489886D5E2E94C13EA1A5FDC4B6DC5204
```
See attached for a copy.Tor: unspecifiedAndrea ShepardAndrea Shepardhttps://gitlab.torproject.org/legacy/trac/-/issues/18652ipv6 listener only, ipv4 source addresses2020-06-13T14:55:46ZTracipv6 listener only, ipv4 source addresses[notice] Opening OR listener on [::]:0
[notice] OR listener listening on port 38153.
[notice] Guessed our IP address as 42.42.42.42 (source: 154.35.175.225).
If my listening "port" is IPv6, the ip address guessed should be the IPv6 one,...[notice] Opening OR listener on [::]:0
[notice] OR listener listening on port 38153.
[notice] Guessed our IP address as 42.42.42.42 (source: 154.35.175.225).
If my listening "port" is IPv6, the ip address guessed should be the IPv6 one, if available.
Practically, if the address family of the listen port should be used as the address family of the outgoing socket that detects the local addess.
**Trac**:
**Username**: chadmillerhttps://gitlab.torproject.org/legacy/trac/-/issues/18633Tor service crashes on Debian sid when seccomp enabled in torrc2020-06-13T14:55:33ZcypherpunksTor service crashes on Debian sid when seccomp enabled in torrcI'm having issues with setting "Sandbox 1" in torrc on Debian sid. When I do, the process crashes and restarts indefinitely.
I see two suspect log entries, one from my auditd log, one from tor log.
First auditd:
type=SERVICE_START m...I'm having issues with setting "Sandbox 1" in torrc on Debian sid. When I do, the process crashes and restarts indefinitely.
I see two suspect log entries, one from my auditd log, one from tor log.
First auditd:
type=SERVICE_START msg=audit(____): pid=1 uid=0 auid=____ ses=____ msg='unit=tor@default comm="systemd" exe="/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
And here is a suspect tor log entry:
(Sandbox) Caught a bad syscall attempt (syscall getsockopt)
Not entirely sure what is causing the issue. I also have apparmor enabled and enforced with the default system_tor profile, but I'm not seeing any denials being logged, so I'm assuming apparmor is not at fault.
The process restarts rapidly when this happens -- it exits and starts over and over. When I do one "ps aux | grep tor" to find the pid, then "pgrep tor" to confirm, and expect to look in /proc/(pid) to confirm sandboxing is enabled... the pid has already changed.https://gitlab.torproject.org/legacy/trac/-/issues/18620HSFORGET command to clear cached client state for a HS2020-06-13T14:55:29ZTracHSFORGET command to clear cached client state for a HSThis is a patch used by the Android app [Briar](https://briarproject.org/) (since [October 2014](https://code.briarproject.org/akwizgran/briar/commit/9e5e2e2df24d84135f14adaa42111c3ea2c55df8)) that [we would like to upstream](https://cod...This is a patch used by the Android app [Briar](https://briarproject.org/) (since [October 2014](https://code.briarproject.org/akwizgran/briar/commit/9e5e2e2df24d84135f14adaa42111c3ea2c55df8)) that [we would like to upstream](https://code.briarproject.org/akwizgran/briar/issues/115). It adds an `HSFORGET` command to the control protocol which clears any cached client state relating to a specified hidden service. This can be used to flush state that's likely to be stale before trying to connect to a hidden service via an unstable network connection (such as a mobile data connection).
**Trac**:
**Username**: str4dTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/18604Deleting an ephemeral service doesn't always destroy intro circuits2020-06-13T14:55:17ZJohn BrooksDeleting an ephemeral service doesn't always destroy intro circuitsOn tor 0.2.7.6 with hidden services configured via ADD_ONION, this warning appeared several times:
```
log_warn(LD_REND, "Unrecognized service ID %s on introduction circuit %u.",
serviceid, (unsigned)circuit->base_.n_ci...On tor 0.2.7.6 with hidden services configured via ADD_ONION, this warning appeared several times:
```
log_warn(LD_REND, "Unrecognized service ID %s on introduction circuit %u.",
serviceid, (unsigned)circuit->base_.n_circ_id);
```
This happens when an introduction circuit finishes building and the service it was built for no longer exists.
When removing an ephemeral service, we close all S_ESTABLISH_INTRO or S_INTRO circuits that are CIRCUIT_STATE_OPEN. I suspect this warning happens when the service is removed before an introduction circuit reaches STATE_OPEN.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18580exit relay fails with 'unbound' DNS resolver when lots of requests time-out2020-06-13T17:34:27ZDhalgrenexit relay fails with 'unbound' DNS resolver when lots of requests time-outper
[tor-relays] What does this message mean in my tor logs?
https://lists.torproject.org/pipermail/tor-relays/2016-January/008621.html
[tor-relays] unbound bogs down strangely, degrading exit relay
https://lists.torproject.org/piperma...per
[tor-relays] What does this message mean in my tor logs?
https://lists.torproject.org/pipermail/tor-relays/2016-January/008621.html
[tor-relays] unbound bogs down strangely, degrading exit relay
https://lists.torproject.org/pipermail/tor-relays/2016-March/008918.html
Relay daemon ceases to service Tor Browser requests, timing out, when a local instance of 'unbound' is the DNS resolver and large numbers of DNS requests time-out.
Works fine when 'named' is swapped in place of 'unbound'.
GoDaddy DNS stops responding when large numbers of queries are submitted and this was observed as the particular trigger.
To reproduce, configure the SOA+NS records for several thousand dummy domains to point to a non-responding IP, then generate large numbers of requests against them.
The commands
unbound-control dump_requestlist
unbound-control dump_infra
are helpful for identifying the state.
Have debug-level daemon trace taken when relay was in the unresponsive condition described.Tor: unspecified