- tor-relays - lists.torproject.org

New Fallbacks from June 2019
by teor 05 Aug '19

05 Aug '19

Dear Relay Operators, Thanks to everyone who opted-in their relays as fallback directory mirrors. We rebuilt the list of fallbacks in June 2019. [0] The new list will be released in Tor 0.4.1.4-alpha/rc. It was backported to all supported Tor releases. [1] The FallbackDir flags on Consensus Health [2] and Relay Search [3] might take a week or two to update. Don't worry if your relay missed out this time. It's still helping Tor users. And we will rebuild the fallback list again in 6-12 months time. We are tracking future fallback changes in this ticket [4]. To opt-in your relays, add a comment to the ticket [4], or reply to this thread. If you have multiple relays, you can opt-in as many as you like. (We picked up to 7 per operator this time, and we may pick more next time.) T [0]: See: https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc https://trac.torproject.org/projects/tor/ticket/28793 [1]: 0.2.9, 0.3.5, 0.4.0, and 0.4.1: See https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… [2]: https://consensus-health.torproject.org/graphs.html Which uses stem's cached fallback list at: https://gitweb.torproject.org/stem.git/log/stem/cached_fallbacks.cfg [3]: For example, this relay is a new fallback, but its flag isn't shown yet: https://metrics.torproject.org/rs.html#details/1211AC1BBB8A1AF7CBA86BCE8689… [4]: https://trac.torproject.org/projects/tor/ticket/30972

2 2

ORPort // DirPort
by Fabio De Sicot 05 Aug '19

05 Aug '19

Hello everyone I have a problem I wasn't able to fix until now. Could you help me whit this? ------------------------ - when I start tor I receive this error: [...........] Aug 03 09:48:29.000 [notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up. Aug 03 09:48:40.000 [notice] Have tried resolving or connecting to address '[scrubbed]' at 3 different places. Giving up. [...........] Aug 03 10:07:09.000 [warn] Your server () 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. Aug 03 10:07:09.000 [warn] Your server () has not managed to confirm that its DirPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. - I verified, and ports 9051, 9001 and 9030 were not filtered # firewall-cmd --get-active-zones internal interfaces: eth0 # firewall-cmd --zone=internal --list-allinternal (active) target: default icmp-block-inversion: no interfaces: eth0 sources: ports: 9051/tcp 9051/udp 9001/tcp 9001/udp 9030/tcp 9030/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: - I checked my torrc file # cat /usr/local/etc/tor/torrcNickname xxxxxx ORPort 9001 <<<< ControlPort 9051 <<<< DirPort 9030 <<<< # # RunAsDaemon 0 ExitRelay 0 CookieAuthentication 1 ContactInfo xxxxxxx - I verified the internal ip # ifconfig eth0eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.8 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::1874:3d84:ac42:fa97 prefixlen 64 scopeid 0x20<link> ether b8:27:eb:90:a2:b8 txqueuelen 1000 (Ethernet) RX packets 1118761 bytes 398404534 (379.9 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1095304 bytes 428598871 (408.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 - and I verified that on my router the port forwarding was active # Port Forwarding Name Port Range Protocol IP Address Enable TOR 9051 TCP&UDP 192.168.0.8 x ORPORT 9001 TCP&UDP 192.168.0.8 x DIRPORT 9030 TCP&UDP 192.168.0.8 x ------------------------ Thanks in advance Regatds -- Fabio De Sicot # https://fosstodon.org/@jolek78 <https://fosstodon.org/@jolek78>

2 1

Tor relay has low consensus weight
by Piers 04 Aug '19

04 Aug '19

Hi, i have been running a tor relay (link: https://metrics.torproject.org/rs.html#details/858BEC79D7355EC0631E98D47CF1…) on a raspberry pi 2 for 15 days, however i think there might be a problem with it. My consensus weight is only 43 and thus the relay doesn't get used much. Please advise if there is an issue -- Many thanks, -Piers

3 2

Unutilized bandwidth
by Alec Larsen 01 Aug '19

01 Aug '19

Hello, I've only recently joined this list, so I apologise in advance if this is not the appropriate place for my question. For the past month, I have been operating an exit node ( 89094DFA4158C7A1583EC3A332CDCBC74A28CC0E ) from UnitedIX in Chicago, IL, US. The server has a dedicated gigabit port, and I had hoped to be able to relay around 200 TB of traffic per month, but for some reason my advertised bandwidth has been hovering at just 12 MiB/s since the first few days. The server itself is an older Supermicro PfSense server with a Xeon E3-1270v3 at 3.5ghz and 32gb of RAM. It is currently running the latest stable release of FreeBSD (12.0p7) and Tor (0.4.0.5). As far as I can tell, the machine is mostly idle: * The Tor process is the most active, and I've yet to see it go above 5% CPU. * Memory usage is under 1.5gb. * Running `speedtest-cli` (even to different servers using the `--server` option) consistently gives 600mbps+ in both directions to most destinations. * There's nothing interesting in `dmesg` or the debug logs. Does anyone have suggestions for what the bottleneck here might be? I'm happy to share more details about my configuration if that would be helpful. Thank you in advance for any help that you are willing to provide! I think Tor provides a lot of value, and I would like to provide as much bandwidth as I can to the network. -- Alec

6 7

Cherryservers (formerly balticservers) account terminated for exit relay
by Chris Kerr 31 Jul '19

31 Jul '19

I just heard from the hosting provider cherryservers.com that they are terminating my account (after 2.5 years) where I run the exit relay "ostwaldripening" (46.166.162.53), because they no longer wish to host tor exit nodes. I tried to create an account on trac.torproject.org to edit the "GoodBadISPs" wiki page, but the spam blocking stopped me from doing so.

5 4

Re: [tor-relays] Windows Relay Setup
by William Pate 31 Jul '19

31 Jul '19

Hi! Well, I certainly expected far more snarky responses. :) Thank you for the links. I'll check them out and, if I get it to work, maybe write up a guide for others. Thank you! William ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, July 14, 2019 1:44 AM, Barton Bruce <barton.bruce(a)gmail.com> wrote: > > > William, > > On 7/11/2019 6:58 PM, William Pate wrote: > > > 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. > > > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > There used to be a VIDALIA (sp?) kit that could simply be downloaded and > run on a windows machine. I then worked for an ISP/CLEC and had lots of > bandwidth so ran Vidaalia on a 64 bit Windows 7 Ultimate machine on my > desk at work. > > I never did hear why something had changed at the tor project so that > stopped working, but do remember a rude snippy condescending reply from > someone on the mailing list so I lost interest. > > I did get the head Tor guy from the Central Square Cambridge office of > TOR to come speak at a local networking group's monthly meeting we held > at a MicroSlush faclity in Burlington, MA and it was well received by a > packed audience. I think he now has left TOR and works for some ISP. > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus

4 3

exit operators: overall DNS failure rate above 5% - please check your DNS resolver
by nusenu 31 Jul '19

31 Jul '19

Dear Exit relay operators, first of all thanks for running exit relays! One of the crucial service that you provide in addition to forwarding TCP streams is DNS resolution for tor clients. Exit relays which fail to resolve hostnames are barely useful for tor clients. We noticed that lately the failure rates did increase significantly due to some major exit operators apparently having DNS issues and we would like to urge you to visit Arthur's "Tor Exit DNS Timeouts" page that shows you the DNS error rate for exit relays: https://arthuredelstein.net/exits/ (the page is usually updated once a day) Please consider checking your DNS if your exit relay consistently shows a non zero timeout rate - and make sure you run an up to date tor version. If you are an exit operator but have no (or no working) ContactInfo, please consider updating that field in your torrc so we can reach you if something is wrong with your relay. kind regards nusenu -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

11 15

Question about Bridges Bandwidth Authority
by s7r 29 Jul '19

29 Jul '19

Hello, I'd like to know more details about how exactly the bridge bandwidth authority works, and if we use the "weight" of each bridge for anything. For example, I have setup 5 obfs4 bridges, with the exact very same hardware resources and all on the same network speed of course. One of them gets used by clients (say 20-50 unique clients every 6 hours or so) while the rest of 4 are not used at all. This usage is not a concern for me, as its known bridges take time until they get used, depending on which bucket they have been assigned and etc. So I assume it's OK at this particular point in their lifetime to be unused by any client. But what I am curious about is, when I search them on RelaySearch, the used one has a measured bandwidth of over 2 MiB/s (and has the fast flag) while other 3 unused ones have bandwidths of between 50 and 60 KiB/s (these also have the fast flag) and there is one last one which is also not used and has a bandwidth of less than 10 KiB/s that does not have the fast flag. (Fast flag missing is also not my problem, I am just mentioning it as a side detail). Now I know for sure those values are not at all in according to the real environment. Each bridge should be at least capable of 3 MiB/s even if all 5 are used at the same time at their full speeds. Actually I have simulated this, it's not just theoretical. Is there anything related to usage, so that the bridge bandwidth authority only measures the used bridges? What could have cause such big discrepancy in my particular case, any ideas? Also, do we use the weight of each bridge in order to determine how much % probability it has to be served to a request in the bucket that is part of, or we don't use bridge weights for anything at all? Thanks!

3 4

Relay authority
by torjoy 26 Jul '19

26 Jul '19

Hi, this is my first post here. I'm running 3 bridges in brazil (maybe one of them becomes a middle-relay), so I want to know what we need here to have some bridge authority for example here in south america. Is too much different from a normal relay? I've already see the "authorithative flags" for torrc but dont made any changes. I think something more should be done and is not so easy. Best regards.

2 3

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

23 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