Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:34:21Zhttps://gitlab.torproject.org/legacy/trac/-/issues/28518Complain if net.inet.ip.random_id is not set on FreeBSD-based servers2020-06-13T15:34:21ZfkComplain if net.inet.ip.random_id is not set on FreeBSD-based serversThe attached patch lest Tor complain if net.inet.ip.random_id
is not set on FreeBSD-based servers
Apparently a couple of operators haven't gotten the memos [0] yet
and it looks like FreeBSD's default value will not change any time
s...The attached patch lest Tor complain if net.inet.ip.random_id
is not set on FreeBSD-based servers
Apparently a couple of operators haven't gotten the memos [0] yet
and it looks like FreeBSD's default value will not change any time
soon [1].
[0]:
https://lists.torproject.org/pipermail/tor-relays/2014-March/004199.html
https://lists.torproject.org/pipermail/tor-relays/2014-November/005687.html
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195828
[1]:
https://lists.freebsd.org/pipermail/freebsd-net/2015-April/041942.htmlTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28613Log is filled with OpenSSL errors2020-06-13T15:34:36ZTracLog is filled with OpenSSL errorsWhen I run `tor.exe -f torrc`, log file becomes filled with such lines:
```
Nov 25 19:51:46.000 [warn] Unhandled OpenSSL errors found at connection_or.c:1685:
Nov 25 19:51:46.000 [warn] TLS error: internal error (in SSL routines:tls13_h...When I run `tor.exe -f torrc`, log file becomes filled with such lines:
```
Nov 25 19:51:46.000 [warn] Unhandled OpenSSL errors found at connection_or.c:1685:
Nov 25 19:51:46.000 [warn] TLS error: internal error (in SSL routines:tls13_hkdf_expand:---)
Nov 25 19:51:47.000 [warn] Unhandled OpenSSL errors found at buffers_tls.c:69:
Nov 25 19:51:47.000 [warn] TLS error: internal error (in SSL routines:tls13_hkdf_expand:---)
```
Version tested: 3741f9e5 on Windows 7 SP1 x64, configured with `--disable-gcc-hardening` and compiled by MSYS2 with following libraries: Libevent 2.1.8-stable, OpenSSL 1.1.1a, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.7.
**Trac**:
**Username**: VortTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/28772DNS resolver at DNSPort stops working after some time, while tor is working. ...2020-06-13T15:35:20ZTracDNS resolver at DNSPort stops working after some time, while tor is working. Only restart helps.Hello. I am tor user more than 6 years. And always this problem existed. Now I am totally tired and decided to fill a bug. I am using always latest versions, now at 0.3.5.5 and on android the same, latest 0.3.* version.
I use DNSPort o...Hello. I am tor user more than 6 years. And always this problem existed. Now I am totally tired and decided to fill a bug. I am using always latest versions, now at 0.3.5.5 and on android the same, latest 0.3.* version.
I use DNSPort option and route all my DNS traffic to it. After tor is connected, it is working well, but after some time (2-5-10 hours), it stop to work and return no IP address to any DNS request, while the tor itself continue working, log don't show anything relevant. DNS requests resolve only internally through socks port.
This happens many years to me, and only restarting tor helps to get my DNS back.
I even tried to open multiple DNSresolvers, like
DNSPort 127.0.0.2:53
DNSPort 127.0.0.3:53
DNSPort 127.0.0.4:53
and put them all to /etc/resolv.conf, and it helped to keep it running more long, but anyway after some time they all stops resolving.
On android I have the same issue. I rerouted all DNS traffic to it, and after some hours only restarting to service works. I even thought to write some script, if domain fails to resolve, restart to service...
Please help! DNSPort resolver must recreate it's circuits if they fails. and don't wait for hard reset.
Thank you!
**Trac**:
**Username**: toruser787Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28927TB 8.5a6 using obfs4 did not leave dormant mode on request2020-06-13T15:35:57ZtraumschuleTB 8.5a6 using obfs4 did not leave dormant mode on requestToday a long running TB 8.5a6 using obfs4 repeatedly logged about being in dormant mode and did not build any circuits for existing and new tabs until the bridge was disabled. Then everything worked again.
Tor version: 0.3.5.5-alpha (gi...Today a long running TB 8.5a6 using obfs4 repeatedly logged about being in dormant mode and did not build any circuits for existing and new tabs until the bridge was disabled. Then everything worked again.
Tor version: 0.3.5.5-alpha (git-a2ecc19ab923f34c) running on Linux with Libevent 2.1.8-stable, OpenSSL 1.0.2q, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A.
Related: #2149, #25375, #28335, #28847, #28849
Steps to reproduce:
1. Start a fresh TB 8.5a6 with `--debug --log` and enable obfs4.
2. Use it for some days.
3. Let it run idle for some hours.
Step 2 may be optional, the computer was suspended several times but not the day this bug happened.
Will add the exact message when it happens again.Tor: unspecified