Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:16:07Zhttps://gitlab.torproject.org/legacy/trac/-/issues/23928Tor drops all connections2020-06-13T15:16:07ZTracTor drops all connectionsTor drops all my connections.
This is what journalctl has to say:
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(_start+0x2a) [0x56150e7fb67a] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr...Tor drops all my connections.
This is what journalctl has to say:
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(_start+0x2a) [0x56150e7fb67a] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/lib/libc.so.6(__libc_start_main+0xea) [0x7f19752f3f6a] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(main+0x1a) [0x56150e7fb61a] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(tor_main+0xf35) [0x56150e802da5] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(do_main_loop+0x252) [0x56150e7ffe92] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/lib/libevent-2.1.so.6(event_base_loop+0x53f) [0x7f1976620b1f] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/lib/libevent-2.1.so.6(+0x220d8) [0x7f19766200d8] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(+0x4beef) [0x56150e7feeef] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(+0x10b987) [0x56150e8be987] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(connection_edge_process_inbuf+0x1ea) [0x56150e8c668a] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(connection_edge_package_raw_inbuf+0x1ee) [0x56150e825bae] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(connection_edge_send_command+0x62) [0x56150e825892] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(relay_send_command_from_edge_+0x451) [0x56150e825421] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: /usr/bin/tor(log_backtrace+0x45) [0x56150e923975] (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: Bug: . Stack trace: (on Tor 0.3.1.7 6babd3d9ba9318b3)
REDACTED26:36 REDACTED Tor[13516]: circuit_package_relay_cell(): Bug: outgoing relay cell sent from src/or/relay.c:839 has n_chan==NULL. Dropping. (on Tor 0.3.1.7 6babd3d9ba9318b3)
**Trac**:
**Username**: BoBeR182https://gitlab.torproject.org/legacy/trac/-/issues/18547Add hostnames and geoip to connection panel2019-12-21T22:10:30ZDamian JohnsonAdd hostnames and geoip to connection panelMany releases ago Nyx [showed hostnames on the connection panel](https://gitweb.torproject.org/nyx.git/tree/src/util/hostnames.py?id=1.4.5.0), but dropped this because it leaked our connections to our DNS provider. We can still get this ...Many releases ago Nyx [showed hostnames on the connection panel](https://gitweb.torproject.org/nyx.git/tree/src/util/hostnames.py?id=1.4.5.0), but dropped this because it leaked our connections to our DNS provider. We can still get this information, but it must be on **every** relay or none at all.
Turns out Onionoo already supports exactly what we want! In particular here's the query we want...
[https://onionoo.torproject.org/details?fields=fingerprint,country,country_name,region_name,city_name,host_name&running=true&type=relay](https://onionoo.torproject.org/details?fields=fingerprint,country,country_name,region_name,city_name,host_name&running=true&type=relay)
Note that [Onionoo supports gzip compression](https://onionoo.torproject.org/protocol.html) and we want to take advantage since it drops the size of our replies from 1.5 MB to 432.6 KB.
For this we want a new **Daemon subclass** in **tracker.py**. This class would have a single **relay_details(fingerprint)** method that returns a struct with these attributes. If we meet the following two constraints then it calls Onionoo to update our cache...
1. We make a request for a fingerprint the cache doesn't have.
2. It's been over an hour since the relays_published date in our last reply (like the consensus Onionoo updates hourly, so no point in requesting more frequently).
Note that we might not want all of these geoip fields (we'll need to fiddle with the panel to see what is nice to have).Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/14979Option to close circuit2019-12-21T22:41:02ZintrigeriOption to close circuitVidalia allows that, and that's one thing we at Tails will be missing when we remove it. The main use case is debugging potentially buggy or malicious exit nodes. For example, you get an unexpected HTTPS or SSH warning, write down the in...Vidalia allows that, and that's one thing we at Tails will be missing when we remove it. The main use case is debugging potentially buggy or malicious exit nodes. For example, you get an unexpected HTTPS or SSH warning, write down the info about your exit node, and close that circuit to get a fresh one and confirm your suspicions.Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/12956Circuit list scares relay operators by using term 'exit'2017-10-25T20:09:30ZRoger DingledineCircuit list scares relay operators by using term 'exit'Every so often we have concerned users thinking they misconfigured their relay's exit policy, since in arm they see circuits that end at their relay and whose final hop is labelled 'Exit'.
E.g.:
```
arm - last-request (Linux 3.2.0-4-amd...Every so often we have concerned users thinking they misconfigured their relay's exit policy, since in arm they see circuits that end at their relay and whose final hop is labelled 'Exit'.
E.g.:
```
arm - last-request (Linux 3.2.0-4-amd64) Tor 0.2.5.6-alpha (recommended)
Relaying Disabled, Control Port (open): 9051
cpu: 0.0% tor, 0.8% arm mem: 29 MB (0.8%) pid: 6395 uptime: 1-20:40:44
page 2 / 5 - m: menu, p: pause, h: page help, q: quit
Connections (2 circuit):
76.99.61.63 --> 188.138.17.248 (fr) 3.1m (CIRCUIT)
│ 83.168.200.204 (se) ParadiseTorRelay1 1 / Guard
│ 18.181.5.37 (us) VERITAS 2 / Middle
└─ 188.138.17.248 (fr) EuropeCoastDE 3 / Exit
76.99.61.63 --> 209.159.130.6 (us) 3.1m (CIRCUIT)
│ 83.168.200.204 (se) ParadiseTorRelay1 1 / Guard
│ 213.138.110.88 (gb) lupine 2 / Middle
└─ 209.159.130.6 (us) LiveFreeOrDie 3 / Exit
```
I think for non-general-purpose circuits, we should call that third hop something else. I'm open to suggestions -- one option would be to just call the last hop on a non-exit circuit "Middle" also. Another option would be to call it "Internal".
Specifically, we could apply this new name to everything with circuit purpose other than GENERAL. Or we could apply it to all circuits that have the IS_INTERNAL flag. Maybe the latter approach is a bit more general.Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/9312Tor: the proxy server is refusing connections (Mac OS X)2020-06-15T23:16:10ZTracTor: the proxy server is refusing connections (Mac OS X)I this log is just frome me trying to go to https://encrypted.google.com/.
This is from the Tor message log (advanced) with all message filters enabled.
Jul 23 14:36:09.887 [Info] routerlist_remove_old_routers(): We have 0 live routers...I this log is just frome me trying to go to https://encrypted.google.com/.
This is from the Tor message log (advanced) with all message filters enabled.
Jul 23 14:36:09.887 [Info] routerlist_remove_old_routers(): We have 0 live routers and 0 old router descriptors.
Jul 23 14:36:12.474 [Info] Monitored process 320 is still alive.
Jul 23 14:36:27.474 [Info] Monitored process 320 is still alive.
Jul 23 14:36:42.474 [Info] Monitored process 320 is still alive.
Jul 23 14:36:57.474 [Info] Monitored process 320 is still alive.
Jul 23 14:37:04.887 [Debug] count_usable_descriptors(): 4094 usable, 4094 present.
Jul 23 14:37:04.904 [Debug] count_usable_descriptors(): 871 usable, 871 present.
Jul 23 14:37:10.887 [Info] routerlist_remove_old_routers(): We have 0 live routers and 0 old router descriptors.
Jul 23 14:37:12.474 [Info] Monitored process 320 is still alive.
Jul 23 14:37:27.474 [Info] Monitored process 320 is still alive.
**Trac**:
**Username**: hidemyidentityTorBrowserBundle 2.2.x-stablehttps://gitlab.torproject.org/legacy/trac/-/issues/6430Circuit list scares relay operators by using term 'exit'2020-06-13T03:26:49ZRoger DingledineCircuit list scares relay operators by using term 'exit'When you attach arm to your shiny new relay, and it does a reachability test by making a circuit back to itself, arm labels the third hop in that circuit the 'Exit'. Which makes at least one user freak out because he thought he set his e...When you attach arm to your shiny new relay, and it does a reachability test by making a circuit back to itself, arm labels the third hop in that circuit the 'Exit'. Which makes at least one user freak out because he thought he set his exit policy to reject *:*.
Perhaps arm should learn whether circuits are Internal or not (via the getinfo details), and call the final hop something other than Exit in that case?Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/5186Show streams on circuits2019-12-21T22:04:34ZcypherpunksShow streams on circuitsArm should show the targets of individual streams. For example, currently arm might show a new stream like this (spaces removed):
```
127.0.0.1:42051 --> 127.0.0.1:9050 UNKNOWN 0.0s (SOCKS)
```
Of course the destination is `127.0....Arm should show the targets of individual streams. For example, currently arm might show a new stream like this (spaces removed):
```
127.0.0.1:42051 --> 127.0.0.1:9050 UNKNOWN 0.0s (SOCKS)
```
Of course the destination is `127.0.0.1:9050`. That's just our socksport, and it provides no new information to the arm user. The destination should be shown as the target of the stream.
Once the stream is attached to a circuit, this binding should be shown explicitly. Note that this is not entirely trivial to do: for example, sometimes streams are reattached to different circuits (e.g. if a particular circuit does not work).
It might also be useful to indicate the status of a particular stream, e.g. "SENTRESOLVE", "SUCCEEDED", etc.Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/4281Usage popup not unique clients2019-01-11T18:46:46ZDamian JohnsonUsage popup not unique clientsThe usage popup either shows the number of client connections we've had per a locale or exit connections per port. For the client counts this isn't very useful since it counts *each* connection that a person makes so it's more of an acti...The usage popup either shows the number of client connections we've had per a locale or exit connections per port. For the client counts this isn't very useful since it counts *each* connection that a person makes so it's more of an activity metric rather than showing how many people are using you.
I should only count each source ip once.Damian JohnsonDamian Johnsonhttps://gitlab.torproject.org/legacy/trac/-/issues/1373Deadly decreasing traffic to 6-15 Kbyte/s after 2 hours tor-server work2020-06-13T14:04:36ZTracDeadly decreasing traffic to 6-15 Kbyte/s after 2 hours tor-server workBefore the fallowing messages occur
the unlimited traffic was about 1Mbyte/s (limited only by ISP),
the number of connections was 1500-2000 and permanently increased.
Apr 25 04:56:08.500 [Warning] Failing because we have 4063 connection...Before the fallowing messages occur
the unlimited traffic was about 1Mbyte/s (limited only by ISP),
the number of connections was 1500-2000 and permanently increased.
Apr 25 04:56:08.500 [Warning] Failing because we have 4063 connections already. Please raise your ulimit -n.
Apr 25 07:02:30.031 [Warning] Cannot seed RNG -- no entropy source found.
Apr 25 09:02:31.562 [Warning] Cannot seed RNG -- no entropy source found.
Apr 25 10:02:32.781 [Warning] Cannot seed RNG -- no entropy source found.
Apr 25 10:56:09.296 [Warning] Failing because we have 4063 connections already. Please raise your ulimit -n.
Apr 25 12:02:34.734 [Warning] Cannot seed RNG -- no entropy source found.
Apr 25 13:02:36.046 [Warning] Cannot seed RNG -- no entropy source found.
Apr 25 14:02:36.968 [Warning] Cannot seed RNG -- no entropy source found.
But according to only one, "common/crypto.c", line 1826: log_warn(LD_CRYPTO, "Cannot seed RNG -- no entropy source found.");
and the block before that
static const char *filenames[] = {
"/dev/srandom", "/dev/urandom", "/dev/random", NULL
};
there is a /dev/random:
# ls -1l /dev/random
# crw-r--r-- 1 root root 1, 8 Aug 31 2002 /dev/random
There are two OpenSSL installations: the original from RHL distribution and in the /usr/local/ssl (OpenSSL 0.9.8l 5 Nov 2009).
After the messages above and 2 working hours the traffic became about 6-15 Kbyte/s, the number of connections became about 4078.
This behavior I see last two months. But before this months the tor-server 0.2.1.21 works fine and now I built on RHL tor 0.2.1.25 that has the same symptom.
Also take into account lowering of number of Tor-servers from 1800-1900 in January and 1200-1400 now. I think, the problem above could lead to this.
The some last contents of /usr/local/var/log/tor/notices.log
Apr 23 03:04:01.070 [notice] Tor 0.2.1.25 opening log file.
Apr 23 03:04:01.074 [notice] Parsing GEOIP file.
Apr 23 03:04:01.701 [notice] OpenSSL OpenSSL 0.9.8l 5 Nov 2009 looks like version 0.9.8l; I will try SSL3_FLAGS to enable renegotation.
Apr 23 03:04:04.325 [notice] We now have enough directory information to build circuits.
Apr 23 03:04:04.325 [notice] Bootstrapped 80%: Connecting to the Tor network.
Apr 23 03:04:04.449 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Apr 23 03:04:04.966 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Apr 23 03:04:07.896 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Apr 23 03:04:07.896 [notice] Bootstrapped 100%: Done.
Apr 23 03:04:12.329 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Apr 23 03:04:50.256 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Apr 23 03:05:09.624 [notice] Performing bandwidth self-test...done.
Apr 23 08:45:42.214 [warn] Failing because we have 8159 connections already. Please raise your ulimit -n.
Apr 23 14:45:43.224 [warn] Failing because we have 8179 connections already. Please raise your ulimit -n.
Apr 23 18:04:19.638 [warn] Cannot seed RNG -- no entropy source found.
Apr 23 19:04:20.699 [warn] Cannot seed RNG -- no entropy source found.
Apr 23 20:04:22.022 [warn] Cannot seed RNG -- no entropy source found.
Apr 23 20:45:44.027 [warn] Failing because we have 8180 connections already. Please raise your ulimit -n.
Apr 23 21:04:23.100 [warn] Cannot seed RNG -- no entropy source found.
Apr 24 00:04:26.831 [warn] Cannot seed RNG -- no entropy source found.
Apr 24 02:45:57.676 [warn] Failing because we have 8161 connections already. Please raise your ulimit -n.
Apr 24 20:47:45.654 [warn] Failing because we have 8159 connections already. Please raise your ulimit -n.
Apr 24 22:04:48.278 [warn] Cannot seed RNG -- no entropy source found.
Apr 24 23:04:49.623 [warn] Cannot seed RNG -- no entropy source found.
Apr 25 01:04:51.865 [warn] Cannot seed RNG -- no entropy source found.
Apr 25 02:47:47.053 [warn] Failing because we have 8181 connections already. Please raise your ulimit -n.
Apr 25 03:04:53.733 [warn] Cannot seed RNG -- no entropy source found.
Apr 25 03:53:40.586 [notice] Interrupt: will shut down in 30 seconds. Interrupt again to exit now.
Apr 25 03:54:10.605 [notice] Clean shutdown finished. Exiting.
Apr 25 03:58:54.261 [notice] Tor 0.2.1.25 opening log file.
Apr 25 03:58:54.313 [notice] Parsing GEOIP file.
Apr 25 03:58:55.038 [notice] OpenSSL OpenSSL 0.9.8l 5 Nov 2009 looks like version 0.9.8l; I will try SSL3_FLAGS to enable renegotation.
Apr 25 03:59:03.156 [notice] We now have enough directory information to build circuits.
Apr 25 03:59:03.156 [notice] Bootstrapped 80%: Connecting to the Tor network.
Apr 25 03:59:03.318 [notice] Bootstrapped 85%: Finishing handshake with first hop.
Apr 25 03:59:03.941 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Apr 25 03:59:04.548 [notice] Bootstrapped 90%: Establishing a Tor circuit.
Apr 25 03:59:08.890 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Apr 25 03:59:08.890 [notice] Bootstrapped 100%: Done.
Apr 25 04:00:09.977 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Apr 25 04:00:10.770 [notice] Performing bandwidth self-test...done.
Apr 25 04:52:44.677 [warn] Failing because we have 4063 connections already. Please raise your ulimit -n.
Apr 25 06:59:06.377 [warn] Cannot seed RNG -- no entropy source found.
Apr 25 08:59:08.079 [warn] Cannot seed RNG -- no entropy source found.
Apr 25 09:59:09.377 [warn] Cannot seed RNG -- no entropy source found.
Apr 25 10:52:45.995 [warn] Failing because we have 4063 connections already. Please raise your ulimit -n.
Apr 25 11:59:11.488 [warn] Cannot seed RNG -- no entropy source found.
Apr 25 12:59:12.760 [warn] Cannot seed RNG -- no entropy source found.
Apr 25 13:59:13.896 [warn] Cannot seed RNG -- no entropy source found.
Apr 25 16:52:46.955 [warn] Failing because we have 4085 connections already. Please raise your ulimit -n.
**Trac**:
**Username**: aynvudoAndrew LewmanAndrew Lewman