- tor-relays - lists.torproject.org

Re: [tor-relays] Call for setting up new obfs4 bridges
by dmz21＠ziggo.nl 22 Jul '19

22 Jul '19

> On July 19, 2019 at 1:44 PM Ben Riley <blades1000(a)gmail.com> wrote: > > > To follow up my previous email, I found the "Firewall" app and I've > manually opened 9051 & 8531 in that, and when I tested those via the online > port checking tools, they are now open. > > Restarted TOR (sudo systemctl restart tor) and the logs show it > bootstrapped to 100% and stated the ORPort 9051 is now reachable. > TOR did its bandwidth self-test.....done. > > Should that now be working ok? Yes, the logs look good. I think the ORPort indeed needs to be reachable for a bridge. You could try testing your own bridge using Tor Browser [1] or a Tails DVD [2]. Or wait a few hours (or weeks for the graphs) and look up your bridge on Tor Relay Search [3]. [1] https://www.torproject.org/download/ [2] https://tails.boum.org/ [3] https://metrics.torproject.org/rs.html# > Log now reads: > > Jul 19 21:31:43 ben-OptiPlex-755 Tor[8779]: Bootstrapped 10% (conn_done): > > Connected to a relay > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 14% (handshake): > > Handshaking with a relay > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 15% > > (handshake_done): Handshake with a relay done > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 75% > > (enough_dirinfo): Loaded enough directory info to build circuits > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 90% > > (ap_handshake_done): Handshake finished with a relay to build circuits > > Jul 19 21:31:44 ben-OptiPlex-755 Tor[8779]: Bootstrapped 95% > > (circuit_create): Establishing a Tor circuit > > Jul 19 21:31:45 ben-OptiPlex-755 Tor[8779]: Guessed our IP address as > > 158.140.206.75 (source: 217.182.196.67). > > Jul 19 21:31:46 ben-OptiPlex-755 Tor[8779]: Bootstrapped 100% (done): Done > > Jul 19 21:31:46 ben-OptiPlex-755 Tor[8779]: Now checking whether ORPort > > 158.140.206.75:9051 is reachable... (this may take up to 20 minutes -- > > look for log messages indicating success) > > Jul 19 21:31:49 ben-OptiPlex-755 Tor[8779]: Self-testing indicates your > > ORPort is reachable from the outside. Excellent. Publishing server > > descriptor. > > Jul 19 21:32:14 ben-OptiPlex-755 Tor[8779]: New control connection opened. > > Jul 19 21:33:05 ben-OptiPlex-755 Tor[8779]: Your network connection speed > > appears to have changed. Resetting timeout to 60s after 18 timeouts and 129 > > buildtimes. > > Jul 19 21:33:07 ben-OptiPlex-755 Tor[8779]: Performing bandwidth > > self-test...done. > > > > On Fri, Jul 19, 2019 at 8:41 PM Ben Riley <blades1000(a)gmail.com> wrote: > > > Thanks for that. So I tried as you suggested and edited (gedit) the torrc > > file, replacing the obfs4 from 443 to 8531. > > I also added a port forward for that port on my router. > > Restarted TOR and the log file shows that it made a circuit (Bootstrapped > > 100%). > > I can now run nyx and see that TOR is trying to make connections. > > As per the log below, it seems that ORPort 9051 is unreachable (which is > > true according to a port checker) > > Though I've got the following ports forwarded on the router 9050, 9051, > > 443 & 8531 - 9001 is NOT forwarded though. > > > > Now the log says this: > > > >> Jul 19 19:53:58 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.969 [notice] > >> Tor 0.4.0.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, > >> Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.970 [notice] > >> Tor can't help you if you use it wrong! Learn how to be safe at > >> https://www.torproject.org/download/download#warning > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.990 [notice] > >> Read configuration file "/usr/share/tor/tor-service-defaults-torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.990 [notice] > >> Read configuration file "/etc/tor/torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Jul 19 19:53:58.997 [notice] > >> Based on detected system memory, MaxMemInQueues is set to 2862 MB. You can > >> override this by setting MaxMemInQueues by hand. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15447]: Configuration was valid > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Tor 0.4.0.5 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1, > >> Zlib 1.2.11, Liblzma 5.2.2, and Libzstd 1.3.3. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Tor can't help you if you use it wrong! Learn how to be safe at > >> https://www.torproject.org/download/download#warning > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Read configuration file "/usr/share/tor/tor-service-defaults-torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.210 [notice] > >> Read configuration file "/etc/tor/torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.214 [notice] > >> Based on detected system memory, MaxMemInQueues is set to 2862 MB. You can > >> override this by setting MaxMemInQueues by hand. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opening Socks listener on 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opened Socks listener on 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opening OR listener on 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opened OR listener on 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opening Extended OR listener on 127.0.0.1:0 > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Extended OR listener listening on port 36399. > >> Jul 19 19:53:59 ben-OptiPlex-755 tor[15449]: Jul 19 19:53:59.215 [notice] > >> Opened Extended OR listener on 127.0.0.1:36399 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Tor 0.4.0.5 running on Linux > >> with Libevent 2.1.8-stable, OpenSSL 1.1.1, Zlib 1.2.11, Liblzma 5.2.2, and > >> Libzstd 1.3.3. > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Tor can't help you if you > >> use it wrong! Learn how to be safe at > >> https://www.torproject.org/download/download#warning > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Read configuration file > >> "/usr/share/tor/tor-service-defaults-torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Read configuration file > >> "/etc/tor/torrc". > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Based on detected system > >> memory, MaxMemInQueues is set to 2862 MB. You can override this by setting > >> MaxMemInQueues by hand. > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opening Socks listener on > >> 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opened Socks listener on > >> 127.0.0.1:9050 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opening OR listener on > >> 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opened OR listener on > >> 0.0.0.0:9051 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opening Extended OR listener > >> on 127.0.0.1:0 > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Extended OR listener > >> listening on port 36399. > >> Jul 19 19:53:59 ben-OptiPlex-755 Tor[15449]: Opened Extended OR listener > >> on 127.0.0.1:36399 > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Parsing GEOIP IPv4 file > >> /usr/share/tor/geoip. > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Parsing GEOIP IPv6 file > >> /usr/share/tor/geoip6. > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Configured to measure > >> statistics. Look for the *-stats files that will first be written to the > >> data directory in 24 hours from now. > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Your Tor server's identity > >> key fingerprint is 'MelbTORbridge 9F19251CEE17B1E05084898D164F0544CCB095DD' > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Your Tor bridge's hashed > >> identity key fingerprint is 'MelbTORbridge > >> E4AF099DA5946A6D6EA65DC55B517D3F9B12D0ED' > >> Jul 19 19:54:04 ben-OptiPlex-755 Tor[15449]: Bootstrapped 0% (starting): > >> Starting > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Starting with guard context > >> "default" > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Signaled readiness to systemd > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Bootstrapped 5% (conn): > >> Connecting to a relay > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Registered server transport > >> 'obfs4' at '[::]:8531' > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opening Socks listener on > >> /run/tor/socks > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opened Socks listener on > >> /run/tor/socks > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opening Control listener on > >> /run/tor/control > >> Jul 19 19:54:16 ben-OptiPlex-755 Tor[15449]: Opened Control listener on > >> /run/tor/control > >> Jul 19 19:54:17 ben-OptiPlex-755 Tor[15449]: Bootstrapped 10% > >> (conn_done): Connected to a relay > >> Jul 19 19:54:17 ben-OptiPlex-755 Tor[15449]: Bootstrapped 14% > >> (handshake): Handshaking with a relay > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 15% > >> (handshake_done): Handshake with a relay done > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 20% > >> (onehop_create): Establishing an encrypted directory connection > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 25% > >> (requesting_status): Asking for networkstatus consensus > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Bootstrapped 50% > >> (loading_descriptors): Loading relay descriptors > >> Jul 19 19:54:18 ben-OptiPlex-755 Tor[15449]: Guessed our IP address as > >> 158.140.206.75 (source: 185.103.110.144). > >> Jul 19 19:54:20 ben-OptiPlex-755 Tor[15449]: I learned some more > >> directory information, but not enough to build a circuit: We have no recent > >> usable consensus. > >> Jul 19 19:54:21 ben-OptiPlex-755 Tor[15449]: I learned some more > >> directory information, but not enough to build a circuit: We're missing > >> descriptors for 1/2 of our primary entry guards (total microdescriptors: > >> 5382/6384). > >> Jul 19 19:54:25 ben-OptiPlex-755 Tor[15449]: Bootstrapped 75% > >> (enough_dirinfo): Loaded enough directory info to build circuits > >> Jul 19 19:54:25 ben-OptiPlex-755 Tor[15449]: Bootstrapped 90% > >> (ap_handshake_done): Handshake finished with a relay to build circuits > >> Jul 19 19:54:25 ben-OptiPlex-755 Tor[15449]: Bootstrapped 95% > >> (circuit_create): Establishing a Tor circuit > >> Jul 19 19:54:27 ben-OptiPlex-755 Tor[15449]: Bootstrapped 100% (done): > >> Done > >> Jul 19 19:54:27 ben-OptiPlex-755 Tor[15449]: Now checking whether ORPort > >> 158.140.206.75:9051 is reachable... (this may take up to 20 minutes -- > >> look for log messages indicating success) > >> Jul 19 19:55:35 ben-OptiPlex-755 dbus-daemon[3325]: [session uid=1000 > >> pid=3325] Activating service name='org.gnome.Calculator.SearchProvider' > >> requested by ':1.262' (uid=1000 pid=8482 comm="/usr/bin/gnome-shell " > >> label="unconfined") > >> Jul 19 19:55:36 ben-OptiPlex-755 dbus-daemon[3325]: [session uid=1000 > >> pid=3325] Successfully activated service > >> 'org.gnome.Calculator.SearchProvider' > >> Jul 19 19:55:42 ben-OptiPlex-755 nautilus[15604]: Could not get mtime for > >> 'file:///home/ben/.cache/tracker/meta.db': Error when getting information > >> for file “/home/ben/.cache/tracker/meta.db”: No such file or directory > >> Jul 19 19:55:43 ben-OptiPlex-755 bijiben-shell-s[15603]: Could not get > >> mtime for 'file:///home/ben/.cache/tracker/meta.db': Error when getting > >> information for file “/home/ben/.cache/tracker/meta.db”: No such file or > >> directory > >> Jul 19 19:55:44 ben-OptiPlex-755 tracker-store[3751]: Error opening > >> database: Could not open sqlite3 > >> database:'/home/ben/.cache/tracker/meta.db': unable to open database file > >> Jul 19 19:55:44 ben-OptiPlex-755 tracker-store[3751]: > >> tracker_sparql_query_exec_sql_cursor: assertion 'iface != NULL' failed > >> Jul 19 19:55:44 ben-OptiPlex-755 tracker-store[3751]: ___lambda11_: > >> assertion 'cursor != NULL' failed > >> Jul 19 19:55:49 ben-OptiPlex-755 Tor[15449]: New control connection > >> opened. > >> Jul 19 19:55:56 ben-OptiPlex-755 org.gnome.bijiben.SearchProvider[3325]: > >> Unable to load location /home/ben/.local/share/bijiben: Error opening > >> directory '/home/ben/.local/share/bijiben': No such file or directory > >> Jul 19 20:03:43 ben-OptiPlex-755 org.gnome.Shell.desktop[8482]: Window > >> manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a > >> timestamp of 0 for 0x6e00084 (torrc (/et) > >> Jul 19 20:14:38 ben-OptiPlex-755 Tor[15449]: Your server ( > >> 158.140.206.75:9051) has not managed to confirm that its ORPort is > >> reachable. Relays do not publish descriptors until their ORPort and DirPort > >> are reachable. Please check your firewalls, ports, address, /etc/hosts > >> file, etc. > >> > > > > > > On Fri, Jul 19, 2019 at 6:34 PM < > > dmz121(a)ziggo.nl> wrote: > > > >> > >> > On July 19, 2019 at 6:36 AM Ben Riley <blades1000(a)gmail.com> wrote: > >> > > >> > > >> > Hi, > >> > > >> > Thanks for the reply. Yes, I ran that command way back at the start. I'm > >> > assuming I don't have to run it every time the machine reboots or > >> updates? > >> > I ran it again this morning and it made no difference. > >> > > >> > Ah logs, you say that like I know where those are :P > >> > When I run sudo tail /var/log/tor/log - I get nothing. > >> > I found the Logs app and run that to get all the system logs - way too > >> much > >> > stuff and I couldn't move it to here, so I found this command (Google) > >> cat > >> > /var/log/syslog | grep tor -i and got the following (I think I've > >> included > >> > 2 set of attempts to boot up): > >> > > >> > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Starting with guard context > >> > > "default" > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Signaled readiness to > >> systemd > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Bootstrapped 5% (conn): > >> > > Connecting to a relay > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Server managed proxy > >> > > encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: > >> > > permission denied) > >> > >> I ran (and keep running) into the same problem (but on Debian), even > >> after the fix suggested below. > >> Could you please try an unused port above 1024, like 8531? That resolved > >> this issue for me. > >> > >> hope this helps and kind regards. > >> > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Managed proxy at > >> > > '/usr/bin/obfs4proxy' failed the configuration protocol and will be > >> > > destroyed. > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: tor_assertion_failed_(): > >> Bug: > >> > > ../src/feature/client/transports.c:1836: > >> managed_proxy_stdout_callback: > >> > > Assertion mp->conf_state == PT_PROTO_COMPLETED failed; aborting. (on > >> Tor > >> > > 0.4.0.5 ) > >> > > Jul 19 14:32:23 ben-OptiPlex-755 Tor[28002]: Bug: Assertion > >> mp->conf_state > >> > > == PT_PROTO_COMPLETED failed in managed_proxy_stdout_callback at > >> > > ../src/feature/client/transports.c:1836. Stack trace: (on Tor 0.4.0.5 > >> ) > >> > >> (removed rest of log) > >> > >> > > >> > > >> > > >> > On Fri, Jul 19, 2019 at 1:12 AM Philipp Winter <phw(a)torproject.org> > >> wrote: > >> > > >> > > On Thu, Jul 18, 2019 at 12:50:34PM +1000, Ben Riley wrote: > >> > > > Then I saw the above email about being a bridge and thought, fine, > >> I'll > >> > > > configure it to be a bridge and help out someone. > >> > > > Tried to do it via the docker/script method, but soon realised that > >> was > >> > > > outside my skill level (hey stop laughing! :P) > >> > > > >> > > Did you run into any specific issues? If you had troubles following > >> the > >> > > guide, I'm gonna blame the guide. > >> > > > >> > > > Setting ORPort to 443 as suggested. I forwarded that port on the > >> > > > router and then tested it, but it said it was closed. So I thought > >> my > >> > > > router was playing up. I checked a few other ports using online > >> tools > >> > > > and a few of them were closed. I forwarded a new another port to > >> some > >> > > > other software on another machine and that worked?! So I realised > >> the > >> > > > ports are open on the router but closed on the ubuntu machine. I've > >> > > > played around with all the settings, changed by torrc file to a > >> really > >> > > > basic one of: > >> > > > >> > > To run obfs4 on port 443, you will have to run the following command, > >> to > >> > > allow obfs4proxy to bind to port 443: > >> > > > >> > > sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy > >> > > > >> > > If you did that already, it would be helpful to see your logs. > >> > > > >> > > Cheers, > >> > > Philipp > >> > > _______________________________________________ > >> > > tor-relays mailing list > >> > > tor-relays(a)lists.torproject.org > >> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > > > >> > _______________________________________________ > >> > tor-relays mailing list > >> > tor-relays(a)lists.torproject.org > >> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >> > >

3 3

Limiting Tor Relay To Run On Google Cloud VPS
by Keifer Bly 20 Jul '19

20 Jul '19

Hi all, So a while back I was trying to run a tor relay via Google Cloud VPS but it was costing quite a bit. However, I was chatting with them, and I found out that as long as the relay generates a maximum of 4.9 GB per month and less than 2 million connections, it won't cost anything. I am wondering how to configure these limitations in tor? Thanks all. It's a small relay I know. --Keifer

4 4

Call for setting up new obfs4 bridges
by Philipp Winter 19 Jul '19

19 Jul '19

Hi everyone, BridgeDB is running low on obfs4 bridges and often fails to provide users with three bridges per request. Besides, we recently fixed a BridgeDB issue that could get an obfs4 bridge blocked because of its vanilla bridge descriptor: <https://bugs.torproject.org/28655> We therefore want to encourage volunteers to set up new obfs4 bridges to help censored users. Over the last few weeks, we have been improving our obfs4 setup guide which walks you through the process: <https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4…> The guide provides instructions for Debian, Ubuntu, CentOS, RHEL, OpenSUSE, FreeBSD, and OpenBSD. If you're running into any issues with the guide, please let us know! Finally, once you set up an obfs4 bridge, make sure that both your ORPort *and* your obfs4 port are reachable. Tor currently only tests the reachability of its ORPort. We set up a service that allows you to test the reachability of your obfs4 port: <https://bridges.torproject.org/scan/> Thanks for keeping the Tor network healthy by running relays and bridges! Thanks, Philipp

9 15

Windows Relay Setup
by William Pate 13 Jul '19

13 Jul '19

I'm interested in hosting a Windows-based relay, if anyone can point me to a good tutorial. I've tried the most common ones.

3 2

What fraction of Tor’s DNS traffic goes to Google and Cloudflare?
by nusenu 13 Jul '19

13 Jul '19

https://medium.com/@nusenu/what-fraction-of-tors-dns-traffic-goes-to-google… > 60.05% of the tor network’s exit capacity uses a resolver which is > located in the same autonomous system as the exit relay itself (that > includes localhost) which is recommended to minimize the path > between exit relay and its resolver. Lets aim to increase this > fraction to above 80%. > > If you are an exit operator and want to help reach this goal you can > use this list to verify you are not using Google or Cloudflare > resolvers. https://gist.github.com/nusenu/e6eec32679cc64ffe3e24d2b9367a931 > The Tor Relay Guide has instructions for setting up a > local DNS resolver. https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#DNSonExitRelays -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

3 2

What rules for a fallback dir - the compiled-in fingerprint, a flag from the authorities or both?
by Toralf Förster 13 Jul '19

13 Jul '19

I do just wonder how a client decides whether/when fallback dir is to be used, especially when the *.inc file changed. -- Toralf PGP C4EACDDE 0076E94E

1 0

tor_bug_occured_(): This line should not have been reached
by [REDACTED] 08 Jul '19

08 Jul '19

Hey guys, my relay 79E683340B80676DCEB029E48FBD36BC66EBDA1E told me: Jul 06 15:22:34.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 150515 circuits rejected, 16 marked addresses. 0 connections closed. 104 single hop clients refused. Jul 06 16:23:25.000 [warn] tor_bug_occurred_(): Bug: ../src/core/or/channeltls.c:1111: channel_tls_handle_cell: This line should not have been reached. (Future instances of this warning will be silenced.) (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: Line unexpectedly reached at channel_tls_handle_cell at ../src/core/or/channeltls.c:1111. Stack trace: (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x46) [0x562903c4faa6] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x562903c4b1c0] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x49a) [0x562903ad571a] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(+0x9a16a) [0x562903af916a] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x99d) [0x562903ac318d] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(+0x69ebe) [0x562903ac8ebe] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f469cdbf9ba] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f469cdc0537] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(do_main_loop+0xb0) [0x562903aca290] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x10e5) [0x562903ab80d5] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x562903ab530a] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x562903ab4ec9] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xeb) [0x7f469c6a109b] (on Tor 0.3.5.8 ) Jul 06 16:23:25.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x562903ab4f1a] (on Tor 0.3.5.8 ) Jul 06 21:22:34.000 [notice] Heartbeat: Tor's uptime is 12 days 6:00 hours, with 5113 circuits open. I've sent 2802.42 GB and received 2781.10 GB. Jul 06 21:22:34.000 [notice] Circuit handshake stats since last time: 13801/13801 TAP, 169020/169020 NTor. Its anyway a little bit strange because this is the only relay i have which never deleted his logfiles since i set it up and where i can not change the language of the operating system. I think its related to the host system but i never really thought about because it seems to work fine. Something i should do now?

2 1

Re: [tor-relays] Call for setting up new obfs4 bridges
by nottryingtobelame＠protonmail.com 08 Jul '19

08 Jul '19

Hello, I successfully ran an obfs4 bridge about a year ago that saw moderate traffic. After a few months, the traffic died off until I was consistently seeing 0 clients. I wiped the keys, got a new IP address, and started a new bridge. The 2nd bridge saw 0 clients, over several months. I finally wiped it again and started a 3rd bridge. Same thing, 0 clients for several months. My 4th bridge, which I took down last night, was up for just shy of 3 months with 0 clients. Before I took it down, I tested using https://bridges.torproject.org/scan/ and confirmed the ports were reachable. While I was not able to test the previous iterations, I setup the port forwarding for each of them for both the OR Port and the Ext OR Port that it randomly assigned. I won't be able to grab a new IP address this time, but I'm starting the bridge up again with new ID keys and new ports. Is it normal for bridges to see no traffic, and if they're not seeing any, should I keep them online?

2 1

Testing the accessibility of my obfs4 bridge
by nottryingtobelame＠protonmail.com 08 Jul '19

08 Jul '19

I plugged my bridgeline into Tor Browser on Windows, and connected successfully. I put it into Orbot on Android and also connected successfully. But when I put it into the new Tor Browser for Android, I am unable to connect. The logs from Tor Browser are pasted here: https://pastebin.com/cF5bwRH1. Any idea why one client would be failing to connect? Thanks in advance.

2 1

ExoneraTor results may be incomplete between April 25 and 30, 2019 and during other periods
by Karsten Loesing 08 Jul '19

08 Jul '19

Hello relay operators, it turns out that our exit scanner had an issue between April 25 and 29, 2019 and that ExoneraTor results may be incomplete during this time. Some context, taken from the ExoneraTor page: https://metrics.torproject.org/exonerator.html "The ExoneraTor service maintains a database of IP addresses that have been part of the Tor network. It answers the question whether there was a Tor relay running on a given IP address on a given date. ExoneraTor may store more than one IP address per relay if relays use a different IP address for exiting to the Internet than for registering in the Tor network, and it stores whether a relay permitted transit of Tor traffic to the open Internet at that time." Now, if somebody looks up their exit IP address during the time between April 25 and 29, 2019, their relay won't be listed in the results. It will still be included with the IP address that it used for registering at the directory authorities, but not with its exit IP address. I looked through the archive of exit lists and found similar downtimes of 18 hours or longer which would have the same effect: Gap of 19 hours between 2011-09-10T00:05:00 and 2011-09-10T19:28:46. Gap of 23 hours between 2011-12-21T01:21:19 and 2011-12-22T00:23:36. Gap of 111 hours between 2012-02-07T02:33:16 and 2012-02-11T18:07:47. Gap of 26 hours between 2013-03-07T15:16:50 and 2013-03-08T17:17:55. Gap of 156 hours between 2013-03-14T09:29:25 and 2013-03-20T22:03:41. Gap of 19 hours between 2015-10-09T14:13:37 and 2015-10-10T09:57:26. Gap of 18 hours between 2018-02-02T18:27:54 and 2018-02-03T13:06:09. Gap of 122 hours between 2019-04-25T13:13:19 and 2019-04-30T15:40:21. Gap of 21 hours between 2019-05-25T19:04:43 and 2019-05-26T16:09:23. We're working on adding a notice to ExoneraTor results in case a lookup falls into one of these periods, but that will take us some time. https://trac.torproject.org/projects/tor/ticket/31071 Sorry for any confusions caused by this! All the best, Karsten

1 0