Re: [tor-relays] [tor-talk] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship
What's the chances of switching to a mailing list system that doesn't expose your email address to everyone on the list when you reply? On Fri, Aug 31, 2018, 18:06 Gary wrote: > Hi, > > Yes I too got messages from Cynthia every few hours (wanting to meet) > until I blocked the email address. > > Thanks > > On Fri, 31 Aug 2018, 22:52 Matthew Glennon, > wrote: > >> Anyone else getting nude photos and random links from Cynthia Coleman < >> cynthiacoleman843...@ru.irzum.com> attached to this (and other thread(s) >> lately? Spam obviously, but ugh. >> >> Matthew Glennon >> >> Want to make sure only I can read your message? Use PGP! >> (Then paste the encrypted text into an email for me to receive!) >> https://keybase.io/crazysane/ >> https://pgp.key-server.io/pks/lookup?op=get&search=0x92E43A8A9EF85EB4 >> >> >> On Fri, Aug 31, 2018 at 5:01 PM Conrad Rockenhaus >> wrote: >> >>> Good God every conversation, now. Anyway. >>> >>> This exit isn’t bad exit material. Turkey has been known to block Tor >>> though, I’m actually proud of this guy for having the cajones (also known >>> as balls to those of you who don’t habla espanol) to operate an exit in >>> country such as Turkey, which absolutely hates freedom inducing >>> technologies such as Tor. Let’s give this guy (or gal) the atto-boy by >>> marking the exit as a bad-exit just because stuff gets blocked in >>> autocratic regimes that this operator has no control over. None, absolutely >>> none. They screw with the DNS servers over there, that’s why during the >>> last uprising they were tagging “8.8.8.8” on the walls. >>> >>> Now they’re doing things a little more sophisticated. Either way, this >>> guy gives us a window to see what is blocked and what isn’t blocked within >>> the Turkish thunderdome. >>> >>> -Conrad >>> >>> > On Aug 30, 2018, at 9:24 PM, Nathaniel Suchy wrote: >>> > >>> > What if a Tor Bridge blocked connections to the tor network to >>> selective >>> > client IPs? Would we keep it in BridgeDB because its sometimes useful? >>> > >>> > On Thu, Aug 30, 2018 at 10:02 PM arisbe wrote: >>> > >>> >> Children should be seen and not herd. The opposite goes for Tor >>> relays. >>> >> Arisbe >>> >> >>> >> >>> >> On 8/30/2018 2:11 PM, Nathaniel Suchy wrote: >>> >> >>> >> So this exit node is censored by Turkey. That means any site blocked >>> in >>> >> Turkey is blocked on the exit. What about an exit node in China or >>> Syria or >>> >> Iraq? They censor, should exits there be allowed? I don't think they >>> >> should. Make them relay only, (and yes that means no Guard or HSDir >>> flags >>> >> too) situation A could happen. The odds might not be in your favor. >>> Don't >>> >> risk that! >>> >> >>> >> Cordially, >>> >> Nathaniel Suchy >>> >> >>> >> On Thu, Aug 30, 2018 at 3:25 PM grarpamp wrote: >>> >> >>> >>> This particular case receiving mentions for at least a few months... >>> >>> D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114 >>> >>> >>> >>> The relay won't [likely] be badexited because neither it nor its >>> upstream >>> >>> is >>> >>> shown to be doing anything malicious. Simple censorship isn't enough. >>> >>> And except for such limited censorship, the nodes are otherwise fully >>> >>> useful, and provide a valuable presence inside such regions / >>> networks. >>> >>> >>> >>> Users, in such censoring regimes, that have sucessfully connected >>> >>> to tor, already have free choice of whatever exits they wish, >>> therefore >>> >>> such censorship is moot for them. >>> >>> >>> >>> For everyone else, and them, workarounds exist such as,,, >>> >>> https://onion.torproject.org/ >>> >>> http://yz7lpwfhhzcdyc5y.onion/ >>> >>> search engines, sigs, vpns, mirrors, etc >>> >>> >>> >>> Further, whatever gets added to static exitpolicy's might move out >>> >>> from underneath them or the censor, the censor may quit, or the
Re: [tor-relays] [tor-talk] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship
Anyone else getting nude photos and random links from Cynthia Coleman < cynthiacoleman843...@ru.irzum.com> attached to this (and other thread(s) lately? Spam obviously, but ugh. Matthew Glennon Want to make sure only I can read your message? Use PGP! (Then paste the encrypted text into an email for me to receive!) https://keybase.io/crazysane/ https://pgp.key-server.io/pks/lookup?op=get&search=0x92E43A8A9EF85EB4 On Fri, Aug 31, 2018 at 5:01 PM Conrad Rockenhaus wrote: > Good God every conversation, now. Anyway. > > This exit isn’t bad exit material. Turkey has been known to block Tor > though, I’m actually proud of this guy for having the cajones (also known > as balls to those of you who don’t habla espanol) to operate an exit in > country such as Turkey, which absolutely hates freedom inducing > technologies such as Tor. Let’s give this guy (or gal) the atto-boy by > marking the exit as a bad-exit just because stuff gets blocked in > autocratic regimes that this operator has no control over. None, absolutely > none. They screw with the DNS servers over there, that’s why during the > last uprising they were tagging “8.8.8.8” on the walls. > > Now they’re doing things a little more sophisticated. Either way, this guy > gives us a window to see what is blocked and what isn’t blocked within the > Turkish thunderdome. > > -Conrad > > > On Aug 30, 2018, at 9:24 PM, Nathaniel Suchy wrote: > > > > What if a Tor Bridge blocked connections to the tor network to selective > > client IPs? Would we keep it in BridgeDB because its sometimes useful? > > > > On Thu, Aug 30, 2018 at 10:02 PM arisbe wrote: > > > >> Children should be seen and not herd. The opposite goes for Tor relays. > >> Arisbe > >> > >> > >> On 8/30/2018 2:11 PM, Nathaniel Suchy wrote: > >> > >> So this exit node is censored by Turkey. That means any site blocked in > >> Turkey is blocked on the exit. What about an exit node in China or > Syria or > >> Iraq? They censor, should exits there be allowed? I don't think they > >> should. Make them relay only, (and yes that means no Guard or HSDir > flags > >> too) situation A could happen. The odds might not be in your favor. > Don't > >> risk that! > >> > >> Cordially, > >> Nathaniel Suchy > >> > >> On Thu, Aug 30, 2018 at 3:25 PM grarpamp wrote: > >> > >>> This particular case receiving mentions for at least a few months... > >>> D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114 > >>> > >>> The relay won't [likely] be badexited because neither it nor its > upstream > >>> is > >>> shown to be doing anything malicious. Simple censorship isn't enough. > >>> And except for such limited censorship, the nodes are otherwise fully > >>> useful, and provide a valuable presence inside such regions / networks. > >>> > >>> Users, in such censoring regimes, that have sucessfully connected > >>> to tor, already have free choice of whatever exits they wish, therefore > >>> such censorship is moot for them. > >>> > >>> For everyone else, and them, workarounds exist such as,,, > >>> https://onion.torproject.org/ > >>> http://yz7lpwfhhzcdyc5y.onion/ > >>> search engines, sigs, vpns, mirrors, etc > >>> > >>> Further, whatever gets added to static exitpolicy's might move out > >>> from underneath them or the censor, the censor may quit, or the exit > >>> may fail to maintain the exitpolicy's. None of which are true > >>> representation > >>> of the net, and are effectively censorship as result of operator action > >>> even though unintentional / delayed. > >>> > >>> Currently many regimes do limited censorship like this, > >>> so you'd lose all those exits too for no good reason, see... > >>> https://ooni.torproject.org/ > >>> > >>> > https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_country > >>> > >>> And arbitrarily hamper spirits, tactics, and success of volunteer > >>> resistance communities and operators in, and fighting, such regimes > >>> around the world. > >>> > >>> And if the net goes chaotic, majority of exits will have limited > >>> visibility, > >>> for which exitpolicy / badexit are hardly manageable solutions either, > >>> and would end up footshooting out many partly u
Re: [tor-relays] Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship
Could this be mitigated with a detection addon in Tor Browser? Detect that the site may be blocked at the exit and offer to fetch a new circuit for the site? On Thu, Aug 30, 2018, 19:22 Nathaniel Suchy wrote: > The exit is behind a filtered ISP. Opposed to a website blocking exits. > That’s the difference. > > 1) The content provider causes the block. > 2) The exit causes the block. > > In situation two a censored user may give up on Tor entirely. Should we > allow exits in China or Iraq or Syria or Turkey or the several other > countries. What if their governments who can afford it spin up 10,000 exits > in an effort to censor the Tor Network. Will we sit idly by and allow it? > > On Thu, Aug 30, 2018 at 7:17 PM Pascal Terjan wrote: > >> A country's ISPs blocking some websites is not the exit blocking it and >> the result is the same than websites blocking the country, users of that >> exit can't access the websites just because the exit is in that country but >> doesn't do any filtering itself. >> >> On Thu, 30 Aug 2018, 16:14 Nathaniel Suchy, wrote: >> >>> That’s a website blocking Tor users. Not a Tor Exit blocking a website. >>> On Thu, Aug 30, 2018 at 7:06 PM Pascal Terjan wrote: >>> On Thu, 30 Aug 2018, 14:11 Nathaniel Suchy, wrote: > So this exit node is censored by Turkey. That means any site blocked > in Turkey is blocked on the exit. What about an exit node in China or > Syria > or Iraq? They censor, should exits there be allowed? I don't think they > should. Make them relay only, (and yes that means no Guard or HSDir flags > too) situation A could happen. The odds might not be in your favor. Don't > risk that! > Where do you put the limit? Various categories of websites are blocked in various countries either by ISPs or by content providers. For example should exits not be allowed to run in Germany due to https://en.m.wikipedia.org/wiki/Blocking_of_YouTube_videos_in_Germany ? Or not allow exits in EU due to the number of US websites deciding to block all of EU IPs to not have to comply to GDPR? ___ 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 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 mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Help us get recent cached consensuses from your relay
Sorry I didn't get a chance to do this sooner - I've been out of the office without access to the box. My consensus history is lower than 68. Regards. On Mon, Aug 6, 2018 at 3:39 PM Karsten Loesing wrote: > On 2018-08-06 16:41, Roger Dingledine wrote: > > On Mon, Aug 06, 2018 at 09:07:32PM +1000, teor wrote: > >> We???re now looking for a few more operators who have more than: > >> > >> 70 document-type consensus > >> > >> So that we have a few redundant copies. > > > > moria1 reported 86. I've put the tarball here: > > > > https://freehaven.net/~arma/2018-08-06-diff-cache.tar.bz2 > Thanks, everyone! We have enough consensus copies to fill the gap. We > already inflated them and imported them into CollecTor: > > > https://metrics.torproject.org/collector/recent/relay-descriptors/consensuses/ > > It might take a short while for Onionoo and Tor Metrics to notice, but > on CollecTor we're not missing any data anymore. > > Thanks, teor, for starting this call for help, and thanks, everyone, for > sending their descriptors. Yay! > > All the best, > Karsten > > _______ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] dir port on non exit
I have an exit page set on my nonexit guard just for easy identification by sysadmins investigating why their users are connecting to it. I don't have a specifically identifiable reverse hostname. On Thu, Aug 2, 2018, 15:11 TorGate wrote: > is a blank page enoth. > or is this a god ide to use the exit page and change it to non exit > > TorGate > torgate(at)linux-hus.dk > > > > > Am 02.08.2018 um 21:08 schrieb TorGate : > > i have one exit and two nonexit. > > > TorGate > torgate(at)linux-hus.dk > > > > > Am 02.08.2018 um 21:04 schrieb Matt Traudt : > > On 8/2/18 15:02, Roger Dingledine wrote: > > On Thu, Aug 02, 2018 at 08:53:44PM +0200, TorGate wrote: > > Hi again, > is the dir port on a nonexit node a god ide ? > > > Having a separate DirPort open matters less and less these days. > > In the past it used to be the signal for clients about whether you > are providing cached directory information. Now every relay does that > by default, and clients fetch it via the encrypted ORPort connection, > so your DirPort will go mostly unused these days. > > So, "feel free if it's easy, but also feel free not to." > > Thanks for running a relay! > --Roger > > > Also, you won't set DirPortFrontPage since you aren't an exit. (This is > the only way I could come up with why asking about DirPort in the > context of exit vs non-exit made sense) > > Hope that helps > > Matt > ___ > 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 mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor alpha users: if you are still running 0.3.3.5-rc..
I would guess that people that made this mistake just misunderstood how apt sources work? Just unfamiliar with the distribution method? If that's you: You can have more than one source that supplies a given package and it's apt's job to pick the right one (or make you do it if it can't.) So you can just leave the stable branch listed - generally whichever source has the higher available version will win. You get the cutting edge alphas until they push it to stable (and you can remove/update the alpha source at your leisure.) Happy to help with the test branches. On Tue, Jul 3, 2018 at 9:54 AM nusenu wrote: > Dear debian/ubuntu tor alpha repo users, > > there is an oddly high number of > relays running 0.3.3.5-rc > which was the last version before the 0.3.3.x alpha repo > has been discontinued. > > If you are doing apt upgrades and don't get tor v0.3.3.7 your sources list > is > likely incorrectly setup (only containing the experimental lines without > the tor stable lines), > please ensure you copy and paste the sources.list lines from > > https://www.torproject.org/docs/debian.html.en#ubuntu > > after choosing your settings from the drop down. > > Note: as already noted on this list, the page is slightly outdated. > > If you want to help testing 0.3.4.x you should replace > '0.3.3.x' with '0.3.4.x' > in your sources.list > > > bonus points if you want to share > the reason why you had a misconfigured sources.list > file (maybe we can improve / avoid that somewhere) > > -- > https://twitter.com/nusenu_ > https://mastodon.social/@nusenu > > _______ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ 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
924B24AFA7F075D059E8EEB284CC400B33D3D036 Will be stable for the foreseeable future and is available as a fallback if needed. On Tue, Jun 26, 2018, 12:41 Colin Childs wrote: > Hello Tor 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. > > If your relay is on the current 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. > > Q. I already have a relay in the fallback list, can I add another? > > We will pick up to 7 relays per operator to be in the fallback list. > Please send > any relays that you would like considered for the fallback list. > > Thanks for considering and/or being a fallback directory mirror! > > [1]: > https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors > [2]: https://gitweb.torproject.org/tor.git/tree/src/or/fallback_dirs.inc > [3]: > https://gitweb.torproject.org/tor.git/tree/scripts/maint/fallback.whitelist > [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 > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Prepping bridges for censorship
No - and I don't think a standard port should be chosen. Tor comes with defaults and that's probably good enough. Keep them if you want, or customize them to fit your situation - the consensus has no problem adjusting to your customer port numbers. On the contrary, allowing a bad actor to know (for sure) what port a Bridge is using is bad news for the security of the network as a whole. It's a much better idea to let the Bridge Operator adjust the port number to their situation since they have to advertise the port to their subscribers externally anyway. For Guards, it doesn't really matter since the IP/Port pair is listed in the consensus. If a network operator really wants to attempt to block all of the Tor Guards, they could parse a list of Guard IP:Port pairs no matter what port you choose to use (this is where Bridges come in handy). Using 443/80 really doesn't matter if you intend to run a Middle - since tor <-> tor shouldn't be a problem. There's no real downside to using 443/80 on a Guard; you may very well be available to more clients as a result of using it. On Fri, Jun 22, 2018 at 3:43 PM Keifer Bly wrote: > Yes, but are all guard and bridge relays configured like this? > > > > Maybe this should be a requirement for running a guard or bridge relay for > this reason. > > > > What does everyone think? > > > > *From: *Matthew Glennon > *Sent: *Friday, June 22, 2018 5:18 AM > *To: *tor-relays@lists.torproject.org > *Subject: *Re: [tor-relays] Prepping bridges for censorship > > > > This is the reasoning I go with for using 443/80. > > > > On Fri, Jun 22, 2018 at 8:11 AM Martin Kepplinger > wrote: > > Am 21.06.2018 21:48 schrieb Keifer Bly: > > Hi, > > > > So I had a thought. It seems like a lot of the relays run off of > > various port numbers (of course). However if all of the relays and > > bridges are running off of various port numbers (ie 9001, 1, > > etc.), couldn’t this stop censored users (who’s isp or local firewall > > only allows certain ports like 80 and 443) from being able to connect > > to the tor network even when using bridges due to the port that the > > bridge of guard relay being run on a port number that is blocked by > > the isp or local firewall? > > > > Just a thought. > > Sure, just like for guard relays, for bridges it makes sense to > configure > ORPort to be 443 or 80, to be reachable from behind messy firewalls. > > martin > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > -- > > Matthew Glennon > > matthew@glennon.online > > PGP Signing Available Upon Request > https://keybase.io/crazysane > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Prepping bridges for censorship
This is the reasoning I go with for using 443/80. On Fri, Jun 22, 2018 at 8:11 AM Martin Kepplinger wrote: > Am 21.06.2018 21:48 schrieb Keifer Bly: > > Hi, > > > > So I had a thought. It seems like a lot of the relays run off of > > various port numbers (of course). However if all of the relays and > > bridges are running off of various port numbers (ie 9001, 1, > > etc.), couldn’t this stop censored users (who’s isp or local firewall > > only allows certain ports like 80 and 443) from being able to connect > > to the tor network even when using bridges due to the port that the > > bridge of guard relay being run on a port number that is blocked by > > the isp or local firewall? > > > > Just a thought. > > Sure, just like for guard relays, for bridges it makes sense to > configure > ORPort to be 443 or 80, to be reachable from behind messy firewalls. > > martin > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Relay Operators Needs
On Thu, Jun 21, 2018 at 4:14 PM Ian Zimmerman wrote: > On 2018-06-21 08:25, Matthew Glennon wrote: > > > Relays intending to act as Guards choose port 443 because it (and 80) are > > usually reachable in the tightest of network security situations (where > > traffic destined for most all other ports is blocked at the > > gateway/firewall.) At least that's my reasoning for it. > > I run a bridge [1] on other ports (9030 and 9001). How much would it > help to move it to port 80? I think at the time I configured it I still > had a normal http server on port 80, but this no longer applies. > > That depends on your target audience. Because you're a Bridge, you need to advertise your entry point in external ways. If the audience you're reaching can't get to you on the ports you choose then considering other ports is an option. > By the way: why can I not see the ports (under OR Addresses) or anything > under Transport protocols in the metrics listing? > > I believe this is because you're a bridge. The entire point of a Bridge is to be hidden from the censors trying to block entry to the Tor Network, so we don't want to publish that information on Metrics. > [1] > > https://metrics.torproject.org/rs.html#details/EEB31B5D6DE98CFA1C3243DA0E7CFDAA08D53593 > > -- > Please don't Cc: me privately on mailing lists and Usenet, > if you also post the followup to the list or newsgroup. > To reply privately _only_ on Usenet and on broken lists > which rewrite From, fetch the TXT record for no-use.mooo.com. > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Relay Operators Needs
Relays intending to act as Guards choose port 443 because it (and 80) are usually reachable in the tightest of network security situations (where traffic destined for most all other ports is blocked at the gateway/firewall.) At least that's my reasoning for it. On Wed, Jun 20, 2018 at 11:16 AM nusenu wrote: > >> Yes DirPort does not speak TLS, but since 443 is also best used > >> for ORPort (because it is often one of the ports that are allowed to > pass > >> through firewalls) > >> - https is not possible on the same IP (when already used by the > ORPort). > >> > > > > Well... that's kind of a hack to handle ORPort going through in various > > hosting scenarios. > > The ORPort selection is primarily important for the client -> guard > connection. > For relay <> relay connections firewalls shouldn't matter (that much) > > > > I don't know what ORPort most relays use (I guess I can get > > that from onionoo to some degree) but I do want to hope they are not all > > riding 443 (I know I don't use 443 for my ORPort on both relays). > > > Top 20 ORPorts by relay count: > > +-+--+ > | or_port | #relays | > +-+--+ > |9001 | 3289 | > | 443 | 2080 | > |9002 | 67 | > | 80 | 62 | > |8443 | 53 | > |8080 | 52 | > |9090 | 35 | > |9100 | 31 | > | 110 | 30 | > | 444 | 29 | > | 21093 | 26 | > |9000 | 22 | > | 993 | 22 | > |9003 | 21 | > | 21 | 18 | > |9010 | 15 | > | 20 | 14 | > | 22 | 14 | > | 143 | 14 | > | 19001 | 13 | > +-+--+ > > > > > -- > https://twitter.com/nusenu_ > https://mastodon.social/@nusenu > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reinstalling Relay
That is correct, at least in my experience today. On Mon, Jun 4, 2018 at 2:35 PM Nicolás Dato wrote: > >> I'm going to backup /var/lib/tor and my torrc > > I was thinking in moving the tor relay, by this e-mail I can safely > assume that backuping /var/lib/tor and torrc and moving those to the > new location is enough to keep the same fingerprint/keys, so not to > start as a new fresh relay. Am i correct? > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reinstalling Relay
That took even less time than I expected. The relay is back online and should be in the consensus after a while. On Mon, Jun 4, 2018 at 8:22 AM Matthew Glennon wrote: > When I installed my relay last year, I foolishly enabled disk encryption. > This has caused a few automatic reboots or power failures to turn into a > weekend of downtime. Today (or sometime this week) I'd like to rectify this > by reinstalling the OS. > I'm going to backup /var/lib/tor and my torrc, but I wanted to alert the > masses in case I mess up and have to start over. The relay will be down > during the process, but it shouldn't take more than an hour or so. > > > https://metrics.torproject.org/rs.html#details/924B24AFA7F075D059E8EEB284CC400B33D3D036 > -- > Matthew Glennon > matthew@glennon.online > PGP Signing Available Upon Request > https://keybase.io/crazysane > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Reinstalling Relay
When I installed my relay last year, I foolishly enabled disk encryption. This has caused a few automatic reboots or power failures to turn into a weekend of downtime. Today (or sometime this week) I'd like to rectify this by reinstalling the OS. I'm going to backup /var/lib/tor and my torrc, but I wanted to alert the masses in case I mess up and have to start over. The relay will be down during the process, but it shouldn't take more than an hour or so. https://metrics.torproject.org/rs.html#details/924B24AFA7F075D059E8EEB284CC400B33D3D036 -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Verizon AS701 blocking Tor consensus server tor26 (86.59.21.38)
Thanks! On Fri, May 25, 2018, 17:35 wrote: > >Hi tor-relays mailing list, > > > >Good news! Verizon unblocked tor26 (86.59.21.38). > > > >I posted something similar on NANOG (with modifications for network > people) here: > >https://mailman.nanog.org/pipermail/nanog/2018-May/095386.html > > > >Someone nice at Verizon must have read NANOG (VZ NOC people probably do > >read NANOG) and unblocked tor26. Here is a (successful) traceroute: > > > Thank you Neel! My relay along with all the other Verizon FiOS > relays are now visible to 'tor26'. This can be viewed by > navigating to > > https://consensus-health.torproject.org/ > > and clicking the 'detailed page' link at the bottom > (takes time to load and render). > > https://metrics.torproject.org/rs.html#search/as:701 > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Weather (was: Relay advocate introduction)
f the months time your relay was included in consensus as running (this > shows information on how many % of the months' consensuses this relay has > been included and running) > > [ ] aggregate emails for all my relays into a single digest email > > [ ] email me about new relay requirements > > [ ] email me about tor relay operator events > > > > * Write a specification describing the meaning of each checkbox > > > > **Security and Privacy Implications** > > > > The service stores email addresses of potential tor relay operators, > they should be kept private and safeguarded, but a passive observer can > collect them by watching outbound email traffic if no TLS is used. Suggest > to use a dedicated email address for this service. > > > > **Additional Ideas** > > > > * easy: integration into tor: show the URL pointing to the new Tor > Weather service like the current link to the lifecycle blogpost when tor > starts and detects to be a new relay > > * Provide an uptimerobot-style status page for relay operators using > onionoo data > > > > > > > > -- > > https://mastodon.social/@nusenu > > twitter: @nusenu_ > > > > ___ > > 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 > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay advocate introduction
I'm usually around. On Thu, May 17, 2018, 01:57 Dakota Hourie wrote: > Hi Colin! It is great to see you become more active in the project. > Looking forward to see some of these come to fruition. > > On Wed, May 16, 2018, 9:47 AM Colin Childs, wrote: > > > > Hello tor-relays! > > > > My name is Colin Childs... > > Oftc.net! Already 31 users happily idling in the channel. > > On Wed, May 16, 2018 at 12:58 PM, pikami wrote: > > Hello, > > What IRC server is this on? > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Verizon AS701 blocking Tor consensus server tor26 (86.59.21.38)
The Verizon Wireless network seems to be the same. https://imgur.com/a/fw6X9ZY On Wed, May 16, 2018 at 8:17 AM Matthew Glennon wrote: > My relay exhibits the same results on AS701, MCI Communications Services, > Inc. d/b/a Verizon Business > > https://metrics.torproject.org/rs.html#details/924B24AFA7F075D059E8EEB284CC400B33D3D036 > > matthew@freedom:~$ traceroute 86.59.21.38 > traceroute to 86.59.21.38 (86.59.21.38), 30 hops max, 60 byte packets > 1 lo0-100.RCMDVA-VFTTP-307.verizon-gni.net (96.253.78.1) 4.340 ms > 4.297 ms 4.273 ms > 2 B3307.RCMDVA-LCR-22.verizon-gni.net (130.81.24.74) 3.854 ms 4.156 > ms 8.609 ms > 3 * * * > 4 * * * > 5 * * * > 6 * * * > 7 * * * > 8 * * * > 9 * * * > 10 * * * > 11 * * * > 12 * * * > 13 * * * > 14 * * * > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > > > On Tue, May 15, 2018 at 9:18 PM Shawn Webb > wrote: > >> On Tue, May 15, 2018 at 08:12:50PM -0400, Neel Chauhan wrote: >> > Hi tor-relays mailing list, >> > >> > I have noticed that the Tor consensus server tor26 ( >> https://metrics.torproject.org/rs.html#details/847B1F850344D7876491A54892F904934E4EB85D >> ) >> > is blocked on Verizon's UUNET (AS701) backbone, and therefore, Verizon's >> > retail services like FiOS and Wireless. I can confirm this on FiOS, but >> I >> > don't use Verizon Wireless (my smartphone uses Sprint) so I can't test >> it >> > there. >> > >> > A traceroute to tor26's IP address 86.59.21.38 from a Brooklyn apartment >> > shows this is filtered on Verizon's backbone: >> > >> > neel@xb2:~ % traceroute 86.59.21.38 >> > traceroute to 86.59.21.38 (86.59.21.38), 64 hops max, 40 byte packets >> > 1 unknown (192.168.1.1) 1.128 ms 0.780 ms 0.613 ms >> > 2 lo0-100.NYCMNY-VFTTP-401.verizon-gni.net (173.68.77.1) 1.001 ms >> 3.632 >> > ms 0.900 ms >> > 3 B3401.NYCMNY-LCR-22.verizon-gni.net (100.41.137.96) 2.291 ms >> > B3401.NYCMNY-LCR-21.verizon-gni.net (100.41.137.94) 3.172 ms >> 4.046 ms >> > 4 * * * >> > 5 * * * >> > 6 * * * >> > 7 * * * >> > 8 * * * >> > 9 * * * >> > ^C >> > neel@xb2:~ % >> > >> > In a normal traceroute, you will see ALTER.NET at hop 5. Also, the >> subnet >> > 86.59.21.0/24 is not filtered on UUNET. A traceroute to 86.59.21.1 >> works: >> > >> > neel@xb2:~ % traceroute 86.59.21.1 >> > traceroute to 86.59.21.1 (86.59.21.1), 64 hops max, 40 byte packets >> > 1 unknown (192.168.1.1) 0.863 ms 0.757 ms 0.579 ms >> > 2 lo0-100.NYCMNY-VFTTP-401.verizon-gni.net (173.68.77.1) 1.010 ms >> 1.545 >> > ms 1.034 ms >> > 3 B3401.NYCMNY-LCR-22.verizon-gni.net (100.41.137.96) 3.616 ms >> > B3401.NYCMNY-LCR-21.verizon-gni.net (100.41.137.94) 5.696 ms >> 10.062 ms >> > 4 * * * >> > 5 0.et-5-1-5.BR3.NYC4.ALTER.NET (140.222.2.127) 3.492 ms 3.506 ms >> 2.996 >> > ms >> > 6 204.255.168.118 (204.255.168.118) 8.462 ms 7.479 ms 7.252 ms >> > 7 144.232.4.84 (144.232.4.84) 5.041 ms 4.688 ms >> > sl-crs3-lon-0-6-3-0.sprintlink.net (144.232.9.165) 71.865 ms >> > 8 sl-crs2-lon-0-0-3-0.sprintlink.net (213.206.128.181) 72.214 ms >> 73.579 >> > ms 72.339 ms >> > 9 213.206.129.142 (213.206.129.142) 81.390 ms >> > sl-crs4-ams-0-7-0-3.sprintlink.net (213.206.129.139) 85.854 ms >> 93.238 >> > ms >> > 10 217.149.47.46 (217.149.47.46) 79.004 ms 85.669 ms 79.392 ms >> > 11 ams5-core-1.bundle-ether1.tele2.net (130.244.82.54) 86.507 ms >> 78.374 >> > ms 77.740 ms >> > 12 ams-core-2.bundle-ether9.tele2.net (130.244.82.57) 79.642 ms >> 77.926 ms >> > 81.515 ms >> > 13 wen3-core-2.bundle-ether15.tele2.net (130.244.71.47) 105.400 ms >> > 105.089 ms 109.751 ms >> > 14 tele2at-bundle2-vie3.net.uta.at (212.152.189.65) 122.716 ms >> 110.820 ms >> > 114.354 ms >> > 15 86.59.21.1 (86.59.21.1) 106.389 ms * 105.379 ms >> > neel@xb2:~ % >> > >> > I got in contact with Peter Palfrader and he says he couldn't help, and >> also >> > with Verizon FiOS support and they said the filtering 'isn't on >> Verizon's >> > netw
Re: [tor-relays] Verizon AS701 blocking Tor consensus server tor26 (86.59.21.38)
m (154.54.2.29) 0.734 ms > > 3 be2490.ccr42.lon13.atlas.cogentco.com (154.54.42.86) 68.557 ms > > be2317.ccr41.lon13.atlas.cogentco.com (154.54.30.186) 70.829 ms > > 4 be12488.ccr42.ams03.atlas.cogentco.com (130.117.51.42) 74.570 ms > > be12194.ccr41.ams03.atlas.cogentco.com (154.54.56.94) 76.767 ms > > 5 be2434.agr21.ams03.atlas.cogentco.com (130.117.2.241) 74.515 ms > 74.612 > > ms > > 6 149.6.129.250 (149.6.129.250) 80.758 ms 74.625 ms > > 7 ams5-core-1.bundle-ether1.tele2.net (130.244.82.54) 75.421 ms > 75.425 > > ms > > 8 ams-core-2.bundle-ether9.tele2.net (130.244.82.57) 74.516 ms > 74.558 ms > > 9 wen3-core-2.bundle-ether15.tele2.net (130.244.71.47) 97.605 ms > 95.470 > > ms > > 10 tele2at-bundle2-vie3.net.uta.at (212.152.189.65) 100.314 ms > 97.947 ms > > 11 86.59.118.145 (86.59.118.145) 96.918 ms 98.620 ms > > 12 tor.noreply.org (86.59.21.38) 97.853 ms 98.110 ms > > > > (Source: http://www.cogentco.com/en/network/looking-glass) > > > > It could be possible that other Tier 1 networks formerly blocked tor26, > and > > also unblocked, but Verizon was sloppy not to do so. > > > > It's also possible that Verizon could be doing it because the FCC > repealed > > Net Neturality, and wants to discourage use of Tor to mine FiOS/VZW > > customers' browsing habits. But despite a NN repeal I can still access > Tor > > on FiOS, and also run a relay (I do both) because other consensus relays > are > > still unblocked. > > > > But if Verizon didn't unblock tor26, could it actually mean that Verizon > > wants to discourage Tor (and VPN/proxy) use to try to mine information of > > their customers (and sell ads/information) and direct users to VZ-owned > AOL > > and Yahoo? Well, I hope they were just sloppy and don't mean to wage war > on > > Tor. > > > > While I'm not saying you should avoid using anything Verizon at all > costs (I > > certainly wouldn't want to go to the local cable company), I just want to > > point out a blocked consensus server. > > I'm seeing the same thing from the greater Baltimore, MD area: > > traceroute to 86.59.21.38 (86.59.21.38), 64 hops max, 40 byte packets > 1 172.16.3.1 (172.16.3.1) 0.172 ms 0.162 ms 0.115 ms > 2 lo0-100.BLTMMD-VFTTP-323.verizon-gni.net (100.16.216.1) 23.228 ms > 7.782 ms 2.901 ms > 3 B3323.BLTMMD-LCR-22.verizon-gni.net (100.41.222.240) 2.982 ms > B3323.BLTMMD-LCR-21.verizon-gni.net (100.41.222.238) 1.702 ms > B3323.BLTMMD-LCR-22.verizon-gni.net (100.41.222.240) 7.756 ms > 4 * * * > > 100.41.222.240 is AS19262. > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal:+1 443-546-8752 <(443)%20546-8752> > Tor+XMPP+OTR:latt...@is.a.hacker.sx > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Relay Bandwidth Question
http://whatsabyte.com/P1/byteconverter.htm On Mon, May 14, 2018 at 3:37 PM Jonathan Marquardt wrote: > On Mon, May 14, 2018 at 12:26:42PM -0700, Keifer Bly wrote: > > So I have been away from the computer where my relay is running off of > for a > > few days. I have been wanting to check how much data my relay has been > > receiving during this time. I check it at > > > http://torstatus.blutmagie.de/router_detail.php?FP=db1af6477bb276b6ea5e72132684096eee779d30, > > > but that only shows how many “bytes” have been sent. I am wondering, is > > there a way to show this in megabytes / gigabytes? > > Well, if dividing is too much work for you, have a look at your relay's > logs. > You should see something like this every now and then: > > May 14 19:31:50 vmd20267 Tor[486]: Heartbeat: Tor's uptime is 5 days 11:59 > hours, with 9841 circuits open. I've sent 2466.00 GB and received 2441.27 > GB. > > This is an example from one of my relays. > > If you want to get more in depth with monitoring your relays, check out > Nyx: > http://ebxqgaz3dwywcoxl.onion/ > -- > OpenPGP Key: 47BC7DE83D462E8BED18AA861224DBD299A4F5F3 > https://www.parckwart.de/pgp_key > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guard node configuration?
Being a fast exit is more important to the network, so that'll be your probability so long as you're a good exit. Stay that way if you can. But if you want to be a guard, change your exit policy. On Sat, Apr 21, 2018, 16:51 Gabe D. wrote: > Hi guys. I've a relay running on Tor. It's an exit node now. And I noticed > it has an entry guard flag which is great. But probability of it being an > entry relay is 0%. How can I utilise this server to be an entry relay? How > does one configure this and how does it work? > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Whatever happened to those 47 PrivateInternetAccess exit relays?
I vaguely remember someone announcing them on this list? Did I imagine that? Matt On Thu, Apr 19, 2018 at 9:22 AM nusenu wrote: > > > us-drone-killing-emp...@scryptmail.com: > > Good day,They happened to pop up not so long > > ago,https://nusenu.github.io/OrNetRadar/2018/03/27/a8.htmlDid they > > abandon them? > > They lived for less than two days, so this might have just been a test. > > Someone from the torproject wrote me that they are in contact with them > (or at least were in contact by the end of last month). > > > -- > https://mastodon.social/@nusenu > twitter: @nusenu_ > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Metrics not functioning?
Are the right people aware that Metrics has been like this for most of the day? No matter what relay you look for it claims old data. https://metrics.torproject.org/rs.html#details/9695DFC35FFEB861329B9F1AB04C46397020CE31 -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Heartfelt gratitude from censored region
to get a higher penetration so that the penetration itself > becomes a barrier for the powers that be to clamp us down. > > And as we are not experts, and as we run real risks, and as we want our > family to sleep well, we have framed our "requirements" or "prerequisites" > to run Tor relays almost beyond the reasonable. You might want to call us > paranoid. If there is a way for us paranoid people to run relays and to > advocate, please help us. > > Jack > > 2. Apr 2018 07:36 by a...@mit.edu <mailto:a...@mit.edu>: > > On Mon, Apr 02, 2018 at 03:32:00AM -0400, grarpamp wrote: > > > https://www.torproject.org/docs/faq#RelayOrBridge < > https://www.torproject.org/docs/faq#RelayOrBridge> > > > > "If you have lots of bandwidth, you should definitely run a > normal relay. > > If you're willing to be an exit, you should definitely run a > normal > > relay, since we need more exits. If you can't be an exit and > only have a > > little bit of bandwidth, be a bridge. Thanks for volunteering!" > > The 'normal's above are ambiguous and conflicting. > Replace them with 'non-exit' and 'exit'. > > > Ah, actually no, replace them with "relay" and "relay". > > In that text, "normal relay" is as opposed to "bridge relay". > > The FAQ text sure needs some updating. > > --Roger > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org < > mailto:tor-relays@lists.torproject.org> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays < > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays> > > -- next part -- > An HTML attachment was scrubbed... > URL: < > http://lists.torproject.org/pipermail/tor-relays/attachments/20180403/ead69030/attachment.html > > > > -- > > Subject: Digest Footer > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > -- > > End of tor-relays Digest, Vol 87, Issue 4 > * > > > > ___ > 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 > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Previous Guard not getting Guard flag back
Sorry - that was crass. Thanks for the attempt, but I've read those documents. Specifically, I'm looking into what has changed, if anything. Is it just below the threshold of the Weighted Uptime? (e.g. we have enough Guards?) I asked because I was told that the bwauth issues were holding people back before (because everyone was unmeasured). Since that was resolved but still no guard flag, I was becoming curious. I'll just sit back and wait some more. Matt On Wed, Mar 21, 2018 at 1:23 PM Vasilis wrote: > Hi Matthew, > > Matthew Glennon: > > While I understand that my relay lost the guard flag because of a weekend > > of downtime, I would expect that it would get it back after a while of > > stable again? Anyone able to shed some light on when it will get the flag > > back? > > > https://metrics.torproject.org/rs.html#details/924B24AFA7F075D059E8EEB284CC400B33D3D036 > > "Directory authorities assign the Guard flag to relays based on three > characteristics: "bandwidth" (they need to have a large enough consensus > weight), "weighted fractional uptime" (they need to be working most of the > time), and "time known" (to make attacks more expensive, we don't want to > give > the Guard flag to relays that haven't been around a while first). This last > characteristic is most relevant here: on today's Tor network, you're first > eligible for the Guard flag on day eight." > > I will suggest you to read the lifecycle of the new relay post [1], the > Guard > FAQ [2] and the guard flag section of the directory protocol [3]. > > [1] https://blog.torproject.org/lifecycle-new-relay > [2] https://www.torproject.org/docs/faq#EntryGuards > [3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2490 > > Hope this helps. > > > Cheers, > ~Vasilis > -- > Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 > Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162 > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] arm crashes
Pick your flavor: https://nyx.torproject.org/#download On Tue, Mar 20, 2018 at 4:47 PM smichel0 wrote: > sudo apt-get install nyx > ...List of bundles... ready > ...dependecies... > ...status information... ready > --> E: bundle/packet can't be found > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > ‐‐‐ Original Message ‐‐‐ > Am 20. März 2018 7:38 PM schrieb Matthew Glennon : > > Arm just doesn't work anymore. Use nyx instead. > > On Tue, Mar 20, 2018 at 2:32 PM smichel0 wrote: > >> Hello, >> from time to time, arm looks like below: >> https://smichel.ocloud.de/index.php/s/q2knnq3AD67rPjK >> But with a simple keystroke (arrow) it runs again. After a few days it >> seems to crash completely: >> https://smichel.ocloud.de/index.php/s/GjwdCLebR4iDkuv >> I dont't know then, if the relay is still working. Last time this >> happend, I simply startet arm again and it worked. But thiis way I will >> never reach the guard-flag :) >> Yours >> SMichel >> >> >> Sent with ProtonMail <https://protonmail.com> Secure Email. >> >> ___________ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > -- > Matthew Glennon > matthew@glennon.online > PGP Signing Available Upon Request > https://keybase.io/crazysane > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] arm crashes
Arm just doesn't work anymore. Use nyx instead. On Tue, Mar 20, 2018 at 2:32 PM smichel0 wrote: > Hello, > from time to time, arm looks like below: > https://smichel.ocloud.de/index.php/s/q2knnq3AD67rPjK > But with a simple keystroke (arrow) it runs again. After a few days it > seems to crash completely: > https://smichel.ocloud.de/index.php/s/GjwdCLebR4iDkuv > I dont't know then, if the relay is still working. Last time this happend, > I simply startet arm again and it worked. But thiis way I will never reach > the guard-flag :) > Yours > SMichel > > > Sent with ProtonMail <https://protonmail.com> Secure Email. > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Previous Guard not getting Guard flag back
While I understand that my relay lost the guard flag because of a weekend of downtime, I would expect that it would get it back after a while of stable again? Anyone able to shed some light on when it will get the flag back? https://metrics.torproject.org/rs.html#details/924B24AFA7F075D059E8EEB284CC400B33D3D036 Thanks -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Unmeasured Flag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thanks. -BEGIN PGP SIGNATURE- Version: Keybase OpenPGP v2.0.76 Comment: https://keybase.io/crypto wsBcBAABCgAGBQJals2hAAoJEHIAmlM/NGGbGPkIAJVLlIaW8V9mMhQghPCHSi0o sEY84vDSYkOXKxUHaCbAXieSgq3IEJsD801DybACUhN2r0RhTpxIqzPSuL8F3VGC KdTT22zqAyB6r9WSVosaKzTts0tGIaON/TOJpm3WUoZdNJ31tBqHiP8Re09wnR5b 3V3D4D1/ZP4AhVYKFJ0+UReGuHa71ZUsUd6hhajsdccLkeRmAHhspJmn9G2DN/UA 1fvP5lu2uLXr1voHrakZMH6WvUwO2nES94SxflgEKqkq32ejLTeu6Q+fLFuv9LA1 Ju5TurdIXnDaIFs1+40sLiZUYKYpGSXimJsLe+G8tyfrKyYltPu/S3vpR/xFjI0= =Le8E -END PGP SIGNATURE- On Wed, Feb 28, 2018 at 10:21 AM Matt Traudt wrote: > On 2/28/18 10:15, Matthew Glennon wrote: > > So if I'm understanding this correctly, we're still having problems with > > a bw testing nodes and that is why my relay has the unmetered flag? > > Right. The bandwidth measuring system is still spinning back up. No one > is considered measured. > > Things will be back to normal "soon." > > Matt > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > -- Matthew Glennon matthew@glennon.online PGP Signing Available Upon Request https://keybase.io/crazysane ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Unmeasured Flag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 So if I'm understanding this correctly, we're still having problems with a bw testing nodes and that is why my relay has the unmetered flag? -BEGIN PGP SIGNATURE- Version: Keybase OpenPGP v2.0.76 Comment: https://keybase.io/crypto wsBcBAABCgAGBQJalsdlAAoJEHIAmlM/NGGbpQcH/16WQLlMAAVzx4blIRV2bIJF Hwdyj4FFQ+Ms0hHhj1DwMkB6EMa11kogLA8k+NGim8QeF2Qyobd1lARUXjZdfbV5 s/L6JYYCO+PsJxJY2+nOU41HUps1w5zLfFy+ekxkVwsX8dXq+SVy06+1HXfjY2uT HJnIpkx9/IZWMjJzRv33ylIMDq4u0MltJr+4MRrb5rSn6+9pz9m4z6CeUKJbsiLh nE0YRblkRwfrlVCP3VTaaRyQdMUwWzKwnB9S8dtKGDKb+tYz4QduFuzBf1eGGrO7 cp9GeHiittyBSGylRWveQgbkzwXRGPuUGtabXutQRqGXDvanDtEroHg+hUP0SEw= =b7/2 -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
