Re: [tor-relays] More consensus weight problems
Hey Josh, (The following is the only sentence that matters in this email) I was just curious about the statement that it takes a full 2 weeks for the new-relay cap to be aged-out. (The following is only background information in case you were curious, because it's been a hell of a long standing issue.) Oh, damn near all of them. If I recall correctly, it all started in March, and just got worse and worse, and by the time May rolled around I was just wasting money. However, I let about 5 exits slide on their renewal this month as all but 2 non-exit relays lost consensus completely, perpetually locked at 20. At one point, I was merrily pumping well over 200Mbit upload and download, over 400Mbit/s total over all the relays. Then one day, literally 1 day, I was not so merrily pumping ~100k/s total over all relays. A few months have now lapsed, and I've mostly given up. I now just try things and report in the hopes that it will jog someones memory or give some insight into what's going on. Doing everything I could, limited though it may be, to keep my fastest relay running, which at one point was doing 125Mbit each way, over a period of over a month I tried resetting the keys, updating the software, resetting the keys again, then finally upgrading to the 0.2.7.x alpha, resetting the keys again, and still nothing. Consensus weight = 20 == nothing. Then I got upset and complained, and starlight said I had to wait 2 weeks for the new-relay cap to be released, which I knew to be untrue as I had never experienced that before, because I have fond memories of times long ago when my relays worked. So for fun, I re-spun one of my working relays. Fresh install, new onion keys. It gained consensus after ~48 hours, instead of the 336 hours (2wks) starlight indicated. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] More consensus weight problems
Starlight, I created this relay on Friday, shortly after you told me to be patient. https://atlas.torproject.org/#details/41C526E3C1441A3CDE9B605002643B94F3750E8C Uptime: 3 days 23 hours CW: 1100 (yesterday it was at 740) It gained consensus after 48 hours, but you said it would take 2 weeks? How is this possible? Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] More consensus weight problems
I did as s7r suggested, updated to 0.2.7.1-alpha-dev, and changed fingerprints. And we're still crippled by CW of 20. (Yes, yes, I know. The relay has gone back to stage 1/3 because the fingerprints changed.) Uptime: 48 hours Upload/download : 2.1GB, works out to a blazingly fast speed of 12.1KB/s - - I just now did a 1GB speed test while running the relay. (wget -O /dev/null http://speedtest.wdc01.softlayer.com/downloads/test1000.zip) Length: 1073741824 (1.0G) [application/zip] Saving to: `/dev/null' 100%[] 1,073,741,824 14.1M/s in 86s 2015-07-02 09:23:31 (11.9 MB/s) - `/dev/null' saved [1073741824/1073741824] - - Don't forget to smile! Matt Speak Freely 0x4D9A54A3.asc Description: application/pgp-keys ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] More consensus weight problems
Rah rah rah... Emailed Aaron directly by accident. Here's the email: Hello, First of all, I love Tor. I love Tor Browser, and I love running relays. When the problems are solved, I will most likely spin up more relays. I'm leaving my fastest relay running, as a method of checking the status for myself. The rest have already started to expire, and within the next week or so most of the other ones will have expired as well. I'm going to try tor-dev-alpha 2.7.1 and change fingerprints, as per a suggestion from s7r, seeing as how I have nothing to lose. I just wish the bwauths could scan relays based off previous relative consensus weights... If this particular relay was at 27000, it should be higher on the list to check compared to another one I have that is at 487. My one relay was blazing fast with thousands of connections, my other is painfully useless with dozens, but my fastest one lost its consensus while the slowest one kept it's consensus. It just seems silly. That being said, I don't know how/if the bwauths scan in any order or just willy-nilly, (that's not entirely true, I know it's segmented to some degree as I recall reading a blog post about how it's chopped up) but... I'd be much less upset if my best relays worked and my worst relays didn't. More complaining... bleh. One thing I would like to point out though... it appears... These problems have at least a casual relationship with MyFamily. One group of MyFamily is completely done - all of them stuck at 20. Another group of MyFamily is working happily. I've been doing some tests over the past few months trying to understand why I keep having problems, and one thing has consistently popped up... MyFamily. As one of MyFamily lost consensus, another family gained consensus back on or around the same time. Yes, especially nusenu, I know I'm supposed to have it all configured to be under 1 MyFamily... But in a way I'm glad I didn't, as the casual relationship I see really could only be seen having done what I did. I say casual because I have no proof of causation. But... it is interesting. If no one else has experienced similar problems, then I'd chock it up to a completely unexpected unrelated set of mysterious circumstances that should not have happened for which there is no explanation. Aaron, if there is anything I can do to help you please let me know. So in conclusion, I'm not done, I'm just not happy. This was supposed to be a short email, oops. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] More consensus weight problems
Yeah, I've given up. I won't be renewing most of my relays this month. :( Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] More consensus weight problems
Zero progress on this, so I thought I'd pop it up again. I'm only pointing this out because it's interesting, not because I think anyone will do anything about it. It may be interesting to someone looking into the diversity of consensus weights given a small subset from two providers, that is all. Neither of the two problem relays have gotten rid of their consensus weight of 20. One of my other relays has lost significant consensus, from 11170 to 1720, its now pushing peanuts, or about 1/10 of what it used to. My oldest relay pushed(in/out) ~10TB last month before losing it's consensus weight. My other relay, brand new, has been up for about a week and still stuck at 20. All 5 relays come from 2 providers in the euro-region, my other relays are not important so are not displayed. About ~4 hours ago I restarted the 5 relays to see the fun. Since that time, here is that status of each: 1) Measured speed 165.6Kb/s (arm) Downloaded 50.0GB Uploaded 51.0GB Avg Rate: 66.8Mbit/s (vnstat) Consensus 21200 Provider #1 2) Measured speed 105.4Kb/s (arm) Downloaded 28.7GB Uploaded 29.4GB Consensus 13500 Avg Rate 38.13Mbit/s (vnstat) Provider #2 3) Measured speed 13.4Kb/s (arm) Downloaded 4.1GB Uploaded 4.3GB Consensus 1720 Avg Rate 5.4Mbit/s (vnstat) Provider #2 4) Measured speed 160b/s (arm) Downloaded 3.1GB Uploaded 3.2GB Consensus 20 Avg Rate 3.82Mbit/s (vnstat) Provider #2 **Oldest relay in list 5) Measured speed 160b/s (arm) Downloaded 217MB Uploaded 216MB Consensus 20 Avg Rate 204kbit/s (vnstat) Provider #1 **Newest relay in list Relay #5 should be acting more like relay #1. Keep in mind though relay #1 was rate limited last week by half because my provider asked me to - it was for a period of time happily doing 75-90Mb/s each way. Relays #2-4 should all be similar, but they're everywhere. Enjoy. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Cheap exit-friedly VPS provider
I've got a few relays with PulseServers as well. I really like them. I've spoken to the owner Kyle quite a few times. I accepted that he is a reseller of OVH, reluctantly, because their abuse department are fuc... Nevermind. You could try opticservers.com, based in the UK. I have a few relays with them. The owner Joe is also very nice. From what I understand, it is all his own equipment, so no OVH. 100mbit/s unmetered at ~$7USD (it's in British currency, so whatever the conversion rate is for £4). I wouldn't suggest the 256MB ram, go for 512/1024. If you must go with OVH, then I'd suggest buying a $3 vps as well, and don't run a relay on it (keep at least 1 vps clean). I lost 11 annual-subscription relays because all of the relays were blacklisted, and that was enough for them to claim the following verbatim: Your account was suspended because 100% of your IPs are blacklisted on multiples lists for Spam and other malicious activities. This case is closed and this decision is final. I checked all of the relays. DanTor reported Tor relays, CBL aggregates from DanTor, SpamHaus Zen aggregates from CBL, and those were the only blacklists any of my relays were on. Of course, I repeatedly contacted them prior to spending all of my money on annual subscriptions to make sure it was okay, and I have the emails telling me they support it, and they even commented on how important these types of projects are. But they still shut down all of my relays and kept all of my money. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] More consensus weight problems
Actually I remembered a third relay having problems. On Friday last week my provider asked me to rate limit one of my relays because it was pumping a lot of data. (Unmetered does have its limits, and I fully appreciate how my provider handled it) I changed the RelayBandwidth from 100Mbit to 50Mbit, and it almost immediately went from averaging 75Mbit/each way to about 7 each way. It's consensus weight dropped like a rock. It's slowly sort of mostly kind of caught up, now in the 25-35/each way range. (I can sort of understand why it happened - the network was adjusting things to deal with the decreased capacity. But it should not have been such a dramatic drop, then the slow rise. I feel this is little more than nit-picking on my part, though.) This sort of seems to be in line with the thread: [tor-relays] BWAUTH weightings too volatile. . .twitchy https://atlas.torproject.org/#details/656E73D7D153DE93D5EEAF837D675F8F129A5006 When the consensus weight is retarded, so is my relay. Just thought I'd add that to the list. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor network loses ~50 relays/day due to bw auth problem
GIGGITY GIGGITY GOO!!! It appears as of this morning, 3 of my relays are now reporting something better than 20, in the upper hundreds. My other one that started working the week before is now chomping along it's merry way. So I will turn the 3 back on to exit-relays. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Please enable IPv6 on your relay!
Hello everyone, I know that most of you know to do this already, but remember to update your IPv6 firewall! :) Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Auto-detect and enable IPv6 // Re: Please enable IPv6 on your relay!
Roman, First, I would like to apologize for the language below. It's not the nicest way for me to communicate, but I wrote it all down and don't want to have to re-write it to soften the content. An apologetic disclaimer is what you get instead. :) I'm sorry for the vulgarity. -- Uhh, I would like to point out that it would be exceptionally stupid to have Tor autoconfigure IP addresses, regardless of whether it's IPv4 or IPv6. Unless of course you have some automagical way of Tor determining which IP address you want to use. I'm sure fairy dust can be used to determine which IP address you want to use, but I can't think of a single method for any application to correctly guess which IP address you want to use that doesn't include Tinker Bell and her tiny friends. The examples you provided are for servers with 1 single IP address, a relatively trivial system. In that case, it's easy to guess which IP to use. So yes, Tor can *guess* which IPv4 to use, but it's a fecking guess! STUPID! What if I want to run a webserver on one IP address, and Tor on another? What if I decide to also run a mail server on a third IP address? What if I want to run an Onion Service? What if I have a beefy system with quad 100mbit connections and want to run 4 Tor relays on the same system? What about a complicated network setup that uses VMs and requires punching through NAT and port forwarding through two firewalls to the outside world? Does Apache correctly guess which IP you want to use, when there are multiple choices? Does your favourite mail server *know* which IP address to use? NO! So why should Tor be made of fairy dust? A certain lack of understanding of best practices seems to be your problem, not Tor's. This is a security *FEATURE*. The consequences of magic can be catastrophic, and you should be able to understand the very real and serious implications. We're all running relays for what is arguably the very best anonymity software available, not minecraft servers. You need to take security seriously. Write a script if it's such a problem! Learn to love sed. This is a non-problem. This is trivial. You're running 15 relays - which is awesome, so you're not retarded - you can do this. But seriously, you need to think about what you just said, and why it's such a terrible idea. Accusing the developers of a lack of understanding is wholly unwarranted. You should apologize. Regards, Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor network loses ~50 relays/day due to bw auth problem
I thank you, Tom. I lack all of the cited qualifications - now I know. :) Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] amount of unmeasured relays continuously rising since 2 weeks
Hey NOC, Nah I had the same experience with *1* relay. Following the same pattern, none of the other relays have left 20. I'm now at 16200 and averaging ~30mb/s. 4 still in limbo. What's also interesting is I setup a non-exit and it also will not get past 20. What does arm say your measured speed is? Mine was 45Kb/s for the longest time, but very recently went to 126.5Kb/s, but that's silly. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Leaseweb exit relay notice
The problem is compounded by the fact each BL company is racing it's way to the bottom, adding each others finds to their own lists. SpamHaus has OVER 1 *BILLION* addresses listed. I lost several relays (11) from OVH because DanTor recorded my relays, then CBL recorded DanTor, then SpamHaus Zen recorded CBL, which allowed OVH to claim 100% of your IPs are blacklisted on multiple lists when in reality it was from a guy in the UK who publishes all Tor relays - guard, middle, exit - that caused this whole problem for me. Not one single complaint from anyone against any of my relays. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor network loses ~50 relays/day due to bw auth problem
To be a bwauth you have to be a dirauth, if the bwauth draft spec I read was correct. But how do you become a dirauth? The addresses are hardcoded into Tor, so it's not like I could just spin up a dirauth in an evening and let the network do the rest. There's got to be more to it. I was interested in hearing the response as well, so... Bump. Jannis Wiese: What does it take to run a bwauth and/or dir auth? I would be happy to help, if I can. Jannis Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Consensus Weight Stuck at 20 (Even on Relay with Stable Flag)
Another update. Nothing to report. None of the exits I changed to guard changed their consensus weight. I spun up a brand new guard relay last week, and it also is stuck at 20. So, my one relay that was an exit but then put to guard which was then reverted back to exit is - dun dun dun - a complete one off. Curse words and middle fingers. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Consensus Weight Stuck at 20 (Even on Relay with Stable Flag)
Further update: I changed two other affected relays to guard last night. The consensus weight didn't budge at all and bandwidth usage was negligible, so I've deleted all my onion keys for those two relays. So these relays are starting fresh. We'll see how it goes. I'm going to wait until I get some flags and see a measured speed of anything above 160b/s, as I'll assume this means regardless of actual accuracy, the bwauths have been able to determine *something* about me, then I'll switch the flip back to exit. This should take a while, as they have to go through the different stages again. My first relay's consensus weight hasn't budged yet, but it was in the thousands before I changed from guard to exit, so I'm not concerned - it hasn't dropped is the point I'm trying to make. The first relay is now finally being used appropriately, at 13Mb/s in and out each. Since last evening I've done over 250GB in/out. Arm is still reporting the measured speed as 45Kb/s. Relay that is now working https://atlas.torproject.org/#details/D60B02A13F5D9CAFD6EC27A5332C5FEF5B769105 You can see from March to near the end of April, as an exit relay, damn near nothing was going on. Around April 20th I changed it to guard, and activity finally started happening. Yesterday I switch back to exit, and you can clearly see the exit probability jump. :) For comparison: https://atlas.torproject.org/#details/034A61A65419B5A115A7B6B253CAC4C9D5731E02 Like the other relay, it's consensus never went above 20. However, when I switched the flip to guard, the middle and guard probability increase was technically present, but negligible. 0.0002% and 0.0001%, respectively. Because the first relay's consensus weight responded almost immediately to the change, I arbitrarily decided the problem for the other two relays was not fixed. So I deleted the keys and am starting over to see if that helps any. And here we are. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Consensus Weight Stuck at 20 (Even on Relay with Stable Flag)
From my experience, this happens only with exit relays. Changing from an exit relay to a guard fixes the problem immediately. I've seen past threads that mentioned deleting your id key would fix the problem, but that never fixed it for me. But that is also counter-intuitive given that going from exit to guard while keeping the same id fixes the problem. If I recall correctly, going back to exit causes the problem to re-appear - I will see if I can confirm that again with one of my guards-that-was-exit. The common theme I keep seeing is that the bwauths need to fix their systems, but beyond that, or which part of their system, I don't know. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Consensus Weight Stuck at 20 (Even on Relay with Stable Flag)
A quick update regarding my guard-that-was-exit. This relay, when it was an exit relay, never got past consensus weight of 20. When I changed it to guard, the consensus weight immediately jumped, and bandwidth was finally starting to be used. As usual, it took a few days for full usage, but it did come. Instead of measured bandwidth at 20b/s, it now read 45kb/s. Though arm indicated the average speed was 7-11Mb/s. A few hours ago I switched that relay back to exit, and so far everything looks goodish. The measured bandwidth still says 45Kb/s. I'm now averaging 10.6Mb/s, and have downloaded 16GB and uploaded 17GB since my last email. In arm, I lost my HSDir flag, but I have received Exit flag, and have just over 500 exit connections and 1700 in/out connections. The consensus weight, or anything for that matter, hasn't changed in Atlas yet, but that's not terribly surprising. There were recent changes in how/when Atlas report things now, right? So... perhaps I just found a fix? Err... Workaround. This isn't a fix. I'll take a look at doing this to the other relays to see if this fixes the problem for them as well. Maybe some other people can do the same thing to confirm? 1) Comment out your ExitPolicy accept rules 2) service tor restart 2) Run the relay as a middle/guard until you see in Atlas your consensus weight rises - it should rise within a few hours, but seeing as how your relay isn't working anyway - you can try to wait a day to make sure all those bwauths pick you up. 3) Uncomment your ExitPolicy accept rules 4) service tor restart 5) Report your status back. How exciting! Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Consensus Weight Stuck at 20 (Even on Relay with Stable Flag)
I'll be shutting down 5 of my unmetered 100mbit relays until they are fixed. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] T-shirts and Confirming Relay Control
Matthew Finkel, It's kind of disingenuous to suggest If you want to work on something, then please come work on it, we really are overloaded. You have to let us work on it, for us to work on it. Do you understand the problem? To The Inner Circle (The Tor Project People), I am at the very least the third person to mention in this thread that we have offered to help. No one responded to my offers. I'm pretty sure at least some of their offers were ignored as well, though I can't be bothered to double check. I get that you're busy. However, Matthew's attitude to Seth is, in my most humble of opinions, unwarranted. You've got several people who out of their own free will, decided to offer our additional help, above and beyond what we already do. I wonder, how would you feel, if after offering free assistance to a community that then goes completely, totally, and utterly UNANSWERED, only to have those very people that we offered to assist, bitch that they are busy and want our help. How would you feel? Angry? A little schadenfreude? Or numb? I'm a husband, a father, and a business owner. I'm a busy guy, yet I still offered to help. I can't express how pissed off I am about this, without going into a obscenity-laced tirade about how your house isn't in order. When I offer assistance to someone, or in Tor's case several people, I damn well expect a response. Yes or no, thanks or fuck off, please or tomorrow, join us! or maybe next time. Deafening silence is in no way a mechanism that encourages support from the broader community, but from my perspective that's all you've given. Here's a suggestion to The Inner Circle - Have a volunteer coordinator that actually responds to people. This way, when the next person offers to help, they might actually get a good g*d d@mn f@cking response! Seeing as how I'm a nobody and my offers aren't worth acknowledging, please continue to do whatever you'd like, with *all* the success it brings. Don't forget to smile. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Relays Network Survey
Boo to Javascript. Please don't take this the wrong way, but you should consider having someone proof-read your survey before you publish it. I found it exceptionally difficult to read, as many words were missing, or the wrong tense was used. Granted, I am a grammar nazi, but this was an eye sore. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Consensus Weight
Mine is now at 457, so I suspect it will continue to climb as the network learns more. I wonder... if the bwauths use a different mechanism to test exit nodes than middle nodes... Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Consensus Weight
Hi NOC, I just set one of the relays to be a non-exit, to see if that helps. I guess the next step will be to completely start new with a fresh VPS install... But I doubt that will work as the second VPS I got from the same provider *never* left a consensus of 20. I just did some more speed tests 100M file @ 10.3M/s for 10 seconds for VPS #1 100M file @ 10.7M/s for 10 seconds for VPS #2 1000M file @ 10.4M/s for 99 seconds for VPS #1 1000M file @ 10.5M/s for 98 seconds for VPS #2 These are both on unmetered accounts, so to say it's a piss off that this isn't working well might be a bit of an understatement. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Consensus Weight
Alright, I'm about to lose my mind. My consensus weight on atlas already jumped from 20 to 207 on the relay I changed from an exit to middle. So... Super-duper. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Consensus Weight
Most dearest Network Operations Center, As the problem has yet to go away, I decided to bring back from the dead this thread. The problem still persists, my consensus weight never leaves 20. - I have deleted the ID - I have changed the IP address - I had the relay offline for... 2 weeks? My consistent average speed is ~100-200kb/s, though the server is quite capable of handling 2-4MB/s. Doing speed tests I can sustain 6-8MB/s. So, I decided to get another VPS account and setup a new relay. Exact same issue is present. Affected VPS #1 https://atlas.thecthulhu.com/#details/28683E52268BDCF8B292DD9037131C315DB44A77 Affected VPS #2 https://atlas.thecthulhu.com/#details/D60B02A13F5D9CAFD6EC27A5332C5FEF5B769105 Atlas has always looked drunk while displaying stats for VPS #2, as the pretty graphs never seem to display anything for the 3 days, or 1 week IO graph. My two non-exit relays work great. My two exit relays suck the big one. I'd appreciate some more advice. And no, I haven't set the MyFamily parameters for various reasons. If and when this issue gets fixed, I'll add them. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Subpoena received
All I can say is reach out to EFF and Moritz. I am surprised and saddened to hear this. Have you told your ISP about Tor? Did you tell them in advance of setting up the relay what it is, and what it is not? Kind regards, Matt Speak Freely Tyler Durden: Now Alistaro (our ISP) wants the IPs as well or they will probably shut down the server tomorrow. Well that escalated quickly. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Subpoena received
Thanks Moritz. This is good information. I do see both sides of the coin, as American courts often do seem to be attempting to override international law. But, when someone spits in your face, it's rarely a good idea to spit back. If we all took the position of 'Teacher' when these things happen, eventually the courts will learn the technology and know not to ask. Also of critical importance, depending on your country of origin, it may actually be illegal for you to provide third parties, for example a court of law, any log information that you do have - because as relay Operators, it's not our data that's traveling through the network. Good luck! Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Subpoena received
A foreign sovereign can command anything to anyone... without a reasonable expectation that anyone will follow it. Even in Canada, I am not obliged to respond to American subpoenas unless and until my government commands me to. Only your sovereign can command you to do anything. A foreign sovereign has zero right to anything outside of it's own purview. Here is an excellent quote From the OFFICES OF THE UNITED STATES ATTORNEYS http://www.justice.gov/usam/usam-3-19000-witnesses#3-19.320 Since foreign nationals residing in the foreign countries are not subject to the subpoena power of United States Courts, their attendance can be obtained only on a voluntary basis. Obtaining testimony from foreign nationals is often a delicate matter, and care must be taken to avoid offending the sovereignty of the foreign country involved. Keep us up to date!!! Matt Speak Freely Moritz Bartl: Hi Tyler, Thanks for sharing. I've been reluctant to publish ours, because with the wrong interpretation -- without relating it to the sheer amount of data we push -- it may paint a negative picture on Tor. Also, funny how they simply assume how you (in Luxembourg) and the hoster (in Romania) can be commanded via a US subpoena. I agree that it's best to give them a straightforward answer, but you are not required to do so. On 04/20/2015 04:32 PM, Tyler Durden wrote: Hi I just wanted to let you know that Washington sent us a subpoena regarding one of our exit nodes in Romania. They want to know the real IP behind the Tor Network. I mailed them what Tor is and why I can't help them in identifying this person. Nevertheless I will give you the link to the full subpoena. Maybe you guys find it interesting. I will forward the subpoena to our lawyer as well. https://mega.co.nz/#!ilIjlZSb!-deirKharWaDtp_UMxhev58E14zeouyoWUbzxeWPvEQ Greetings ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Subpoena received
Dave, I missed a required comment on my post, so thanks! I am not a lawyer, and my comments should not be taken as legal advice. The Law of Nations is more or less black and white, but the politicians and lawyers have mucked the lines very well. Thomas, I like your style. They are well aware of their need to send Letters of Rogatory for the foreign sovereign they wish to deal with. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Keep smiling only - i dont expect any answer
This is a financial institution that manages inter-bank payment systems in South Korea. I think when they said *trial* they meant *attempt*, which means the attack did not succeed. But a trial could also be a successful attack that was meant to test whether they could get in before the real fun starts. So I'm not sure if the attack was successful or not, but assuming it was a successful attack... Tell them to report it. Tell them it would be a gross violation of their due diligence, and most likely legal responsibility to not report it. Tell them not to rely on other people to ensure their network is protected from all of the widely and freely available attack vectors. Tell them you run a Tor relay, and as such you have no control over who does what, and provide relevant links. Point them to your Tor Exit Notice that is easily and readily available for anyone to see. Now, if the attack wasn't successful, tell the Network Security Manager that as an inter-banking payment system provider they should expect attacks of varying degrees, but that you still have no way of controlling who does what on the Tor network. Either way, tell them FCKeditor_Vul is easy to fix, but is entirely their responsibility. Their WYSIWYG editor has a vulnerability - how is that your fault? Regards, Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] MY IP adress on blacklist and then in exit relay policy
Hopefully I won't be adding too much confusion into the conversation... When you see reject 37.157.192.208:*, it means not to accept anything sourced from your IP. For example, if you were to run a Tor client on your server that's running the relay, you would not be able to exit the Tor network from your server... But why would you, right? This appears to be standard, as all of my relays did the same thing automagically. Nothing to worry about. (I could be wrong.) Oh, and if you're running 3 relays, use MyFamily field! :) Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Undiagnosable Crashes in Relays
Vincent Yu is Tor 0.2.6.5-rc on Linux skyhighartist is Tor 0.2.4.24 on Linux my affected relay Tor 0.2.5.11 on Linux Cool. Matt Speak Freely Nick Mathewson: What version of Tor did these relays run? Is it possible that one of the crash bugs fixed in 0.2.5.11 is to blame? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Undiagnosable Crashes in Relays
One of my relays went down a few weeks ago, and I didn't notice until a few days ago. https://atlas.torproject.org/#details/4CA46581FB3C82102565B02C1ECB6DD38EF6654A I did find what caused it, but thus far I cannot remember what it was. If I remember, I'll post again. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Undiagnosable Crashes in Relays
My apologies for my lack of memory... It's still fuzzy, but Roger helped jog the the gerbil into action. There was a line regarding assert failure in my logs. I could not get Tor to start again until I followed these instructions: https://trac.torproject.org/projects/tor/ticket/13111 My secret onion keys had 0 values, so I removed them and restarted Tor and it went on it's merry way. It's quite possible the cause of my crash was completely different than Vincent and skyhighatrist, as neither of them indicated they had to do that to get them back up and running. Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Consensus Weight
Poke. Bump. :) Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Consensus Weight
Hello Network Operations Center, Darn. Done. Yet another fingerprint bites the dust... Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 7 relays gone because of spammers
Hi ZEROF, I had fail2ban, harden (which includes tiger, tripwire, logcheck, plus MANY others), all the fancy log checkers, rkhunter and clamav, unattended-upgrades, and had all logs emailed to me on a daily basis. It was tedious to go through, but I was trying to do my due diligence. I disabled root login, changed ssh port (security through obscurity - damn right, but I kept it in the privileged range.) --- Each password was a minimum of 32 characters, alphanumeric plus symbols. No two passwords were alike, or remotely similar. (No, I didn't use keys :@) I checked how secure is my password, and this is the result: It would take a desktop PC about 21 quattuordecillion years to crack your password I had to look quattuordecillion up, as my spell checker doesn't know what it means. In the US, it means 1, followed up 45 zeros. (In the UK it is 10^84, but I believe the website is American so I'm sticking with ^45) --- I disabled as many services as I could reasonably tolerate. I removed world rights to as much as I could think. I did everything I could think of to make each VPS effectively useless except for running a Tor relay. My firewall matched my Reduced Exit Policy, plus my secret ssh port. I never thought about the honey-pot... That's a good one. Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 7 relays gone because of spammers
After much research, I've found some interesting tidbits. Out of the 88 blacklists mxtoolbox reports against, 6/7 relays reported 3 problems - 1) Efnet blocks Tor exits and reported. No exceptions. - 2) CBL detected a single trojan/malware/spam, etc, and reported - 3) Spamhaus ZEN detected CBL's detection, and reported 1 of the 7 relays also had two hits from Mailspike - 1) Mailspike Z found a distributed spam wave, and reported - 2) Mailspike BL aggregates other Mailspike lists, and reported Essentially, all 7 of my relays were taken down because of trivial issues, all but 1 being single instances of reported problems from a single source. Both CBL and Mailspike offer de-listing services that are easy to use, and straight forward. I spoke with MasterCard yesterday, and they've mailed off the paperwork I need to fill out to do the charge-back. I won't get into the specifics, but they were encouraging. I will also be moving my unrelated business dealings away from OVH as soon as possible. Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 7 relays gone because of spammers
, but that made me smile. :) Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor weather not sending emails?
Just another update about this. It took about a day for Tor Weather to report that a different server went down... It took about 3 days for it to notice the first server went down. So, it's slower than molasses, but it will report system failures eventually. -- Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Very Safe Exit Policy
Hey Stephen, I'm a relatively new operator, and I run over a half dozen Reduced Exit relays and a few middle relays. Abuse complaints shouldn't be common coming from IRC - the main culprits for complaints are DMCA and related for alleged IP (Intellectual Property) theft. That would be your torrents and other downloading services. The Reduced Exit Policy disables the ports traditionally used by those services. (But its rude to download off Tor anyway...) But remember, a Very Safe exit policy is also a very restrictive policy. You may unintentionally inhibit legal activities/dissent/communication/free flow of knowledge. Also, regarding whether it's a reduced exit, or full blown wide open: It is most definitely strongly encouraged, and sensible to put up a tor exit notice. IMHO get this setup before you open your ports. Define the intention before you implement the decision. There are template notices available that only need minor modifications. As well, it's always good to contact your provider and let them know that you're running a Tor relay. I contacted mine, let them know what I was intending to do, how many I was planning on setting up, and I specifically asked for them to contact me immediately over any concern. They were more than kind, and understanding. This sets up a positive environment for when they may in the future get some complaints - they will already know it's not YOU per se, and that no malice was intended. Even if your provider says they permit it, let them know anyway. The whole matter of whether or not the companies that file the complaints have a legal leg to stand on, depending on country, is well beyond the scope of this email. But it is VERY important to understand your rights and responsibilities regarding retransmission of data, as well as that of your provider. In many cases, country dependant, your provider cannot be held liable for retransmission, nor can you. I would STRONGLY encourage you to read as much as possible about this as possible before running an exit relay of any type. Again, I'm relatively new so others could slam my comments as ignorant or whatever... There is a ton of information available to you. If you're concerned about running an exit relay, I would suggest getting confident (and damn proud) of running a middle relay first, then when comfortable move toward a Reduced Exit policy. Kind regards, Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor weather not sending emails?
It took 3 days for Tor Weather to tell me one of my relays went down. I had similar settings, I believe 0 bandwidth for an hour. So, it's sorta kinda working? :) Kind regards, Matt Speak Freely ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
