Re: [tor-relays] Relay MIGHTYWANG consensus issues and loss of STABLE flag
Hi Eddie Yes I saw your post on the day it happened and guessed that we are suffering from exactly the same issue that started at exactly the same time. I couldn't correlate the loss of stable flag with anything in recent Tor server releases but I am going to recheck those; I am currently working my way back through the consensus voting lists in the run-up to the 14th October to try and understand where the problem started, I'll report back here. thanks W On 29/10/21 18:57, Eddie wrote: Welcome to the club: https://gitlab.torproject.org/tpo/network-health/team/-/issues/128 Since Georg opened that (on my behalf) I too have lost the Stable flag. Cheers. On 10/29/2021 9:10 AM, Mighty Wang wrote: Hello fellow operators I have one pretty large relay, MIGHTYWANG which is an IP4/6 guard, dedicated hardware running on a 1Gb line uncontended. It is usually one of the top 5 relays by consensus weight but on the morning of 14th October it lost Guard status on account of losing the stable flag. I checked logs, connectivity and server health - nothing unusual, everything is generally pretty bullet proof in and around the relay and it had been running for well over a year without a reboot - just the very occasional Tor daemon restart following upgrades but no such activity prior to the 14th. So next I checked the consensus and I see that around half of the directory authorities seem to be not assigning the stable flag. See attached screenshot showing current consensus. The peering to each of those relays seems OK from what I can see (IP4 and IP6) so any idea what gives? I've got a MIGHTYWANG sitting here twiddling it's thumbs because have the directory authorities don't want to use it. Bit of a waste. I had similar things happen a few years ago with one of my old relays; again no obvious reason, just seemed to be the a random whim of the directory authorities. I've noticed a couple of other long term relays are in a similar position - is this some time of attack, deliberate action or just Tor magic? Wang -- MIGHTYWANG 9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC ___ 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 -- MIGHTYWANG 9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay MIGHTYWANG consensus issues and loss of STABLE flag
Thanks Sebastian On 29/10/21 19:04, Sebastian Hahn wrote: Hi Wang, On 29. Oct 2021, at 18:10, Mighty Wang wrote: I have one pretty large relay, MIGHTYWANG which is an IP4/6 guard, dedicated hardware running on a 1Gb line uncontended. It is usually one of the top 5 relays by consensus weight but on the morning of 14th October it lost Guard status on account of losing the stable flag. I checked logs, connectivity and server health - nothing unusual, everything is generally pretty bullet proof in and around the relay and it had been running for well over a year without a reboot - just the very occasional Tor daemon restart following upgrades but no such activity prior to the 14th. So next I checked the consensus and I see that around half of the directory authorities seem to be not assigning the stable flag. See attached screenshot showing current consensus. The peering to each of those relays seems OK from what I can see (IP4 and IP6) so any idea what gives? I've got a MIGHTYWANG sitting here twiddling it's thumbs because have the directory authorities don't want to use it. Bit of a waste. I had similar things happen a few years ago with one of my old relays; again no obvious reason, just seemed to be the a random whim of the directory authorities. I've noticed a couple of other long term relays are in a similar position - is this some time of attack, deliberate action or just Tor magic? Wang I operate gabelmoo and your relay seems to be unreachable via IPv6 from here. Here's a traceroute: traceroute to 2a02:29d0:8008:c0de:bad:beef:: (2a02:29d0:8008:c0de:bad:beef::), 30 hops max, 80 byte packets 1 informatik.gate.uni-erlangen.de (2001:638:a000:4140::1) 1.966 ms 2.037 ms 2.214 ms 2 constellation.gate.uni-erlangen.de (2001:638:a000::3341:33) 0.718 ms 0.770 ms 0.831 ms 3 yamato.gate.uni-erlangen.de (2001:638:a000::3033:30) 0.829 ms 1.122 ms 1.234 ms 4 * * * 5 * * * 6 * * * 7 ffm-bb1-v6.ip.twelve99.net (2001:2034:1:6b::1) 19.795 ms 19.786 ms 19.779 ms 8 prs-bb1-v6.ip.twelve99.net (2001:2034:1:be::1) 20.489 ms prs-bb2-v6.ip.twelve99.net (2001:2034:1:c1::1) 20.931 ms prs-bb1-v6.ip.twelve99.net (2001:2034:1:be::1) 20.509 ms 9 ldn-bb4-v6.ip.twelve99.net (2001:2034:1:7b::1) 19.517 ms ldn-bb1-v6.ip.twelve99.net (2001:2034:1:7a::1) 19.390 ms 19.334 ms 10 * * * 11 vaioni-ic326121-ldn-b2.ip.twelve99-cust.net (2001:2000:3080:937::2) 20.387 ms 19.464 ms 20.446 ms 12 2a02:29d0:0:1:: (2a02:29d0:0:1::) 39.577 ms 39.414 ms 39.363 ms 13 2a02:29d0:3:1003::1 (2a02:29d0:3:1003::1) 20.520 ms 20.514 ms * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Perhaps this helps analyze the problem? Cheers Sebastian Strangely your relay gabelmoo is one of the relays I checked IP4/IP6 connectivity to and I can hit your IP6 OK from MIGHTYWANG so there is a route, traceroute to 2001:638:a000:4140:::189 (2001:638:a000:4140:::189), 30 hops max, 80 byte packets 1 beijing.dsd-labs.com (2a02:29d0:8008::1) 0.091 ms 0.076 ms 0.088 ms 2 2a02:29d0:3:1003:: (2a02:29d0:3:1003::) 1.367 ms 1.378 ms 1.364 ms 3 2a02:29d0:0:1::1 (2a02:29d0:0:1::1) 1.487 ms 1.443 ms 1.458 ms 4 * * * 5 ldn-bb4-v6.ip.twelve99.net (2001:2034:1:7b::1) 1.839 ms ldn-bb1-v6.ip.twelve99.net (2001:2034:1:7a::1) 17.684 ms 17.402 ms 6 prs-bb1-v6.ip.twelve99.net (2001:2034:1:be::1) 17.454 ms prs-bb2-v6.ip.twelve99.net (2001:2034:1:c1::1) 18.639 ms 18.623 ms 7 ffm-bb1-v6.ip.twelve99.net (2001:2034:1:6b::1) 18.859 ms 17.696 ms ffm-bb2-v6.ip.twelve99.net (2001:2034:1:6c::1) 18.092 ms 8 kr-erl156-0.x-win.dfn.de (2001:638:c:a039::2) 21.150 ms 20.963 ms 21.541 ms 9 constellation.gate.uni-erlangen.de (2001:638:a000::3033:33) 21.509 ms 21.291 ms 22.232 ms 10 * informatik.gate.uni-erlangen.de (2001:638:a000::3341:41) 20.767 ms 21.339 ms 11 despari.informatik.uni-erlangen.de (2001:638:a000:4140:::189) 21.215 ms 20.971 ms 20.725 ms I think your UDP based traceroute is hitting my firewall and getting dropped but you do have a route to me - in fact your relay has a long term active connection to mine via IP6 right now: tcp6 0 0 2a02:29d0:8008:c0de:bad:beef:::443 2001:638:a000:4140:::189:41011 ESTABLISHED So it isn't an IP6 issue from what I can see (although that was an issue about 18 months ago as a result of some temporary peering issues). I checked all the DA relays on IP6 and IP4 and all have active connections to me via IP6 (where they support it) or IP4 so if it is a connectivity issue it must be transient and so far undetectable. There is something else happening here but I don't know what yet. thanks Wang ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor
[tor-relays] Relay MIGHTYWANG consensus issues and loss of STABLE flag
Hello fellow operators I have one pretty large relay, MIGHTYWANG which is an IP4/6 guard, dedicated hardware running on a 1Gb line uncontended. It is usually one of the top 5 relays by consensus weight but on the morning of 14th October it lost Guard status on account of losing the stable flag. I checked logs, connectivity and server health - nothing unusual, everything is generally pretty bullet proof in and around the relay and it had been running for well over a year without a reboot - just the very occasional Tor daemon restart following upgrades but no such activity prior to the 14th. So next I checked the consensus and I see that around half of the directory authorities seem to be not assigning the stable flag. See attached screenshot showing current consensus. The peering to each of those relays seems OK from what I can see (IP4 and IP6) so any idea what gives? I've got a MIGHTYWANG sitting here twiddling it's thumbs because have the directory authorities don't want to use it. Bit of a waste. I had similar things happen a few years ago with one of my old relays; again no obvious reason, just seemed to be the a random whim of the directory authorities. I've noticed a couple of other long term relays are in a similar position - is this some time of attack, deliberate action or just Tor magic? Wang -- MIGHTYWANG 9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
On 21/07/20 18:16, nusenu wrote: Hi, I'm happy to finally announce version 1 of the ContactInfo Information Sharing Specification: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification This is an effort that started in 2017 as you can see on github. ... regards, nusenu Hi Nunsenu Firstly, thank you for taking the time to look at the issue of malicious relay operators and come up with some potential approaches for addressing it. If I understand correctly your objective is to increase the level of effort required to run a relay, at least when it comes to the larger relays. I assume that you assume that if more effort is required then malicious relay operators will shut down and go elsewhere? I do not feel the proposed verification measures will make a malicious relay operators life sufficiently more difficult unfortunately. Malicious relay operators already expend relatively large amounts of money and presumably effort to do their thing; the example you gave initially talked about a potentially malicious operator providing up to 23% of exit capacity - that must be a very expensive already surely? I can't help but feel that the issue of malicious operators could perhaps be better addressed by 1) Having a valid email contact address for any given relay as you already suggest; and 2) Having each operator join this mailing-list (using the above email address) and introduce, anonymously or otherwise, themselves and their relay(s). To have either the guard or exit flags on your relay you would need to complete the aforementioned 2 steps. In cases where there are concerns over a relay or set of relays then there would be a transparent and public forum where those concerns can be both raised and (hopefully) addressed, i.e. this mailing list. I get that it is not as interesting as a more technical approach but IMHO it would be more effective and could be implemented almost immediately and is actually not that easy to game compared to technical solutions. Anyway these are just my thoughts. Thanks again for taking the time to look at the problem. yours M Wang -- MIGHTYWANG 9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)
9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC MIGHTYWANG Viva la Wang! On 08/07/20 18:36, gus wrote: Dear Relay Operators, Do you want your relay to be a Tor fallback directory mirror? Will it have the same address and port for the next 2 years? Just reply to this email with your relay's fingerprint. Important: you have until July 23 2020 to reply to this message to get in the fallback directory mirror list. If your relay is on the current fallback list, you don't need to do anything. If you're asking: Q: What's a fallback directory mirror? Fallback directory mirrors help Tor clients connect to the network. For more details, see [1]. Q: Is my relay on the current list? Search [2] and [3] for your relay fingerprint or IP address and port. [2] is the current list of fallbacks in Tor. [3] is used to create the next list of fallbacks. Q: What do I need to do if my relay is on the list? Keep the same IP address, keys, and ports. Email tor-relays if the relay's details change. Q: Can my relay be on the list next time? We need fast relays that will be on the same IP address and port for 2 years. Reply to this email to get on the list, or to update the details of your relay. Once or twice a year, we run a script to choose about 150-200 relays from the potential list [3] for the list in Tor [2]. Q: Why didn't my relay get on the list last time? We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might be down when we check. That's ok, we will check it again next time. It's good to have some new relays on the list every release. That helps tor clients, because blocking a changing list is harder. cheers, Gus [1] https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDirectoryMirrors [2] https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc [3] https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list [4] https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_2017-05-16-0815-09cd78886.log ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- MIGHTYWANG 9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Debian-tor Vs User
Switch from root to user = su usrname >Password. The problems start when I try and su to debian-tor. First I get a query for a password which it doesn't have. So I make a pass for debian-tor and enter it when I su to debian-tor. I enter whoami and the response is: user and not debian-tor. With or without a password it doesn't work. Secondly, if I su debia-tor > passwrd - sudo -u debian-tor nyx it produces a page and a half of pure gibberish. Sudo -i to root and enter nyx, it operates perfectly; and yes I understand I shouldn't run nyx as root. How do I become debian-tor so I can operate my bridge correctly? Adriann -- It can't be, so therefore it isn't - stanton Friedman Hello Kathi You need to add your standard user to the debian-tor group. it is not necessary to set a password for the debian-tor user or to try to su to that debian-tor. If your username is kathi then as the following one-liner should do what you need on debian: "sudo adduser kathi debian-tor" Then arm/nyx should fire up as the kathi user... regards Wang -- MIGHTYWANG 9B2BC7EFD661072AFADC533BE8DCF1C19D8C2DCC ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
