- tor-relays - lists.torproject.org

Re: [tor-relays] bad validity timestamps on authority certificates
by Scott Bennett 05 Nov '11

05 Nov '11

On Sat, 5 Nov 2011 02:14:43 -0400 Roger Dingledine <arma(a)mit.edu> wrote: >On Fri, Nov 04, 2011 at 06:06:41PM -0500, Scott Bennett wrote: >> Nov 04 15:51:00.273 [warn] Certificate not yet valid: is your system clock set incorrectly? >> Nov 04 15:51:00.274 [warn] (certificate lifetime runs from Nov 5 04:26:47 2011 GMT through Nov 4 04:26:47 2012 GMT. Your time is Nov 04 20:51:00 2011 GMT.) >[snip] >> My system's clock gets adjusted to the network timeservers' values once per >> hour. I've checked the logs and found that the each adjustment has been less >> than 71 ms during this time. >> So the question is why are the authorities putting out new certificates >> with valid time periods beginning six or more hours in the future? Also, when >> will the authorities be corrected? > >These aren't directory authorities. These are just random relays that >you're connecting to who have clocks more than an hour off, and an >over-active log message. Oh, okay. I had thought that only the authorities passed out "certificates", which then got stored into cached-certs. I didn't know that just any old relay could do so, too. > >See >https://trac.torproject.org/projects/tor/ticket/4370 >https://trac.torproject.org/projects/tor/ticket/4371 Thanks for the explanation, Roger. BTW, those messages seem to have stopped a few hours ago. > >This is the alpha Tor, with a shiny new (and still somewhat >sharp-around-the-edges) v3 link handshake. I'm glad this one doesn't >crash, like the last one did. :) > Yup. After seeing the notes about that bug, I just waited an extra day or two to upgrade, skipping 0.2.3.6-alpha and going straight to 0.2.3.7-alpha when it became available. :-) Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0

bad validity timestamps on authority certificates
by Scott Bennett 05 Nov '11

05 Nov '11

For the last day or so, my relay has been logging messages like these: Nov 04 15:51:00.273 [warn] Certificate not yet valid: is your system clock set incorrectly? Nov 04 15:51:00.274 [warn] (certificate lifetime runs from Nov 5 04:26:47 2011 GMT through Nov 4 04:26:47 2012 GMT. Your time is Nov 04 20:51:00 2011 GMT.) Nov 04 17:28:37.359 [warn] Certificate not yet valid: is your system clock set incorrectly? Nov 04 17:28:37.361 [warn] (certificate lifetime runs from Nov 5 06:26:47 2011 GMT through Nov 4 06:26:47 2012 GMT. Your time is Nov 04 22:28:37 2011 GMT.) Nov 04 17:56:47.782 [warn] Certificate not yet valid: is your system clock set incorrectly? Nov 04 17:56:47.782 [warn] (certificate lifetime runs from Nov 5 06:26:47 2011 GMT through Nov 4 06:26:47 2012 GMT. Your time is Nov 04 22:56:47 2011 GMT.) My system's clock gets adjusted to the network timeservers' values once per hour. I've checked the logs and found that the each adjustment has been less than 71 ms during this time. So the question is why are the authorities putting out new certificates with valid time periods beginning six or more hours in the future? Also, when will the authorities be corrected? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 1

TOR notice.log is spammed with "Certificate not yet valid" warnings
by Klaus Layer 03 Nov '11

03 Nov '11

Hi, since 0.2.3.6-alpha the logs of my instances are full of these messages: 14:56:23 [WARN] (certificate lifetime runs from Nov 3 16:15:34 2011 GMT through Nov 2 16:15:34 2012 GMT. Your time is Nov 03 13:56:23 2011 GMT.) 14:56:23 [WARN] Certificate not yet valid: is your system clock set incorrectly? Any idea how I can get rid off these warnings? Best regards, Klaus

3 3

ARM: Client locales on connections page
by Klaus Layer 23 Oct '11

23 Oct '11

Hi, I recently found the "Client locales" function on the connection page of ARM. What exactly is the number behind the country code: ir 223334 (%13) us 188412 (%11) │ it 133819 (%8 ) │ de 121516 (%7 ) │ kr 102462 (%6 ) Thanks, Klaus

2 2

TBB on same system as relay?
by Rick Huebner 21 Oct '11

21 Oct '11

I run a relay 24/7, but sometimes also want to use Tor myself as a client. Until now, I've been using the Tor Button in my normal Firefox browser to switch in and out of Tor mode as needed, but now I see that going forward, the standalone Tor Browser Bundle is the only recommended way of using Tor as a client. How can I run the TBB on my system without interfering with my relay? When I just tried it now, the TBB brought up a second Vidalia instance which then tried to command my relay's existing Tor instance instead of spawning a second one for itself. This caused it to prompt for the relay's command interface password, but I cancelled out since I suspect that allowing the TBB to interfere with my relay's Tor process would lead to Bad Things, e.g. reconfiguring its options on the fly to a client-mode config and dropping all my users. So... how do relay operators use Tor themselves, if they can't run TBB? Or is there a way to configure them to live safely together? Or have I misinterpreted the new TBB focus, and the relay bundles will continue to support use as a client in the future as they do now? I'm using Windows 7 if that matters, but I doubt it.

4 4

Metrics portal problems?
by Rick Huebner 20 Oct '11

20 Oct '11

Is the metrics portal at https://metrics.torproject.org/ partly down, or undergoing maintenance or something? I see that some of the stats don't seem to have been updated in the last week or so. Many of the graphs are truncated, e.g. https://metrics.torproject.org/users.html?graph=direct-users&start=2011-10-…, and the per-relay stats on the https://metrics.torproject.org/networkstatus.html page all seem to stop with the 2011-10-12 13:00:00.0 consensus.

2 1

How works the flag attribution?
by Ottakar 17 Oct '11

17 Oct '11

Hi people, I just start my first node, and as my English is light, many aspect of the config are mysterious for me. I just see that my node as 2 new flags: "Stable" and "Guard". Maybe someone can explain to me how this attribution works? Thanks

3 2

Questions
by francois.pasgloup＠netcmail.com 16 Oct '11

16 Oct '11

2 1

icecat
by mick 09 Oct '11

09 Oct '11

Resending because I sent from the wrong address.... Begin forwarded message: To: tor-relays(a)lists.torproject.org Subject: icecat All I have now had a total of three abuse requests from the ISP hosting one of my tor nodes from a company called icecat (rip(a)icecat.biz) On the first two occasions I pointed to the notice on my server about it being a tor node and they went away. This time they are threating to null route my server if I don't do something. So reluctantly I have added a reject of 87.255.38.35:* to my exit policy. I'd be interested to hear from any other operators who have been pestered in this way about supposed abuses of icecat. Best Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------

2 1

Relay accounting calculations
by Steve Snyder 05 Oct '11

05 Oct '11

I'm not sure I understand how the relay accounting limit is calculated. The manual says that you might specify an AccountingMax limit of 1 GB, a ceiling that would be applied to each of the input and output traffic. The manual also says that it is known the output traffic can be larger than the input traffic, especially if you're running an exit node. (I imagine that the converse applies if you also have Tor clients on the same network, using the node, though the manual doesn't say so.) Given that the AccountingMax value applies to traffic in each direction, one would have to specify a rate that is half their actual limit. That is, given a 100GB limit one would specify "AccountingMax 50 GB" in the config file, causing the relay to sleep when 50GB is reached in either input or output traffic. Is the algorithm really this inflexible? If I reach 50GB on output traffic, with only 49GB of input traffic, that puts the relay into hibernation with 1GB of bandwidth left unused. That seems counter-intuitive to me. Is the manual inaccurate, or am I just missing the hidden genius of tracking input and output traffic as distinct pools? It seems more sensible to specify the full bandwidth allotment, with the relay hibernating when the sum of the input and output traffic reach that limit.

2 1

Hibernation timing & bandwidth
by Steve Snyder 05 Oct '11

05 Oct '11

I have a relay with a fixed monthly bandwidth limit, so I expect the relay to hibernate toward the end of the month. (I'm trying to spread the bandwidth out over the month, but actual relay utilization cannot be estimated accurately.) I'm wondering how to time this hibernation period. What I'd like to avoid is hibernating during a period when relay hibernation is common. If I know that most Accounting-limited relays hibernate at, say, the end of the calendar month, then I can schedule my hibernation to be at the start of the calendar month. If most hibernation is done on Saturday (day 6, the end of the week) then I can arrange to sleep on Wednesday (day 3). Is there a known trend to relay hibernation that I can schedule against? Thanks.

2 1

bad line
by cmeclax-sazri 05 Oct '11

05 Oct '11

You may have noticed a deterioration in my throughput over the past month. Yesterday I called my ISP, trying to figure out the problem, and was advised to put one computer directly on line and see what happens. I did this for an hour about 20:00 UTC, taking Tor and the mail server off line, and connecting just the laptop, on which I did pings. I saw 25% packet loss with no uploading or downloading (the laptop does have a Tor client, but I was not using it). Further testing with 2ping shows that the packets lost are incoming. Hopefully the problem will be resolved either early next week or the week after (I'll be out part of the week). cmeclax

1 1

Response back from DataCell/Iceland
by Patrick Hooker 01 Oct '11

01 Oct '11

I wrote a nice letter to DataCell about the bandwidth my Tor router was using and got a quick and good response. It also sheds some light on Datacell's(in Iceland) connectivity to the outer world. " Bandwidth in Iceland is an issue in terms of most ISP's charge by the gigabyte transferred. This is the case because most ISP's depend on Vodafone or Siminn for their backhaul and those charge by the transferred Gigabyte on the international side while they don't charge for national transfer. They do that because they pay outrageous prices on the link to central europe and probably because they want to make a lot of money too ;-). Our connectivity does not depend on them however. We managed to get a somehow acceptable price for international connectivity. Its still 5 times higher than bandwith in central europe but its at least not 50 times as high as the first offers we got. At the moment we have excess capacity. Our links are loaded like less than 1%. Once we get more customer, the link will be filled up. Our infrastructure is configured to use fair queuing. This means that every IP in our network gets a fair share of the bandwidth which is the way we operate. I don't mind having traffic on the excess bandwidth as long as all customers get their guaranteed part. If it would become an issue we would enforce it by using rate limits." So, for now anyway, there doesn't seem to be a problem with my running nearly 100GB/day through my Tor middle router. The TOS excludes the running of open mail proxies doing anything illegal (by Iceland's laws), this to be expected. I can see nothing in the TOS would directly rule out Tor, at least a non-exit router. All my contact with DataCell has been very friendly, I'd recommend them to anyone who can afford ~US$70/mo. for a virtual server. Just remember that when in Iceland, never carelessly throw stones and be polite to the littl' people. Bless Bless, Patrick

1 0

Updating arm
by Bill White 30 Sep '11

30 Sep '11

Hello all -- I'm running a brand-new relay (Diogenes) and at the same time I've discovered arm, which I find an excellent way to learn the art of running a Tor relay. I'm also a Linux beginner, so please forgive my ignorance about my question. My relay is now running arm v. 1.4.0.2, and I want to upgrade to the latest version, 1.4.4. I have downloaded and extracted the tarball (http://www.atagar.com/arm/download.php) However, running ./configure, and every combination of "how to" install/upgrade I can find, results in failure. And "sudo apt-get install tor-arm" tells me I already have the most recent version posted in the repository, which is where I obtained my original arm install. Can someone help me upgrade arm to the latest version? I'm running Ubuntu server 2.6.38-8-server x86_64 Thanks in advance, -- Bill

3 7

Introduction
by Patrick Hooker 29 Sep '11

29 Sep '11

Greetings, Thought I'd say a quick hello since I'm following the list for several days now. I'm running a non-exit relay, "Anonimulo" on a VPS account I have in Iceland. I'm not sure how long I'll be able to keep it up, I may need the bandwidth/CPU time for other activities in the future. For now I'm giving 1MB/s to Tor. I had been wondering just how to monitor my relay when I read about ARM on this list. I installed ARM, fiddled with the torrc a bit and was pleasantly surprised with ARM's display. Kudos to the developer! It appears that Anonimulo is running flat out at max bandwidth too. Yay! Patrick

4 5

Re: [tor-relays] max / burst speed
by Rick Huebner 29 Sep '11

29 Sep '11

On 9/27/2011 1:37 PM, "Steve Snyder" <swsnyder(a)snydernet.net> wrote: > Either there is simply not enough traffic to saturate all available middle nodes or Tor's node selection algorithm is, um, sub-optimal. I just started my relay a month ago, so I've done some research, and it seems to be pretty complicated. Please excuse what turned into an over-long post, but I think this is info that new relay operators don't generally know, and should. At its base, the traffic allocation scheme is elegantly simple: each client randomly selects circuit participants based on the sum of all the relays' bandwidth values from the most recent consensus (not counting complications like starting with a guard node, ending with an exit, etc.). So ideally, a relay with twice the bandwidth of another will (on average) be selected for circuits twice as often, and (again, on average) end up processing twice as much traffic. And also, if the total bandwidth demand from all clients is enough to consume, say, 60% of all Tor relays' available bandwidth, each relay will (on average) be kept operating at about 60% of capacity. But... the bandwidth figure in the consensus that clients use to select relays is not a simple figure. Apparently, it used to be based on the rates reported by each relay in their uploaded server descriptors, but people tried to game the system and fed it bogus data, so that was replaced by the authoritative servers going out and measuring the actual bandwidth of each relay by downloading a test file through it to see how fast it really went. So the values your relay uploads in the descriptor are ignored now, and your set Rate and Burst speeds aren't relevant for traffic allocation except in as much as they affect the speed that the official bandwidth scanner can download the test file through you. The only bandwidth figure that matters for driving traffic to your relay is the one reported in the consensus, which you can see at https://metrics.torproject.org/networkstatus.html, or from your own relay's DirPort at http://<relay>:<dirport>/tor/status-vote/current/consensus if you're a directory mirror. Note that these are not the values from any of the TorStatus servers, they're displaying something else entirely (and not always the same thing as each other, either). So anyway, don't expect a change in your torrc file to immediately bring you more traffic. Your relay has to get rescanned first, which probably only happens once a day. OK, fair enough. But those bandwidth numbers aren't just the simple speed which was seen when the scanner last downloaded a test file through your relay. To smooth out random speed changes as your relay is remeasured day to day, the bandwidth scanners use some kind of fairly slow exponential moving average of your download speeds. So it takes considerable time for changes in your relay's speed to slowly seep into the bandwidth number in the consensus. And for new relays, it seems that the initial value which the new measurements are slowly averaged into starts out pretty low, so that your reported bandwidth also starts out pretty low, and then gradually rises over time to somewhere around your actual Rate limit. And by slow, I mean weeks; my new relay has been running for a month, and over that time, I've seen the reported bandwidth slowly, with many fits and starts and temporary setbacks, go from about 20-30 to ~200 (about half my actual Rate limit), and it's still rising. Which kind of has the effect of putting new relays on probation, and slowly feeding them more and more traffic over time to see how they do, which is not a bad thing at all. But new relay operators are usually excited and anxious to see stuff happen, and need to be aware of this slow starting ramp up period and not get too discouraged or give up because they're not seeing much traffic at first. OK, so the bandwidth rating that matters is measured and slowly averaged... but there's yet another layer. To improve the overall performance of the Tor network, and to help clients generally create faster circuits, there's another bias factor thrown in. I don't know the details, but faster relays have their measured bandwidth figures artificially boosted to drive even more traffic through them than their high bandwidth would naturally attract, and/or slower relays have their bandwidth figures artificially lowered to drive less traffic through them (not sure which or both, but the effect is the same regardless). So if the overall client bandwidth demand is, again, 60% of the total Tor network bandwidth available, instead of each relay being at ~60% capacity, the fastest relays will be more fully utilized, and, unavoidably, that means that the slower relays will be correspondingly less utilized. This might dismay slower relay operators who feel that they're being prevented from contributing as much as they'd like, but objectively, it's generally better for a Tor client to have a 300 KB/s circuit hop than a 30 KB/s one. The faster relays are just nicer for clients to use, and it's better overall for the Tor network to make sure they get used as much as possible. And if those fast relays are getting more than their prorated "fair" share of usage based on their actual speeds, that unavoidably means that slower relays are getting less usage than their speed would normally merit. But that doesn't mean the slower relays are useless! Simply by existing, those extra relays greatly increase the difficulty of various attacks on Tor, just because they *might* have been used for any given circuit. Also, the whole guard node system for making certain nasty attacks infeasible relies on having lots of potential guard nodes to choose between, even relatively slow ones. And of course, all exit nodes are especially precious, almost regardless of speed. And finally, even if they're not used all that much while client demand on the Tor network is low to moderate, they provide an important spare reserve of bandwidth to make sure that some relay somewhere will always be ready to handle a new circuit even if the network becomes very busy and manages to max out the high speed "backbone" relays, or Tor is subjected to some kind of DOS attack. So anyway, for all the relay operators asking "why isn't my relay being used more?", there's your infodump. If it's a new relay, or you recently upgraded/raised your speed limits, keep an eye on the official bandwidth figure for your relay in the consensus, especially the nice graph displayed in the Router Detail page that you reach by clicking your router link on the https://metrics.torproject.org/networkstatus.html page. If that graph shows any upwards trend, the effects of your change are still slowly percolating into your official bandwidth figure, and more traffic will appear as it rises. If it's plateaued out, you're getting your share of the overall Tor traffic based on your relay's overall performance and the total client demand on the Tor network. For slow nodes who've limited their overall Rate to avoid hitting bandwidth caps, you might consider using AccountingMax to cap the usage to a safe level, and increase your speeds; you may find it more rewarding to relay significant traffic for 6 hours per day and then hibernate for 18 than to stay on "inactive reserve" status all the time. From the overall viewpoint of the network, is it better to have 1000 new relays at good speeds up 1/4 of the time (effectively adding 250 new fast relays), or to have them at slow speeds all of the time, not being used much? I'm not really sure, but I've noticed that the AccountingMax hibernation feature is hardly used at all from what I see on TorStatus, and I wonder why. OK, enough already, this turned out way longer than I was expecting. Hope it helps.

4 4

(no subject)
by Tim Myers 28 Sep '11

28 Sep '11

Stop Sent via BlackBerry by AT&T

3 2

Re: [tor-relays] max / burst speed
by Rick Huebner 28 Sep '11

28 Sep '11

On 9/27/2011 1:37 PM, "Steve Snyder" <swsnyder(a)snydernet.net> wrote: > Also, I have come to distrust TorStatus. Why? Because difference sites will have different numbers while supposedly monitoring the same network. One of my nodes is currently showing an Observed bandwidth of 10KB (yes, ten) at torstatus.blutmagie.de while the same node is showing an Observed 83KB at torstatus.all.de. Don't take the reported values as gospel. They seem to be measuring different things. As far as I can tell, blutmagie.de appears to be calculating the average bandwidth actually used overall per day, i.e. the average of the rates shown in the Recent Read/Write History graphs, which in turn appear to be faithful copies of the node's reported extra-info data. all.de reports the node's own observed bandwidth figure from its most recently uploaded server descriptor, and I have no idea what it's showing in its Read/Write History graphs, it's not the extra-info history data, and I can't relate it to anything. So blutmagie.de shows how much traffic the different routers are actually processing on average per second, and all.de shows the peak speed reached by each router in a short sprint (10 seconds?).

1 0

Re: [tor-relays] max / burst speed
by Rick Huebner 28 Sep '11

28 Sep '11

On 9/27/2011 1:37 PM, tor-relays-request(a)lists.torproject.org wrote: > No idea what shaping algorithm Tor uses, nor any clue on recommended > burst ratios under said algorithm. Anyone???. I believe Tor uses a token bucket algorithm (https://secure.wikimedia.org/wikipedia/en/wiki/Token_bucket) for traffic shaping. Which works sort of like a fuel tank with a steady rate of fuel being replenished each second (RelayBandwidthRate) and a max capacity of RelayBandwidthBurst bytes. If the tank is full, up to RelayBandwidthBurst bytes can be consumed, but only RelayBandwidthRate bytes will be replenished each second. So there's a sort of reserve available of Burst - Rate bytes, and consumption > Rate bytes/second depletes the reserve, and consumption < Rate refills the reserve, up to the max capacity. In general I think the higher the Burst you can allow, the better; it helps fast clients with small requests to zip through your relay quickly without clamping them to your overall Rate limit, and doesn't cost you anything since your long-term average is still enforced (bursts over your limit are balanced with slack periods under your limit). But I'm not clear on what the highest effective value would be. I could even see a point to having the Burst higher than your physical connection's actual limit, e.g. setting it to 10 times your connection's actual limit would allow bursts to max out your connection for 10 seconds (occasionally, to be balanced again by slack periods under your rate). But really, I doubt that values more than 2 or 3 times your Rate limit will actually matter, since Tor traffic doesn't seem to often come in those kinds of isolated high-multiple bursts (probably the natural averaging effect of having many clients routing dozens/hundreds? of circuits though your relay at once). A simple pragmatic test might be to run the Vidalia bandwidth meter for a day or two, and if the peak rate isn't hitting your Burst, it's high enough not to matter. One interesting side effect of a high Burst might be its impact on the way your relay's bandwidth is measured by the official bandwidth scanners, though. If the bandwidth scanner's test download file is small enough (less than many second's worth of your overall Rate limit bandwidth), a high Burst might allow the test file to be downloaded much more quickly than with a low Burst, raising your official measured bandwidth rating (and drawing more traffic to your relay). Larger test download files would mitigate this, but increase the scanner's workload and time between each relay's re-scans. Just a thought, I don't know how much effect this actually has.

1 0

max / burst speed
by Sebastian Urbach 27 Sep '11

27 Sep '11

Hi all, I doubled my max / burst speed values for my relay a few days ago. Unfortunately the new values are displayes in the statistic but not used at all. Does anyone have a suggestion for me how to get more work :-) ? Thanks and cheers -- Mit freundlichen Grüßen / Yours sincerely Sebastian Urbach -------------------------------------------------------- Religion is something left over from the infancy of our intelligence, it will fade away as we adopt reason and science as our guidelines. -------------------------------------------------------- Bertrand Arthur William Russell (1872-1970), British philosopher, logician, mathematician, historian, and social critic.

7 12

Fwd: Arm 1.4.4 Release
by Damian Johnson 26 Sep '11

26 Sep '11

(for the rare person that isn't on both tor-talk@ and tor-relays@...) ---------- Forwarded message ---------- From: Damian Johnson <atagar1(a)gmail.com> Date: Sun, Sep 25, 2011 at 8:21 PM Subject: Arm 1.4.4 Release To: tor-talk(a)lists.torproject.org Hi all. A new release of arm (http://www.atagar.com/arm/) is now available. Besides the normal batch of bug fixes and minor features this includes an interactive interpretor for raw control port access... http://www.atagar.com/arm/images/screenshot_interpretor_full.png http://www.atagar.com/arm/releaseNotes.php#1.4.4 This is intended to be a tool for developers, highly knowledgeable operators, and anyone that would like to learn about Tor's control protocol. It provides usability improvements like tab completion and history scroll-back, along with IRC style interpretor commands... * /help - provides usage information for all of the tor/interpretor commands and tor's configuration options * /info - queries relay information via fingerprint, nickname, or IP address * /find - searches the backlog for the given regex * /events - displays any events that we've listened for * /write - dumps the interpretor backlog to a file This can both be used via a new page in the curses interface and as a standalone prompt by running "arm --prompt"... http://www.atagar.com/arm/images/screenshot_interpretorPrompt.png Hopefully I'm not the only person that finds this to be useful! -Damian PS. Jesse, Spider.007, and pyllyukko: Tor is now hosting a mirror of the arm tarballs at... https://archive.torproject.org/arm/ This should, of course, be a little preferable for Gentoo, Arch Linux, and Slackware since it provides SSL using their cert. Thanks again for maintaining arm on those platforms!

1 0

Tor relays
by Mahesh Arunachalam 24 Sep '11

24 Sep '11

Please send me some tor relays.

2 1

Re: [tor-relays] Upgrading to 0.2.3.4 on Debian
by auto63557492＠hushmail.com 17 Sep '11

17 Sep '11

Updated my sources.list to have just this for tor: "deb http://deb.torproject.org/torproject.org/ wheezy main" When I run sudo apt-get update, system returns: "W: Failed to fetch http://deb.torproject.org/torproject.org/dists/wheezy/Release Unable to find expected entry main/binary-powerpc/Packages in Meta- index file (malformed Release file?)" Should there be a "binary-powerpc" directory under wheezy/main (or testing/main, stable/main, squeeze/main or any other for that matter)? Or am I missing something else? Again, thanks in advance, Bill - - - - Date: Thu, 15 Sep 2011 18:44:53 +0200 From: Moritz Bartl <moritz(a)torservers.net> Subject: Re: [tor-relays] Upgrading to 0.2.3.4 on Debian To: tor-relays(a)lists.torproject.org Message-ID: <4E722B85.9050006(a)torservers.net> Content-Type: text/plain; charset=ISO-8859-1 On 15.09.2011 06:41, auto63557492(a)hushmail.com wrote: > I run aptitude regularly, and my sources.list includes "deb > http://deb.torproject.org/torprojects.org squeeze main" but there > are no updates coming through for tor beyond 0.2.1.29-1 on my ppc > platform. > Should there be, or should I be doing something else to get to > 0.2.3.4? Am I even asking the right question? add deb http://deb.torproject.org/torproject.org experimental-squeeze main if you want unstable releases. -- Moritz Bartl https://www.torservers.net/

1 0

Upgrading to 0.2.3.4 on Debian
by auto63557492＠hushmail.com 15 Sep '11

15 Sep '11

I setup a relay to support the cause, but also as a means to learn about Linux - still a long way to got on the latter, and so this question: I run aptitude regularly, and my sources.list includes "deb http://deb.torproject.org/torprojects.org squeeze main" but there are no updates coming through for tor beyond 0.2.1.29-1 on my ppc platform. Should there be, or should I be doing something else to get to 0.2.3.4? Am I even asking the right question? Thanks...

4 3

increase txqueuelen: reasonable or not?
by Steve Snyder 26 Aug '11

26 Aug '11

The config page at torservers.net advises increasing the TX Queue Length from the default 1,000 to 20,000. For a differing opinion see the assertion that this increases latencies and hampers network congestion recovery ("bufferbloat"): http://www.cyberciti.biz/faq/gentoo-centos-rhel-debian-fedora-increasing-tx… I'm running an exit node on a 100Mbps network (multi-core CPU on RHEL5), and typically have 600 - 800 connections at any given time. TorStatus usually reports my throughput at 700KB to 800KB per second. I suspect that the 20,000 recommendation pertains to Gbit Ethernet. Still, though, is the default of 1,000 adequate for my Tor traffic? More generally, I haven't tweaked my networking (system network buffer sizes, etc.) because it is unclear to me what recommendations are appropriate for exit nodes running contemporary versions (v0.2.2.30+) of Tor. Reliable benchmarking can't be done because the system load varies with traffic at any given time. Is there a way to prove empirically that this or that adjustment to the system configuration really has an effect on the performance of a Tor relay node? Thanks.

4 3

Sorry, HotMail users, you're rejected
by Steve Snyder 23 Aug '11

23 Aug '11

Got another threatening e-mail from my ISP today, prompted by another SpamCop complaint regarding spam run through HotMail. HotMail records the address of the originating server and that, again, is my exit node. So I have to curtail exit access to HotMail. Yeah, it sucks, but I know of no way to block the sending of webmail while still allowing it to be retrieved.

3 4

relay uptime and stable flag
by Sambuddho Chakravarty 19 Aug '11

19 Aug '11

Dear All I see some relays with uptimes over 100 days (eg. Pandora14), but they don't have the stable flag enabled ... In the FAQ page it says that relays are marked stable when they are running for more than a day, however in the directory service page I see relays which are running for more than 200 days but not marked stable and some which are running for about 3 hours already have the stable flag. Why is there this difference ? Thanks Sambuddho

3 2

tornodeca is back
by cmeclax-sazri 17 Aug '11

17 Aug '11

There's only one now, in Canada, but it has the same nonexistent contact address my(a)mail.info as before, and again I got forwarding failure when my tor picked tornodeca as an exit for a website. cmeclax

1 0

Mitch McConnell
by Darrel 15 Aug '11

15 Aug '11

Well, nevermind. I do not need anonymity that badly- it is a thing of the past. Might as well be Japan defending nuclear power. Hi Mitch McConnell- ever smoke a joint? What is in the tea? Is it Republican? Do you have a fear of Kentuckians making money from plants? Commerce Man

1 0

exit node with private directory server
by Darrel 14 Aug '11

14 Aug '11

I have been reading the documentation and trying to get up to speed. Much of this is new to me. My goal is to have a directory server that is only available on my local-area network and on the same machine run an exit node available to the "onion network". Is this sort of configuration possible? I am installing a dedicated FreeBSD 9-beta computer at the moment and want to run run this configuration as my first tor installation. Darrel

1 0

directory and exit node on same server
by Darrel 14 Aug '11

14 Aug '11

I have been reading the documentation and trying to get up to speed. Much of this is new to me. My goal is to have a directory server that is only available on my local-area network and on the same machine run an exit node available to the "onion network". Is this sort of configuration possible? I am installing a dedicated FreeBSD 9-beta computer at the moment and want to run private directory and "public" exit node. Darrel

1 0

circuit ends in myself
by cmeclax-sazri 12 Aug '11

12 Aug '11

I just restarted tor after upgrading the version, then brought up Vidalia, and one of the circuits ends in myself! (xxx,xxx,cmeclax0 where the xxx's are other relays) How come? I'm a middleman.

2 2

Received abuse complaint - how did this happen?
by Steve Snyder 10 Aug '11

10 Aug '11

Today my ISP informed me that an abuse complaint had been lodged against me by spamcop.net. I looked at the report and my IP is indeed in it. It seems like a valid complaint. My question, though, is how did this happen? I'm using the Reduced Exit Policy as shown here: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/ReducedExitPol… Neither SMTP nor SMTPS are among the ports accepted as exit ports. Anyone have any thoughts as to how my Tor config can be used to transmit spam? Thanks.

4 4

jumping clock
by Softail 09 Aug '11

09 Aug '11

Every few days I find a log message like this Aug 08 07:20:09.241 [warn] Your system clock just jumped 122 seconds forward; assuming established circuits no longer work. Seems to always be 122 seconds as far as I can tell and happens at random times. Doesn't seem to be correlated with the log rotations or anything else. I'm running ntpd and that seems to be working fine. I started to let it use the kludge local clock in case the network was unavailable. I didn't think that was likely and it doesn't seem to have made any difference. Google turns up some complaints about this on much older versions 2.0.23. I'm currently running 2.1.30 from the Tor repository. It's i386 running on x86_64. I suppose I could try rebuilding a 64 bit version but so far haven't built my own yet. Would eventually like to dig into the sources but don't have time right now. Anybody else see this or have suggestions about what to do about it? Thanks -- A man in chains knows he should have acted sooner... Julian Assange

3 4

Setting up a "hidden" exit node
by Joel Hobson 09 Aug '11

09 Aug '11

Hi all, I'm an undergraduate student working as a research assistant for the summer. My current task is to figure out a way to measure delay caused by individual nodes (we want to replicate this paper: http://cis.poly.edu/~ross/papers/Tor.pdf <http://cis.poly.edu/%7Eross/papers/Tor.pdf>). It seems to me that the easiest way of accomplishing this would be to run an exit node and construct a two-hop circuit to it. OP ------> Node to be measured -------> Exit node Since the OP and exit node are under my control, I could measure the time it takes for any packets to reach the exit node from the OP. I want to be the only one who can use this exit node so I don't have to worry about getting approval from the school to run an exit node (could be time-consuming). I realize this is pretty far from any design goals the developers have, but is there some way of running a hidden exit node? One that doesn't appear on any directory server (PublishServerDescriptor 0 might work)****, but can still be used if you know its IP address? The Tor Control Protocol makes it easy enough to create a custom circuit (discussed here: http://thesprawl.org/memdump/?entry=8) but it won't accept IP addresses for nodes. I can put an IP in exitnodes in the torrc file, but exitnodes doesn't seem to have any effect, even when StrictExitNodes is set. Thanks Joel

2 1

bb
by 向梁 06 Aug '11

06 Aug '11

bb

1 0

Newbie Messed up Relay Setup
by flgcrz 05 Aug '11

05 Aug '11

Hello, Is this the right place to post if I'm having difficulties? I've done quite a bit of searching forums and things. I'm new to this and have been struggling a bit to get Tor and Vidalia working smoothly. I think I know what the problem is . I had my relay setup and working fine but Tor was not working. So I looked around a bit and I found this post on the Ubuntu forums and a useful guide to setting up Tor Vidalia and Polipo. I followed the instructions in that guide and finally Tor is working both when Vidalia boots and in my browser albeit with Torbutton as opposed to Foxyproxy (recommended in the guide). I thought this is great progress finally. But no I messed something up. In my enthusiasm I had copied the torrc from the guide without backing up my original and now my relay is no longer working. There are I believe 2 issues. The first I think is that the original references to my keys have been deleted. The second is I think something to do with the setup I have for ControlPort. I don't think its a firewall issue. I am running a firewall locally and have port forwarding setup on my wireless router for 9001 and 9030 Like I said I'm new to all this so I could be wrong. I also don't know a lot about encryption so I am hesitant to post the details of my logs on a public list. I've messed things up so if this is too much of a pain is there a way to just wipe out old keys and start a new relay from scratch? Thanks you in advance Best Kevin ---- Here is the post on Ubuntu Forums http://ubuntuforums.org/showthread.php?p=11117515#post11117515 Here are some of the details from from my logs ( minus the encyption stuff which I can post if those who know better think its ok to do so) Aug 04 18:38:10.018 [Info] resolve_my_address(): Guessed local hostname 'CRZ' resolves to a private IP address (127.0.0.1). Trying something else. Aug 04 18:38:10.019 [Info] resolve_my_address(): Interface IP address '192.168.1.130' is a private address too. Ignoring. Aug 04 18:38:10.023 [Info] resolve_my_address(): Address 'CRZ' resolves to private IP address '127.0.0.1'. Tor servers that use the default DirServers must have public IP addresses. Aug 04 18:38:10.023 [Info] router_pick_published_address(): Could not determine our address locally. Checking if directory headers provide any hints. Aug 04 18:38:10.024 [Info] resolve_my_address(): Guessed local hostname 'CRZ' resolves to a private IP address (127.0.0.1). Trying something else. Aug 04 18:38:10.025 [Info] resolve_my_address(): Interface IP address '192.168.1.130' is a private address too. Ignoring. Aug 04 18:38:10.026 [Info] resolve_my_address(): Address 'CRZ' resolves to private IP address '127.0.0.1'. Tor servers that use the default DirServers must have public IP addresses. Aug 04 18:38:10.027 [Info] router_pick_published_address(): Could not determine our address locally. Checking if directory headers provide any hints. Aug 04 18:38:10.027 [Info] update_consensus_router_descriptor_downloads(): 0 router descriptors downloadable. 0 delayed; 2494 present (0 of those were in old_routers); 0 would_reject; 0 wouldnt_use; 0 in progress. Aug 04 18:38:10.028 [Info] resolve_my_address(): Guessed local hostname 'CRZ' resolves to a private IP address (127.0.0.1). Trying something else. Aug 04 18:38:10.029 [Info] resolve_my_address(): Interface IP address '192.168.1.130' is a private address too. Ignoring. Aug 04 18:38:10.030 [Info] resolve_my_address(): Address 'CRZ' resolves to private IP address '127.0.0.1'. Tor servers that use the default DirServers must have public IP addresses. Aug 04 18:38:10.030 [Info] router_pick_published_address(): Could not determine our address locally. Checking if directory headers provide any hints. Aug 04 18:38:10.031 [Info] routerlist_remove_old_routers(): We have 2617 live routers and 1253 old router descriptors. Aug 04 18:38:10.032 [Info] resolve_my_address(): Guessed local hostname 'CRZ' resolves to a private IP address (127.0.0.1). Trying something else.

2 1

How to fully utilize resources for relay?
by Steve Snyder 05 Aug '11

05 Aug '11

I have a machine that is dedicated to being a Tor exit node. How can I maximize the performance (high throughput / low latency) of Tor traffic? I have plenty of under-utilized CPU and RAM resources on this system. According to TorStatus, my bandwidth is rarely maxed-out. This is on a Linux system, currently running Tor v0.2.2.30-rc. So... what resources can I spend to make this a better Tor node? Thanks.

3 3

Number of Connections Open
by Tim Sally 02 Aug '11

02 Aug '11

Hi! I'm working on a model to estimate the number of connections an OR has open as a function of the OR's bandwidth. I could really use some help confirming that my model is reasonable. Would any relay operators be willing to share the results of some variant of netstat | wc -l and the bandwidth of the relay? Thanks, Tim

8 7

Flags
by vinc3nt 01 Aug '11

01 Aug '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hello, I have set up a Tor relay. Where can I find online documentation that explains the meaning of all flags set: Authority Bad Directory Bad Exit Exit Fast Guard Hibernating Named Stable Running Valid V2Dir Some are intuitive, but others do not understand the meaning tnx - -- vinc3nt +--------------------------------------------------------------------+ |GPG Id key: 4096R/1E2A7F06 2010-11-23 http://pgp.mit.edu | |Key Fingerprint: 1355 B43E 99A9 37EF 5F27 A399 B71C 8AEB 1E2A 7F06 | |() ascii ribbon campaign - against html e-mail | |/\ www.asciiribbon.org - against proprietary attachments | +--------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJONoYsAAoJELcciuseKn8GEX4P/jmXuLHL7nKyDA7vOegKMeii HgesWX2cUbxpVkOzbVZ/ubtE2RMFmVfikS4ChbcIFzAECOKRctY1lDy45Sihwtit jNysYwm9Fh/3uBlpRPMdMhHA8g7rr6Xh5lDvkSTdeyJVAx0xnOLNEhT3Oi2aYsZF a2vgcwTLdsvgDRxMynDhDKwxKIfyPZk443gEYMaT3kxVlxr18zD8XDsFxbVOl9LO HhCZ3USJYHW/rWf3v1+HsIx28CHl0RaxPkwtMzX9oXvN5mLYyYy1O0w2wV7mDnp3 59BOAhxbe3oY6F4fmBrw3FyPfgUDPfD0DaY6UZxnokXeRG743XK8AkfXTkiP0g4B /MxBqWypqcNGUvlToii7GBW8RZt+wBukeS50Qok8+RLIIB7SZSPVx90GnZxCl2q5 tnrlqM0dNKi0/jXUHpcmuxsYVLGQ+k+8Ky2E106pagYiayYeajbhuXjPOmZIqYMu dXTqotR1p4JbJFnrmyFRomgDetKUBaZRk6Kjnln8grQyMglPoKFb/1EvtgxrKMOf hysEakFhIAV8yeCYiQAPm0vfSudgpz6i6reStqTMVrjQqm/HObedSTvN+h/Oy2QX MR1r8TTOSdRZgglxy59g/H4EruQxSET5P/RdnCBcRbLp6xDymPOilpSl+bhBS8KO zOt0C+asU/krtS/XDVzt =KUbN -----END PGP SIGNATURE-----

2 2

stable flag
by Softail 25 Jul '11

25 Jul '11

My relay seems to gain and lose the stable flag every day for the last several days. It's been up more than a week. Is this normal? I don't recall seeing this on a previous hosting provider and I suspect there is something going on with the network. I'm thinking of setting the log level to info or debug to try to figure out what is going on. Is that a good idea? Is it likely to be informative? Thanks -- A man in chains knows he should have acted sooner... Julian Assange

3 4

possible bad exit or bad circuit
by cmeclax-sazri 25 Jul '11

25 Jul '11

jceaovh Pandora18 tornodeca I was browsing a website that I hang out on all the time, and it came up with a Privoxy forwarding failure error. I tried another website and got the same error. I restarted Privoxy; didn't fix it. I brought up Vidalia and looked at the circuits. The one listed above was first; when I attempted to view the website, it added a line with the name of the website, labeled Closed, which quickly disappeared. I closed the circuit and refreshed the website and it came up.

2 5

Strange warnings
by Klaus Layer 22 Jul '11

22 Jul '11

Hi, My relays suddenly show the following warnings: "Tried to establish rendezvous on non-OR or non-edge circuit." Is this something I should worry about? I am wondering why several of my relays shows that at nearly the same time. Thanks, Klaus

2 1

Odd activity on my rely
by George Gemelos 19 Jul '11

19 Jul '11

I'm running an exit node, yreka and have noticed as single IP address that has been connected for at least a day, probably longer, which is pushing anywhere from 3Mb to 9Mb but receives very little traffic back from my node, sub 500Kb. My traffic to this machine is going out of 443 (my ORPort) and being sent to port 50090 on the other machine. I only allow exit traffic to ports 80 and 443. So I do not think this is exit traffic. I have also checked on blutmagie and could not find the IP as a relay which would suggest that this is a TOR user and I am serving as an entry node. I have never seen such speeds for a single user. The one sided nature of the traffic and its size have my interests peaked. I just wanted to verify that this is not unusual and something that I should investigating. I did not include the IP address of the machine because I was not sure it would be in the spirit of TOR to post such information. Any feedback would be greatly appreciated.

4 8

Seeking headless TAILS (or similar)
by Steve Snyder 19 Jul '11

19 Jul '11

I'm looking for a Tor installation that boots off of read-only media and acts as a relay, sort of a TAILS but without the user-space applications. Does such a thing exist? Thanks.

2 2

control_auth_cookie problem
by mick 18 Jul '11

18 Jul '11

Hi Guys I use munin to monitor a bunch of stuff (including tor) on my servers. The long run munin stats are quite useful. I checked my stats today and noticed that there were no entries for tor on one machine going back a couple of weeks. Now I know I rebooted the machine in question about 12 days ago and I /think/ I upgraded tor at that time. Certainly the restart will have caused a regeneration of the cookie file anyway. Checking my logs, I see the following from munin: "Unable to connect to Tor ControlPort (515 Authentication failed: Wrong length on authentication cookie" and similarly in the tor log: " Got authentication cookie with wrong length (16)" Now I can see that the cookie file is 32 characters long, so I'm guessing that the file contains a control character that is screwing up the munin php plugin line "$cookie = file_get_contents($cookiepath);" Anyone else seen this before? Any ideas for fixing it? - short of restarting tor again (I've done that and I'm reluctant to keep on stopping and starting what should be a stable server), Thanks Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------

2 1

DNAT question
by Softail 18 Jul '11

18 Jul '11

I'm trying to switch my ports from 9001/9030 to 443/80. The tor configuration seems straight forward. I tried /sbin/iptables --append INPUT --protocol tcp --match state --state NEW --destination a.b.c.d --dport 9001 --jump ACCEPT /sbin/iptables --append INPUT --protocol tcp --match state --state NEW --destination a.b.c.d --dport 9030 --jump ACCEPT /sbin/iptables --table nat --append PREROUTING --protocol tcp --source-port 443 --destination a.b.c.d --jump DNAT --to-destination :9001 /sbin/iptables --table nat --append PREROUTING --protocol tcp --source-port 80 --destination a.b.c.d --jump DNAT --to-destination :9030 but that doesn't seem to work. The OR and Dir ports are not reachable from the outside. I assumed that PREROUTING happened before INPUT but not really an expert on this. The firewall blocks everything else inbound to that address but the two ports I opened. Do I need to open 443/80 on the INPUT chain as well and if so do I also need to keep 9001/9030 open also? CentOS 5.6 if that matters. Thanks -- A man in chains knows he should have acted sooner... Julian Assange

2 4

How to set the path of tor control listener file?
by Klaus Layer 18 Jul '11

18 Jul '11

Hi all, I am running multiple tor instances on my relay server. All instances save the Control listener file to /var/run/tor/control. Therefore one instance overwrites the control listener file of the other. Is there a way to set the location where tor writes the control file as it can be done for PID file with parameter PidFile or authentication cookie file with parameter CookieAuthFile? Thanks, Klaus -- Klaus Layer Walldorf, Germany GPG Fingerprint: 466D 12F8 28A3 D137 A77E FC3B 271C 2D79 6F5E 94C9

2 1

Fwd: Arm 1.4.3 Release
by Damian Johnson 17 Jul '11

17 Jul '11

(especially relevant to relay operators...) Hi all. A new release of arm (http://www.atagar.com/arm/) is now available. This completes the codebase refactoring project that's been a year in the works and provides numerous performance, usability, and stability improvements... * Relay Setup Wizard Setting up a relay can be tricky for new users. In headless environments this means navigating Tor's massive, user unfriendly man page and even when Vidalia's an option it makes relatively poor exit configurations. Starting arm before Tor now provides instructions for auto-generating a good relay setup... a. Selection for what you'd like to be http://www.atagar.com/transfer/tmp/arm_wizard1.png b. Picking your relay options http://www.atagar.com/transfer/tmp/arm_wizard2.png c. Confirmation for the configuration it's making http://www.atagar.com/transfer/tmp/arm_wizard3.png * Menu Interface All of arm's capabilities are now available via a simple menu interface. http://www.atagar.com/transfer/tmp/arm_menu.png * Arm Gui Prototype Over this summer Kamran Khan has been working on a GTK frontend for arm as part of Google Summer of Code. The initial prototype is ready! http://inspirated.com/2011/06/28/summer-of-code-progress-graphs-logs-and-ac… * Performance Improvements Several arm and TorCtl performance fixes providing a 83% faster startup time, 12% lower memory usage, and instantaneous shutdown. * Improved Platform Support Vastly better support for Mac OSX. Arm has also been backported to Debian Squeeze and Ubuntu Lucid / Maverick. http://packages.debian.org/squeeze-backports/tor-arm https://bugs.launchpad.net/maverick-backports/+bug/721886 * ... etc Options for requesting a new identity, shutting down Tor, reconnecting if Tor's been restarted and many, many bugfixes. http://www.atagar.com/arm/releaseNotes.php#1.4.3 Cheers! -Damian

1 0

CPU utilization for relay
by swsnyder＠snydernet.net 15 Jul '11

15 Jul '11

FYI, this is a profile of my Tor v0.2.2.30-rc relay, taken in a 10-minute sampling: CPU: CPU with timer interrupt, speed 0 MHz (estimated) Profiling through timer interrupt samples % linenr info symbol name 3126 29.7290 cast-586.s:9 CAST_encrypt 1677 15.9486 sha256-586.s:8 sha256_block_data_order 1149 10.9272 aes-586.s:424 _x86_AES_encrypt 844 8.0266 sha1-586.s:8 sha1_block_data_order 273 2.5963 crypto.c:1649 crypto_digest_get_digest 221 2.1018 md32_common.h:283 SHA1_Update 182 1.7309 encode.c:190 EVP_EncodeBlock 171 1.6262 OpenBSD_malloc_Linux.c:1793 ifree 136 1.2934 cast-586.s:379 CAST_decrypt 130 1.2363 md32_common.h:348 SHA1_Final 127 1.2078 obj_lib.c:66 OBJ_dup 122 1.1602 memarea.c:221 memarea_alloc 110 1.0461 aes-586.s:1610 _x86_AES_decrypt After running for 14 hours, the Tor relay has consumed 1.6% of CPU time. It is now using 45MB of RAM, servicing 112 active connections. According to http://torstatus.blutmagie.de my Max/Burst/Observed (Bps) bandwidth is: 153600 / 307200 / 127170 Environment: CPU: Pentium-M (Dothan) @ 1.80 GHz RAM: 1.0 GB DDR1 Net: Fast Ethernet connected to a Surfboard cable modem CentOS v5.6 Tor v0.2.2.30-rc libevent 2.0.12-stable openssl 1.0.0d zlib 1.2.5 glibc 2.5-58 Just another data point.

1 0