- tor-relays - lists.torproject.org

two questions about bridge
by jchase 02 Feb '15

02 Feb '15

Hello, I have a bridge up and running for about 6 months. I have two questions. According to arm my fingerprint is 72DB4EE86C65856E3131A32D8E30EC8A2B72A73D . But if I look up rasptorholland in globe.torproject.org I find that my fingerprint is 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . And again according to globe.torproject.org my pool assignment is blank (the empty set). Are these related to each other and is something wrong? Thanks, J Chase

2 1

Hibernating / Traffic limit and consequrnces for the network.
by Sebastian Urbach 02 Feb '15

02 Feb '15

Dear list, I would like to discuss hibernating and the consequences for the network. As someone running unmetered GBit systems i like to point out that there is a downside for the network when it comes to hibernating. Usually a few days before the end of every month my systems are getting slammed with traffic / directory requests. I thought about that and came up with the theory that a lot of systems with traffic limitations are dropping out a few days before the end of the month. This means more pressure on the remaining systems in the network. If the trend that more systems with limitations are participating increases we are going to see a serious imbalance in the network at some point. I know, poor unmetered systems ;-) I would like everybody to bear this in mind when it comes to the decision "Adjust the Rate or just open the gates and burn it as fast as possible". I'm in the fortunate position to be able to tribute a nice amount of money / traffic, but even systems with unmetered traffic can just help until the bandwidth / hardware limits are reached. It would be awesome if i could conbince some of you to take a step back and take a moment to look at the bigger picture. I would like to provide a good service for everyone, even at the end of the month. That's getting harder the more systems are not present at the end of the month. At this point i like to quote G. K. Chesterton: “We are all in the same boat in a stormy sea, and we owe each other a terrible loyalty.” Thank you for reading this and my best wishes for all of you. -- Sincerely yours / Sincères salutations / M.f.G. Sebastian Urbach ----------------------------------------- Religion is fundamentally opposed to everything I hold in veneration - courage, clear thinking, honesty, fairness, and, above all, love of the truth. ----------------------------------------- Henry Louis Mencken (1880 - 1956), American journalist, essayist, magazine editor, satirist and critic.

6 5

Information leak through WebRTC in FF/Chrome
by JusticeRage 02 Feb '15

02 Feb '15

Hi everyone, I'm not sure this is the place to share this, but I though some of you might want to know: an information leak has been discovered on Firefox / Chrome, and it can be used to reveal a user's real IP address. The article is focused on VPN, but people who connect to the Tor network through a local SOCKS proxy are also affected. Demo here . -- JusticeRage

3 2

entry guard interference?
by starlight.2015q1＠binnacle.cx 01 Feb '15

01 Feb '15

A couple of months ago I hard-configured two entry nodes that I trust for my own browsing. Both are very fast, very reliable nodes on the opposite side of the Atlantic. For about 20 minutes this evening the 'tor' daemon appears to have lost connectivity to the both nodes and I could not browse via Tor. Quite a few instances of this message were logged: Jan 30 22:59:06 Tor[]: Failed to find node for hop 0 of our path. Discarding this circuit. Neither of the configured guards were restarted during the outage, and they are located in diverse networks. The BGP looking-glass routes are different except for the first hop, which is a massive AS aggregation presumably for a trans-Atlantic cable operated by AS1299 (Telianet). I presume that this "cable" is actually a fully redundant load-balanced set of cables and any outage would be measured in milliseconds, or at most two or three seconds. Looking now, I see roughly 200 occurrences of the above message on Jan 14, 26 and 30. The reason I hard-coded the guard nodes was that, after extending the guard lifetime to 18 months, the guards were changing fairly often anyway. This bothered me. So the slightly paranoid side of my personality wonders if this is the result of a determined effort by one of the various spooky organizations out there purposefully disrupting Tor connections with the intent of forcing guard reassignment, naturally with the idea that Tor users might end up selecting guard nodes controlled by same said spooky organizations. Thoughts, comments and sharing of similar experiences are all welcome.

2 6

Re: [tor-relays] Digital Ocean: Moving to better Plan (Abhiram Chintangal)
by Spencer Rhodes 01 Feb '15

01 Feb '15

On Feb 1, 2015, at 7:00 AM, tor-relays-request(a)lists.torproject.org wrote: > > On Sat, 31 Jan 2015 13:23:39 -0800, Spencer Rhodes <spencer(a)rhodespa.com <mailto:spencer@rhodespa.com>> wrote: >> If you are on the 1TB plan at DigitalOcean, you will want to set something like the following: >> >> RelayBandwidthRate 600 KB # Throttle traffic to 600KB/s >> RelayBandwidthBurst 1.2 MB # But allow bursts up to 1.2 MB/s >> >> rather than set a daily or monthly limit. The reason being that your server will stay up all the time instead of suddenly hibernating (essentially going offline) when it hits the cap. > > I'm not sure that's the best course of action. See the Tor Manual section for AccountingMax > > https://www.torproject.org/docs/tor-manual.html.en <https://www.torproject.org/docs/tor-manual.html.en> > > If you have bandwidth cost issues, enabling hibernation is preferable to setting a low bandwidth, since it provides users with a collection of fast servers that are up some of the time, which is more useful than a set of slow servers that are always "available". Yes, I suppose that for a non-exit relay speed is more important than uninterrupted service...

1 0

Re: [tor-relays] Digital Ocean: Moving to better Plan (Abhiram Chintangal)
by Spencer Rhodes 01 Feb '15

01 Feb '15

> > > I have been running a tor middle relay[1] for the past few months. > > One thing that I noticed in the last two months is that my relay is eating > up the 1tb bandwidth in the first three weeks. So I am thinking of moving > to a better plan or tweaking the current config to serve the bandwidth so > that the relay is up for the entire month. > > I assume that you want a recommendation. A better plan probably means spending more money. Would be better for the network. If you can spare the money, go for it. > > If you dont want to spend more money than it would be a good idea to lower the Rate value until you end up within your traffic limit for the month. The benefit would be a permanent available relay. > > Hmm, I think I will try changing the rate and see what happens. Last year, I used a daily limit instead of monthly one. It drastically reduced the relays reported bandwidth ( 1Mbps to 60 kbps ). > If you are on the 1TB plan at DigitalOcean, you will want to set something like the following: RelayBandwidthRate 600 KB # Throttle traffic to 600KB/s RelayBandwidthBurst 1.2 MB # But allow bursts up to 1.2 MB/s rather than set a daily or monthly limit. The reason being that your server will stay up all the time instead of suddenly hibernating (essentially going offline) when it hits the cap.

3 2

Re: [tor-relays] moving digital ocean
by Jan Nielsen 31 Jan '15

31 Jan '15

Digital ocean does not currently charge for going over your data limit. On Jan 31, 2015 1:51 PM, <tor-relays-request(a)lists.torproject.org> wrote: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > > Today's Topics: > > 1. Re: entry guard interference? (starlight.2015q1(a)binnacle.cx) > 2. Re: entry guard interference? (starlight.2015q1(a)binnacle.cx) > 3. Re: Digital Ocean: Moving to better Plan (Abhiram Chintangal) > 4. Re: Consensus weight dropped (Bram de Boer) > 5. Re: Consensus weight dropped (starlight.2015q1(a)binnacle.cx) > 6. Re: Consensus weight dropped (starlight.2015q1(a)binnacle.cx) > 7. Re: Consensus weight dropped (Network Operations Center) > > > ---------- Forwarded message ---------- > From: starlight.2015q1(a)binnacle.cx > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 09:26:24 -0500 > Subject: Re: [tor-relays] entry guard interference? > At 06:20 1/31/2015 -0500, grarpamp wrote: > >Yet during the time of an outage, you might try > >to leave the old tor running and. . . > > I see the idea here but it's a lot > of fiddling and preparation. If it > continues to happen and I suspect > a bug, I'll upgrade the relay > version and run 'tcpdump' with > a ring-buffer capture that holds > the last two or three hours of > traffic. Then I just have to > stop the 'tcpdump' and review what > happened. Look for ICMP "not > reachable," injected RST's etc. > > If my "just because your paranoid > doesn't mean they're not out to > get you" theory is correct, it > may never happen again. Certainly > the spooks of the world all read > the Tor mailing lists. > > > > > ---------- Forwarded message ---------- > From: starlight.2015q1(a)binnacle.cx > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 10:04:14 -0500 > Subject: Re: [tor-relays] entry guard interference? > At 06:20 1/31/2015 -0500, grarpamp wrote: > >Yet during the time of an outage, you might try > >to leave the old tor running and. . . > > Also I see I should make a copy of the > cached-* files and the state file in > case some anomaly is present the Tor > routing data. > > I did look at Vidalia'a network map > at the time of the incident and the > list of relays on the left side looked > ok. On the right side something like > > <path> > <path> > etc > > appeared where client connections > normally are listed. > > > > > ---------- Forwarded message ---------- > From: Abhiram Chintangal <abhiram.chintangal(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 12:22:42 -0500 > Subject: Re: [tor-relays] Digital Ocean: Moving to better Plan > Hello Sebastian, > > Thanks for responding. > > On Fri, Jan 30, 2015 at 10:15 PM, Sebastian Urbach <sebastian(a)urbach.org> > wrote: > >> On January 31, 2015 2:09:14 AM Abhiram Chintangal < >> abhiram.chintangal(a)gmail.com> wrote: >> >> Hi Abhiram, >> >> >>> I have been running a tor middle relay[1] for the past few months. >>> >> >> Thank you very much ! >> >> >>> One thing that I noticed in the last two months is that my relay is >>> eating >>> up the 1tb bandwidth in the first three weeks. So I am thinking of moving >>> to a better plan or tweaking the current config to serve the bandwidth so >>> that the relay is up for the entire month. >>> >> >> I assume that you want a recommendation. A better plan probably means >> spending more money. Would be better for the network. If you can spare the >> money, go for it. >> >> If you dont want to spend more money than it would be a good idea to >> lower the Rate value until you end up within your traffic limit for the >> month. The benefit would be a permanent available relay. >> > > Hmm, I think I will try changing the rate and see what happens. Last > year, I used a daily limit instead of monthly one. It drastically reduced > the relays reported bandwidth ( 1Mbps to 60 kbps ). > > Thanks! > > > -- >> Sincerely yours / Sincères salutations / M.f.G. >> >> Sebastian Urbach >> >> ----------------------------------------- >> Religion is fundamentally opposed to >> everything I hold in veneration - courage, >> clear thinking, honesty, fairness, and, >> above all, love of the truth. >> ----------------------------------------- >> Henry Louis Mencken (1880 - 1956), >> American journalist, essayist, magazine >> editor, satirist and critic. >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > > -- > Abhiram Chintangal > > > > > ---------- Forwarded message ---------- > From: Bram de Boer <list-tor-relays(a)nosur.com> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 20:54:42 +0100 > Subject: Re: [tor-relays] Consensus weight dropped > All, > > Consensus weight of my relays and those of others is still near zero, and > not improving. For a network that attempts to break censorship, it is > peculiar that this is getting so little attention. > > Apparently a few malfunctioning bwauth systems is enough to censor > specific Tor relays. Endless research and development effort is put in > tweaking and optimizing the relay-to-relay communication, but having only > a few systems in the world that determine the consensus weight of the > entire network does not seem to trouble anyone. Wierd. > > I hope the bwauth operators can find a way to correct the problem. I am > feeling silly spending good money on a high-end server with unmetered > bandwidth that has now been relaying a whopping 300 Kb/s on average during > the last five weeks. > > Thanks, > Bram > > > > Thank you all for looking into this. > > > > Karsten wrote: > >> You could start a second relay on the same physical machine on a > >> different port and see whether the bandwidth scanners pick that up. > >> Give it a day or two, and see if only tor26 and moria1 measure it. > > > > In fact, both the 7C3AE76BB9E9E6E4F2AE9270FD824DF54A944127 and > > E6D740ABFFAAAD8052EDF95B2C8DC4059763F365 relays operate on the same IP > > address. Both dropped to 0.000000%. > > > > However, other nodes in the same AS16265 are doing fine (e.g. > > B144DC5C08AF1FB3ABD729AFC2CF938CF63F78AC). This seems to suggest that the > > route between the bwauths and the relay is irrelevant and connectivity is > > not an issue. > > > > I can imagine that an overloaded bwauth occasionally skips a few relays. > > But wouldn't that be corrected automatically during the measurement the > > next day? Given that the relays are missing votes consistently during > many > > consecutive days, some other mechanism must be causing this. > > > > Would a quick-fix be to randomize the order in which relays are measured? > > That way, if a bwauth has trouble processing the entire list in 24h, > every > > day other relays are given a chance? > > > > Thanks, > > Bram > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > > > ---------- Forwarded message ---------- > From: starlight.2015q1(a)binnacle.cx > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 15:23:08 -0500 > Subject: Re: [tor-relays] Consensus weight dropped > At 20:54 1/31/2015 +0100, you wrote: > >Consensus weight of my relays and those of others > >is still near zero, and not improving. . . > > I read the earlier discussion around this > issue with interest. Have no specific > ideas about resolving the problem, but > I can recommend pulling the raw text > data files for the authority votes, > grep'ping your nodes, and looking at > the specific BWauth votes over time. > > The data is found here > > https://collector.torproject.org/archive/relay-descriptors/votes/ > > and while the files are a bit huge, > are easy to whack at with *nix > command line tools such as > egrep/awk/sed/perl etc. In a > pinch one might apply Excel to the > problem, but first trim the data > set down to size with a grep or your > desktop and Excel will choke and > die. > > I did this at the point where the > bandwidth for election to guard > status was increased greatly and > my node was shipped off to middle- > relay mediocrity. Could see > clearly how it all transpired, but > of course I could do nothing about > it short of spending more $$ on > bandwidth. > > With the raw data in hand, it will > be easier to campaign the operators > of the troublesome BWauths to correct > the problem. > > > > > ---------- Forwarded message ---------- > From: starlight.2015q1(a)binnacle.cx > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 15:32:23 -0500 > Subject: Re: [tor-relays] Consensus weight dropped > also, for recent data. . . > > https://collector.torproject.org/recent/ > > > > > ---------- Forwarded message ---------- > From: Network Operations Center <noc(a)schokomil.ch> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Sat, 31 Jan 2015 21:51:12 +0100 > Subject: Re: [tor-relays] Consensus weight dropped > This has already been done. And I was under the impression that things > would be changing soon. I still find it weird that the network is ignoring > several nodes. > > On 31.01.2015 09:23 PM, starlight.2015q1(a)binnacle.cx wrote: > >> At 20:54 1/31/2015 +0100, you wrote: >> >>> Consensus weight of my relays and those of others >>> is still near zero, and not improving. . . >>> >> >> I read the earlier discussion around this >> issue with interest. Have no specific >> ideas about resolving the problem, but >> I can recommend pulling the raw text >> data files for the authority votes, >> grep'ping your nodes, and looking at >> the specific BWauth votes over time. >> >> The data is found here >> >> https://collector.torproject.org/archive/relay-descriptors/votes/ >> >> and while the files are a bit huge, >> are easy to whack at with *nix >> command line tools such as >> egrep/awk/sed/perl etc. In a >> pinch one might apply Excel to the >> problem, but first trim the data >> set down to size with a grep or your >> desktop and Excel will choke and >> die. >> >> I did this at the point where the >> bandwidth for election to guard >> status was increased greatly and >> my node was shipped off to middle- >> relay mediocrity. Could see >> clearly how it all transpired, but >> of course I could do nothing about >> it short of spending more $$ on >> bandwidth. >> >> With the raw data in hand, it will >> be easier to campaign the operators >> of the troublesome BWauths to correct >> the problem. >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

1 0

Re: [tor-relays] Consensus weight dropped
by starlight.2015q1＠binnacle.cx 31 Jan '15

31 Jan '15

At 20:54 1/31/2015 +0100, you wrote: >Consensus weight of my relays and those of others >is still near zero, and not improving. . . I read the earlier discussion around this issue with interest. Have no specific ideas about resolving the problem, but I can recommend pulling the raw text data files for the authority votes, grep'ping your nodes, and looking at the specific BWauth votes over time. The data is found here https://collector.torproject.org/archive/relay-descriptors/votes/ and while the files are a bit huge, are easy to whack at with *nix command line tools such as egrep/awk/sed/perl etc. In a pinch one might apply Excel to the problem, but first trim the data set down to size with a grep or your desktop and Excel will choke and die. I did this at the point where the bandwidth for election to guard status was increased greatly and my node was shipped off to middle- relay mediocrity. Could see clearly how it all transpired, but of course I could do nothing about it short of spending more $$ on bandwidth. With the raw data in hand, it will be easier to campaign the operators of the troublesome BWauths to correct the problem.

3 6

Re: [tor-relays] Consensus weight dropped
by starlight.2015q1＠binnacle.cx 31 Jan '15

31 Jan '15

also, for recent data. . . https://collector.torproject.org/recent/

1 0

Consensus weight dropped
by Bram de Boer 31 Jan '15

31 Jan '15

All, In December consensus weight of both my "nosurveillance" Tor exits dropped: https://atlas.torproject.org/#details/7C3AE76BB9E9E6E4F2AE9270FD824DF54A944… https://atlas.torproject.org/#details/E6D740ABFFAAAD8052EDF95B2C8DC4059763F… I assumed this to be related to the directory authorities tweaking consensus weight in response to the Lizard Squad annoyance around that time. However, traffic has not yet picked up yet. Testing download and upload speeds of my server both maxed out the 100 Mbps line. I have even done a complete reinstall from a fresh Ubuntu image a week ago (while keeping the old keys, as not to restart building reputation from scratch) but that doesn't seem to help either. I am renting this dedicated server from my own private money, in my spare time as I hate surveillance and spying by governments. But right now I starting to feel silly spending that much money for a Tor exit of which only 50kbps bandwidth is used. AFAIK nothing has changed on my server, so I am puzzled why consensus has dropped and was never restored again. Please advice, Thanks, Bram de Boer

10 29

Digital Ocean: Moving to better Plan
by Abhiram Chintangal 31 Jan '15

31 Jan '15

Hello, I have been running a tor middle relay[1] for the past few months. Apart from tweaking the configuration a few times, I didn't have to do much to get things working. One thing that I noticed in the last two months is that my relay is eating up the 1tb bandwidth in the first three weeks. So I am thinking of moving to a better plan or tweaking the current config to serve the bandwidth so that the relay is up for the entire month. Btw, here is my .torrc ORPort 443 DirPort 80 Exitpolicy reject *:* Nickname orpheus ContactInfo orpheus.tor(a)risup.net Log notice file /var/log/tor/notices.log RelayBandwidthRate 1024 KB RelayBandwidthBurst 1024 KB MaxAdvertisedBandwidth 1024 KB DisableDebuggerAttachment 0 AccountingMax 500GBytes AccountingStart month 1 0:00 Thank you! -- Abhiram Chintangal [1]: https://atlas.thecthulhu.com/#details/3045303283D4EAF74C8FA053054C691BB451A…

2 2

Re: [tor-relays] entry guard interference?
by starlight.2015q1＠binnacle.cx 31 Jan '15

31 Jan '15

At 06:20 1/31/2015 -0500, grarpamp wrote: >Yet during the time of an outage, you might try >to leave the old tor running and. . . Also I see I should make a copy of the cached-* files and the state file in case some anomaly is present the Tor routing data. I did look at Vidalia'a network map at the time of the incident and the list of relays on the left side looked ok. On the right side something like <path> <path> etc appeared where client connections normally are listed.

1 0

Re: [tor-relays] entry guard interference?
by starlight.2015q1＠binnacle.cx 31 Jan '15

31 Jan '15

At 06:20 1/31/2015 -0500, grarpamp wrote: >Yet during the time of an outage, you might try >to leave the old tor running and. . . I see the idea here but it's a lot of fiddling and preparation. If it continues to happen and I suspect a bug, I'll upgrade the relay version and run 'tcpdump' with a ring-buffer capture that holds the last two or three hours of traffic. Then I just have to stop the 'tcpdump' and review what happened. Look for ICMP "not reachable," injected RST's etc. If my "just because your paranoid doesn't mean they're not out to get you" theory is correct, it may never happen again. Certainly the spooks of the world all read the Tor mailing lists.

1 0

nearly no bandwith usage with high Consensus Weight?
by AFO-Admin 31 Jan '15

31 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi since some days my relays dropped to nearly zero bandwith but the consensus weight is still high. I never saw a behaivier like this before, maybe somebody can tell me what is going wrong here? Thanks for help https://atlas.torproject.org/#details/F5D03B59A330BE399EAA793FA35353ADD7E4A… https://atlas.torproject.org/#details/14EC9284918461506FC47D6FD9F1C71C3DA11… -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUzHNkAAoJEOExTryL2+47hKEP/Rz7HTULqcLi8ssZXqDwe0LJ GVoNVi+wOByB9BkcT6tC+imdJf6TabQY/WdfmkdNCd0rtGkDyz+kCExwU3xJNTlP 8yaPCuyr9wJMjkMR7F7P3ZA3LvzQ/PQE9z5L1PrvYZOVv7g22aR5KaebrrvhMLWJ RiBgUEGusrmQIdz3WOqTApRE4IOGr7UMg9HrLpK8KWdKT7dUvA0BauonentLxK5D njS5ZbZNIpvN+uPfVGzuJTAL3jIi4QZP8JVyz1kKdIaH2argxP7ReEYakOxNlxqy UkTVIBO1/7/VI1m8NhCSjzE07xagxtjDedGLCJW6b7VxeZ6g3fAgKWFnhc8Fej8c NJzTJXDfmiBjv20v1F9Q7lrxDjSiF8290zSfj99iLN6MsYJgfWthJfoLgwAn4sO6 4HYCyLfwqkZmtZM/UAwR3tfGp/uAi8KRpYrXUqMPjlgQgsh0/dHyIj6eewe93ED6 AThOTeTxz+azOkt0/i9efpppgAWJNd0dzeNDy2drLihDtByJ2e3Zb5MdxisXUGBg 396UOBgm67/rfJJkRqlMcjbWbX8xk3uYVmxM+JO7AHmRFRXcaBhS/EBnjdf9PUr/ K9bcBGK0CXvpwvsQceh+DyBe257tb6a8yU653LQARPfVa3uqBhjMTAP+Zda7ErZa EAUl9lT22QiAYw6QET4l =tuIU -----END PGP SIGNATURE-----

1 0

Mozilla's 'deploying tor relays' blog post
by Sebastian Urbach 28 Jan '15

28 Jan '15

Hi, The ramp up time is not 2 months. It's 3 months with the actual version. Lets see if they read the comments ;-) -- Sincerely yours / Sincères salutations / M.f.G. Sebastian Urbach ----------------------------------------- Religion is fundamentally opposed to everything I hold in veneration - courage, clear thinking, honesty, fairness, and, above all, love of the truth. ----------------------------------------- Henry Louis Mencken (1880 - 1956), American journalist, essayist, magazine editor, satirist and critic.

1 0

Mozilla's 'deploying tor relays' blog post
by Nusenu 28 Jan '15

28 Jan '15

https://blog.mozilla.org/it/2015/01/28/deploying-tor-relays/ ansible configuration https://github.com/XioNoX/moz-tor-relays/

1 0

GHOST: glibc gethostbyname buffer overflow
by goll 28 Jan '15

28 Jan '15

Hello operators, If you have not done so already, update your glibc: "as a result, most stable and long-term-support distributions were left exposed (and still are): Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example." http://www.openwall.com/lists/oss-security/2015/01/27/9 Best regards

1 0

could smoothing/smearing a consensus weights change makes sense
by Toralf Förster 24 Jan '15

24 Jan '15

I am wondering if an adversary would be able to derive useful information due to the fact that the consensus weights are changed abrupt ? (screen shot attached) -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E

2 1

Average packaged cell fullness - decreasing recently
by Kees Goossens 22 Jan '15

22 Jan '15

Dear all, According to the log file of freshhumbug, the average packaged cell fullness always decreases after restarting my relay. This seems to have initiated mid/late October 2014,:-before then the packaged cell fullness was more or less constant. Whatever the measure exactly means, this doesn’t seem right. Hibernation has no impact, i.e. the fullness decreases from before to after hibernation. Could anyone comment on whether this is true but not to worry, or true and to worry, or not true (and not worry)? Graph enclosed (start=23 July 2014, end=today, running more or less all the time, apart from a little hibernation), showing the Nth ‘Averaged packaged cell fullness’ message in the logfile on the X axis and its value on the Y axis. (i.e. X axis does not exactly represent 6 hour intervals due to occasional hibernation.) The steep increases coincide with restarting the relay. Thanks. Kees

1 1

uptime and connections for my middle node relay
by Malte Ketelsen 20 Jan '15

20 Jan '15

Hi, I am running a relay about 5-6 weeks. I have read the 'lifecycle-of-a-new-relay' and I am not over the 86 days, but I still wonder me, at most, I have only inbound connections. Sometimes outbound too, but rarely. Can someone tell me why? And I have another question: Can someone tell me how many hours a day uptime is minimum requirement for a standard middle relay? I have reed many posts, but there are not a exactly answer. Sorry for my english ... greets Malte

2 2

MiB / metrics
by Sebastian Urbach 20 Jan '15

20 Jan '15

Hi, Karsten, thank you very much for your outstanding performance. I never expected that my wish/ticket would be implemented that fast ! -- Sincerely yours / Sincères salutations / M.f.G. Sebastian Urbach ----------------------------------------- Religion is fundamentally opposed to everything I hold in veneration - courage, clear thinking, honesty, fairness, and, above all, love of the truth. ----------------------------------------- Henry Louis Mencken (1880 - 1956), American journalist, essayist, magazine editor, satirist and critic.

1 0

MiB/s / metrics
by Sebastian Urbach 20 Jan '15

20 Jan '15

Hi, I opened a ticket recently with the intention to use a more common unit than MiB/s for metrics. Karsten basically agrees but is waiting for more input. If someone is interested : https://trac.torproject.org/projects/tor/ticket/14257 -- Sincerely yours / Sincères salutations / M.f.G. Sebastian Urbach ----------------------------------------- Religion is fundamentally opposed to everything I hold in veneration - courage, clear thinking, honesty, fairness, and, above all, love of the truth. ----------------------------------------- Henry Louis Mencken (1880 - 1956), American journalist, essayist, magazine editor, satirist and critic.

4 3

Mismatched fingerprints
by Patrick Scharmer 20 Jan '15

20 Jan '15

Hi, I’ve been running a bridge for over a year and noticed recently that the fingerprint shown in ARM (and that actually works when connecting to the bridge) differs from the fingerprint displayed for my bridge on both Atlas and Globe. Any thoughts on why this would happen and how to fix it? I’m assuming the fingerprint published on Atlas & Globe is the same fingerprint that will be distributed by bridges.torproject, is that correct? Apologies if this is a common question… I’ve only recently joined the mailing list and couldn’t find a way to search the archives other than browsing. Regards, -Pat

4 4

New Arris TG1672 Cable Modem, relay not reachable...help!
by Kurt Besig 19 Jan '15

19 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been running a middle relay for nine months with great success, however yesterday my ISP, TWC, upgraded my cable modem and everything went south. Then unfortunately there was a firmware upgrade for my Asus RT-N66U router. Perfect storm, now My relay is down, DirPort[80] and ORPort[443] unreachable. The new router admin interface looks like something written in Greek to me and although I've forwarded 443 and 80 there's still no joy. After almost a year of seamless connectivity I may have forgotten some important setup fact, but other than the modem and router firmware update my setup hasn't changed same computer, same Ubuntu LTS 14.04, same Tor 0.2.5.10... Anyone familiar with this Arris TG1672 modem, Assus' latest RT-N66U firmware 3.0.0.4.376.3754, or any general help would be most appreciated.. horizons3 My old IP:76.91.226.105 New IP:108.185.28.227 dhcp -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUvDFDAAoJEJQqkaGlFNDPIroH/1iXuYVs/aktiL8OhsCoKUbd uarWayXPQSh6DXT+OMFSpy/qkE1kQVP3dNqwuaP9GVwxrJ7Qqr6Suhrmlak7Npel 6BvgQGcTwhsGGtI+KiS4IyVAjjkPcltXOyHCgOELeE8tBjyWsaYuoRJkI48CnZM9 GE+dWy2MXribEZ75IpCl3/qmE1vqdSU4LONtqfMNZ+buFkCp5BhQ5QkiRH+qpOBG tbEuV2CK+2smlWOnK84v0bqfgcj08iWGOOSMu3+Cwc+8j2XI4fi2qMfsbfrq9Qqp spwOhlTtafxJvgf57ul5gY5Vdo9HH5OtZYBwd+SjVGOE0f4qNgXjqRxostKRSmE= =XGLP -----END PGP SIGNATURE----- --- This email has been checked for viruses by Avast antivirus software. http://www.avast.com

5 5

How to get NAMED Flag
by webmaster 18 Jan '15

18 Jan '15

Hello people out there, whats the actually procedure to get a NAMED Flag? -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.17 (MingW32) mQENBFHMmT8BCAC0smvU7Bq1ABxAhvBRn7d4ekkk95aCE4TTQo4wy1z/rGLhQfdt dhiD+Vy61vGrsdK3ei5sW6rBvX2m8+YmBi+8AAgSiZmS0JM3Zz3cmTi5oh0D/yM8 4aDj7wQYfJyzSmYN8InAQ5eA77lwIdqG27kR9wga2szeJwCnWReta0R+7YFkpUW+ zUlf4SWcUx5SmBsaiELQpm+Qcn+fyopo12RX6YVmoNPBvN2nDXDnRhUCKGc+0xhD UrBpCHrApK6sTnMsD34ClCLTL2L1gckQ0AsQqY3PJlx3R8kIJxlmr6R3WnjPMIG0 lqrukB9PcOrHM1MZXK1gK6AtypHBN98lr8Z9ABEBAAG0KndlYm1hc3RlciA8d2Vi bWFzdGVyQGRlZmNvbi1jYy5keW5kbnMub3JnPokBPgQTAQIAKAUCUcyZPwIbIwUJ CWYBgAYLCQgHAwIGFQgCCQoLBBYCAwECHgECF4AACgkQcN1vxvRQl+0SEwf+KXjf YtiSUSVS11uqeQ/8g46NwmNa91P3toZvEd7vhLSbjnL9bi/vApzNnUTGT3VP4/NA dg9SbR4qKlSr8T+YikRMV3tiuiVq8m7g00qM9y8MIomwJTounz8VdO/aJXFSOxAK Bb6ElREADspCzr2qSZCnozWUzbd+b8owbGeRRq3e33Aa5Nlm/xDRxGDWANbaIA8q Gkibvy3vWEwrxiwsakvHGaEZnPEtlNm3M1xcmFAuyl73qzUMkLN0u9E/2igo4EB5 EdMb5Ab5hfWdljxBqJr0tsvMfSK4VkzMCbKYkTqHZIRPQnhiSBE6Yo1Q6RCl/Hht bkvU4RA0J+NkXMZljrkBDQRRzJk/AQgA0HojJnK0uhEkAnbmszYsf477DV+LD02s ZEAlLGhJlf9qYaDiPMPwaZ3nK8/PYKzPpBWfHgRQP97rLHPIVJYl3BHDa/nWeZ2b e/HzYhpX0djbK9qe6W/CTfGbXmC/y+4dDGB8dvtTAW3JILm7xEdwiWtywozEVy7V lnMK4JQvlfOh+3XO6qv71FXyuRkObvkYzqvxUYHewtvvObcVxXHP0C0O6LB44iAW 2boZVVuiHdudnyNAezJajPMUT8SnI0bwL6+0TgnHL4cKNUEPQljIrrvi+9nCkq7V uBtnsYtyoo2reoxmCbX/Z1zZsxdUcKpeJHlc5AypyN8DUJ+APJ9NnwARAQABiQEl BBgBAgAPBQJRzJk/AhsMBQkJZgGAAAoJEHDdb8b0UJftOY0H/1TChmQrJC/qzefW PK7EqFlBg3TIEXdu8JHjF42ZOgzQRfp7E2wWzEx0Y45lNXMs6Yg15hWCEDaUDF6F 5WZKNrP8xIldyR9Aw7fyKqjZ9UuKovqofHsCiaSO7nWzGM6GF3nBDNI9NcFve/wN wggyjAbohOJrJGal3N0HlG3cakqjEmjBe1gQEMC0ZPlWstb/cqqr49TNPrRmQc4P SyGffh8Xqhw94m1LDBXFEaYe7AxjNk1sPAVfO1rOdLF6GOun/UwgbhDQX/Rb9C3t AhjSgyFEiR/gfrUZ7R6SY51qOUf1lN5ZN85C/x27XoZWYlsNaH3Ei6nG+yeswBMk ZRMbezQ= =Med3 -----END PGP PUBLIC KEY BLOCK-----

2 1