Re: [tor-relays] Relay in a stop/start loop
On 06.04.2020 11:01, Totor be wrote:
When starting tor, it goes to the point of IP identification and then
starts shutting down ("Interrupt: we have stopped accepting new
connections...")
It attempts then to restart immediately and loops start --> interrupt
-->
start etc...
Any idea where too start investigating??
Apr 06 10:33:18.724 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 06 10:33:18.725 [notice] Opened Socks listener on 127.0.0.1:9050
^^^
Has nothing to do with your problem. Why do listen on socks port?
Apr 06 10:35:13.000 [notice] Starting with guard context "default"
Apr 06 10:35:13.000 [notice] Signaled readiness to systemd
Apr 06 10:35:13.000 [notice] Interrupt: we have stopped accepting new
connections, and will shut down in 30 seconds. Interrupt again to exit
now.
Look in var/log/syslog if systemd might not find $TORPIDDIR/tor.pid
--
╰_╯ Ciao Marco!
Debian GNU/Linux
It's free software and it gives you freedom!
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit stops after one year, then again after few days
Could it be the VPS company has changed its tolerance of exits and is stopping it? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Sudend drop in Consensus Weight
On Tue, Apr 07, 2020 at 01:53:42PM +0200, Clément Février wrote: > Hello, > > On April 5th, the consensus weight of my tor relay dropped to 0, see > https://metrics.torproject.org/rs.html#details/33D88F331408141F2A2CC563239E54E48F7A211B > As far as I know, nothing specific happened, no update nor reboot. Nothing > in the logs. > Can anyone explain me what happened? It looks like it should be back into better shape now: go to the bottom of https://consensus-health.torproject.org/#relayinfo and put in your relay fingerprint and you'll see that the consensus weight is now in the 8000 range. The graphs on https://metrics.torproject.org/rs.html#details/33D88F331408141F2A2CC563239E54E48F7A211B show the beginning of a recovery too. Thanks, --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Doubt related to Bridge relay
Hi, > On 8 Apr 2020, at 04:05, Imre Jonk wrote: > >> On Mon, 2020-04-06 at 11:07 -0500, Ismael Castro wrote: >> 1. Can I use tor browser from the same computer the bridge relay node >> is set up? Navigation will remain anonymous (at least similar than >> when using only tor browser)? > > You certainly can, the Tor Browser software will still be picking > three-hop circuits through regular (non-bridge) relays. Your traffic > therefore won't loop around and back through your bridge or something. > > If you were to run a regular relay on your computer, then you should > consider telling Tor Browser to avoid building circuits through your > own relay. You can use the ExcludeNodes option for this, and maybe > StrictNodes as well if you want to be extra safe. You can set these > options in Tor Browser's torrc file. Tor automatically detects its own IP address, and avoids nearby relays. So you shouldn't need to modify Tor Browser's config. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit stops after one year, then again after few days
Hi, > On 7 Apr 2020, at 21:34, ylms wrote: > > As written above, I run an Exit (for many years, with the current setup > since 04.2019) but on 30. March 2020 it stopped, I was unable to > determine any reason. Have you checked tor's logs? They are usually in /var/log/tor/log If you have logrotate configured, they might have already been deleted, because 30 March is more than 1 week ago. > So I installed updates and since there were some Kernel updates I also > rebooted the machine. The Exit was back up and ran again till ~36h ago. > Same situation again, I have no idea why it stopped. > > I now activated "Log notice syslog", I think this was in the standard > torrc which is installed with the package of Ubuntu 18.04.4 LTS anyway, > but there is not entries in journalctl. Only Start/Stop/Reload events > are shown in the journal for unit tor.service since 100 day ago. Have you tried reading /var/log/sys log directly? > Can someone help me to troubleshoot this problem, could the fingerprint > be blacklisted? In this case would the Exit come back up running for a > few days as described above? Most of the time, blacklisting just makes Tor log a message in its logs. And the directory authorities stop publishing the relay in the consensus. (We haven't made any changes to required protocols recently. If we do, very old Tor versions may shut down.) Here's what we need to know to be more helpful: * your relay fingerprint * your Tor version * tor's logs when it shuts down T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Advertised Bandwidth vs. RelayBandwidthRate
Hi, > On 7 Apr 2020, at 19:56, petra...@protonmail.ch wrote: > > > Hello all - I see a constant mismatch of my relay regarding the Advertised > Bandwidth vs. the defined and available RelayBandwidthRate. > > Tor metrics usually only shows around 1.3 MiB/s as Advertised Bandwidth > (Bandwidth rate: 3 MiB/s, Bandwidth burst: 6 MiB/s). > > The torrc config defines: > RelayBandwidthRate 24 Mbit > RelayBandwidthBurst 48 Mbit > > So everything looks fine, except the Advertised Bandwidth seems to be too > low. Fingerprint is 605EE4375EE4C38215C8949F5808863749FD4F4A and there is > plenty of bandwidth available (1 Gbps link). The connection is up-and-running > perfectly fine without any issues or interruptions for at least a month. > > Any idea, why the Advertised Bandwidth is so low? On Relay Search, the Advertised Bandwidth is made up of 3 different bandwidths. For your relay, they are: Bandwidth rate: 3 MiB/s Bandwidth burst: 6 MiB/s Observed bandwidth: 1.3 MiB/s You can see these details by clicking on the Advertised Bandwidths figure on: https://metrics.torproject.org/rs.html#details/605EE4375EE4C38215C8949F5808863749FD4F4A The observed bandwidth is the maximum bandwidth peak your relay has seen. It's updated each day. Tor is a low latency network, so it's normal for relays to be loaded at 10-50% of their capacity. (Congestion increases latency.) If you'd like your relay to get more traffic, please increase your RelayBandwidthRate and RelayBandwidthBurst. T ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Sudend drop in Consensus Weight
Clément Février: > Hello, > > On April 5th, the consensus weight of my tor relay dropped to 0, see > https://metrics.torproject.org/rs.html#details/33D88F331408141F2A2CC563239E54E48F7A211B > > As far as I know, nothing specific happened, no update nor reboot. > Nothing in the logs. > Can anyone explain me what happened? I think your relay got hit by one of the critical bugs in our sbws (simple bandwidth scanner). We had some outage of Torflow bandwidth scanners so that sbws ones got the majority when voting. We saw bugs like #33775[1] as a result which affected a number of relays. Looking at the current results for your relay it seems things getting back to the previous state. That's due to some directory authority operators either switching away from sbws to Torflow again or getting Torflow going on their machines (again). (see Roger's mail yesterday[2] for the different options we had in mind and my mail[3] today for the state of sbws and our next steps in that area for more context) Sorry for the inconvenience but things should go back to a normal level rather soon, Georg [1] https://trac.torproject.org/projects/tor/ticket/33775 [2] https://lists.torproject.org/pipermail/tor-relays/2020-April/018337.html [3] https://lists.torproject.org/pipermail/tor-relays/2020-April/018344.html signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is this probing normal for a bridge
On Mon, 2020-04-06 at 14:04 -0700, Eddie wrote: > On the VPS where I run a couple of bridges, I often see the > following: > > tcp6 0 0 aaa.bbb.cc.dd:443 194.14.247.1:18913 > SYN_RECV > tcp6 0 0 aaa.bbb.cc.dd:443 54.93.50.35:18457 > SYN_RECV > tcp6 0 0 aaa.bbb.cc.dd:443 194.68.0.1:29917 > SYN_RECV > > Is this normal probing by the script kiddies or is it specific > because > I'm running the bridges. I'd say the former, it is most probably regular Internet background noise. Regular relays and especially exit relays are a much bigger target than bridges (whose IP addresses are not conveniently listed). This kind of port scanning should be quite harmless as long as you're not exposing vulnerable software. Imre signature.asc Description: This is a digitally signed message part ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Doubt related to Bridge relay
Hi Ismael, welcome to tor-relays! Great to hear that you are helping the Tor network grow. On Mon, 2020-04-06 at 11:07 -0500, Ismael Castro wrote: > 1. Can I use tor browser from the same computer the bridge relay node > is set up? Navigation will remain anonymous (at least similar than > when using only tor browser)? You certainly can, the Tor Browser software will still be picking three-hop circuits through regular (non-bridge) relays. Your traffic therefore won't loop around and back through your bridge or something. If you were to run a regular relay on your computer, then you should consider telling Tor Browser to avoid building circuits through your own relay. You can use the ExcludeNodes option for this, and maybe StrictNodes as well if you want to be extra safe. You can set these options in Tor Browser's torrc file. > 2. Will I notice any decrease or increase in tor network navigation > speed? (understanding that I'll previously set up a max bandwidth to > the node) You will not notice an increase in Tor Browser navigation speed, and if you do, it won't be because of your bridge. You could notice a decrease in navigation speed if your bridge is taking up too much bandwidth, especially if you are on a poor Internet connection. If that happens, consider decreasing the bandwidth available to the bridge with the RelayBandwidthRate option. Note that bridges are recommended to have at least 1 Mbit/s (0.12 MiB/s) of available bandwidth. > 3. Any other concern I should be aware of? Keep the IP address of your bridge private to make it harder for censors to add it to their blacklists. Also, configure your firewall to allow inbound connections to your bridge so it is actually usable. Those are your most important concerns, the rest should all be documented here: https://community.torproject.org/relay/. Have fun running your bridge :) Imre signature.asc Description: This is a digitally signed message part ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Update on the status for sbws (simple bandwidth scanner)
Hello everyone! Some of you might have read about relay operators being affected by a drop of bandwidth on their relays recently or might even have hit this problem themselves. Bug 33775[1] has more details about what is going on (in short: sbws, our new bandwidth scanner, has still release critical bugs but the instances running it got recently the voting majority as Torflow is showing its age and the duct tape around it is wearing off). Roger forwarded a mail to this list yesterday as well about short term hacks to solve this problem[2]. Things are looking good at that front so far. We are optimistic that the situation is getting better substantially rather soon as some of our directory authorities are either switching right now to using Torflow data again or making progress in resolving their Torflow related issues that prevented them from running it. We thought it would be helpful to give an update about our remaining sbws work as well. So, the good news here is that we aim to have all the critical bugs fixed by end of April (yes, this month :)). Right now we know of the following five: #33350[3] #33775[4] #30735[5] #33009[6] #30719[7] We have the last two in `needs_review` (the last one via #30905[8]) and are currently distributing the first three among developers working on sbws, so we can work in parallel on them. There is the risk that behind those bugs some other critical bugs lurk, which we have not found yet. To mitigate that we'll switch one bandwidth authority to running sbws's git master branch so we detect those bugs as early as possible should they exist. Finally, we are working on a proper transition plan away from Torflow to avoid mistakes we've made so far and provide as little friction as possible for all parties involved in the whole process. Let us know if you have any questions. Either way, I hope I could get the point out that the current situation is worked on and temporal. There is no need to shut down relays as the result of the current issues. :) Georg [1] https://trac.torproject.org/projects/tor/ticket/33775 [2] https://lists.torproject.org/pipermail/tor-relays/2020-April/018337.html [3] https://trac.torproject.org/projects/tor/ticket/33350 [4] https://trac.torproject.org/projects/tor/ticket/33775 [5] https://trac.torproject.org/projects/tor/ticket/30735 [6] https://trac.torproject.org/projects/tor/ticket/33009 [7] https://trac.torproject.org/projects/tor/ticket/30719 [8] https://trac.torproject.org/projects/tor/ticket/30905 signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit stops after one year, then again after few days
I can add some information I forgot before. In "nyx" it showed my that the Relay had no flags, now after another reboot it show at least "Exit, Fast, Running, V2Dir, Valid" again, I think the other flags were lost due to the relay being kind of offline. Currently nyx shows about 4 MB/sec, not very much. Regards yl On 4/7/20 12:37 PM, ylms wrote: > Hello all > As written above, I run an Exit (for many years, with the current setup > since 04.2019) but on 30. March 2020 it stopped, I was unable to > determine any reason. > So I installed updates and since there were some Kernel updates I also > rebooted the machine. The Exit was back up and ran again till ~36h ago. > Same situation again, I have no idea why it stopped. > > I now activated "Log notice syslog", I think this was in the standard > torrc which is installed with the package of Ubuntu 18.04.4 LTS anyway, > but there is not entries in journalctl. Only Start/Stop/Reload events > are shown in the journal for unit tor.service since 100 day ago. > > Can someone help me to troubleshoot this problem, could the fingerprint > be blacklisted? In this case would the Exit come back up running for a > few days as described above? > > Regards and thank you very much for any support. > yl > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Sudend drop in Consensus Weight
Hello, On April 5th, the consensus weight of my tor relay dropped to 0, see https://metrics.torproject.org/rs.html#details/33D88F331408141F2A2CC563239E54E48F7A211B As far as I know, nothing specific happened, no update nor reboot. Nothing in the logs. Can anyone explain me what happened? Thanks, Clèm ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Exit stops after one year, then again after few days
Hello all As written above, I run an Exit (for many years, with the current setup since 04.2019) but on 30. March 2020 it stopped, I was unable to determine any reason. So I installed updates and since there were some Kernel updates I also rebooted the machine. The Exit was back up and ran again till ~36h ago. Same situation again, I have no idea why it stopped. I now activated "Log notice syslog", I think this was in the standard torrc which is installed with the package of Ubuntu 18.04.4 LTS anyway, but there is not entries in journalctl. Only Start/Stop/Reload events are shown in the journal for unit tor.service since 100 day ago. Can someone help me to troubleshoot this problem, could the fingerprint be blacklisted? In this case would the Exit come back up running for a few days as described above? Regards and thank you very much for any support. yl ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Advertised Bandwidth vs. RelayBandwidthRate
Hello all - I see a constant mismatch of my relay regarding the Advertised Bandwidth vs. the defined and available RelayBandwidthRate. Tor metrics usually only shows around 1.3 MiB/s as Advertised Bandwidth (Bandwidth rate: 3 MiB/s, Bandwidth burst: 6 MiB/s). The torrc config defines: RelayBandwidthRate 24 Mbit RelayBandwidthBurst 48 Mbit So everything looks fine, except the Advertised Bandwidth seems to be too low. Fingerprint is 605EE4375EE4C38215C8949F5808863749FD4F4A and there is plenty of bandwidth available (1 Gbps link). The connection is up-and-running perfectly fine without any issues or interruptions for at least a month. Any idea, why the Advertised Bandwidth is so low?___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
