- tor-relays - lists.torproject.org

bwadv vs bwhist + implications
by torhoste＠tor.host-ed.me 19 Sep '12

19 Sep '12

Hi, we're currently looking forward to expand our contribution to the Tor network and as a mathematically fascinated person, I'm pretty much into statistical data from https://metrics.torproject.org/network.html at the moment and implication on Accounting/Bandwidthrate configuration opportunities for our Tor relays to utilize them at maximum efficiency, i.e. I'd like to start a discussion with other relay operators. That said, I noticed that the BW advertised into the network (bwadv) vs the BW actually put through the network (bwhist) is at a 1.544945508 ratio throughout the whole Tor network. I.e. a relay configured to provide 500 GiB of traffic/mo would put through (respectively actually is putting through right now) "just" 323.63601 GiB traffic/mo on average. Now, my questions (respectively thoughts for discussion) would be: 1. What would you assume to be the reason for it? I mean this is a calculated average through 3117 relays and thus I'd say rather meaningful, i.e. the largest possible "sample" (i.e. it isn't just a few relays behaving like so). Also, looking at one of our own two test relays that is *definitely* running 24/7 - vks24949, it pretty much shows the same figures. Vnstat estimates 342.23 GiB traffic/mo for September 12 and the relay actually is configured to provide 500 GiB traffic/mo with daily accounting set up (1.461005756 ratio vs 1.544945508 ratio calculated from *.csv provided at https://metrics.torproject.org/network.html for the whole Tor network). 2. As a result of all that, I currently come to the conclusion that it could be a good practice to actually configure 1.544945508 times the traffic for both the daily accountingmax + the actual relaybandwidthrate in KiB/s to *really* utilize the BW provided by sponsors (in our very case) to the full potential. I'm looking forward to your input on this. Thanks in advance, Thomas

1 0

Need advice on IPv6 bridge config
by Steve Snyder 19 Sep '12

19 Sep '12

I'm getting my feet wet with IPv6 bridges, so far without success. I set up a test bridge (0.2.3.22-rc) on one network and plugged the address:port into Vidalia (TBB x86_64-2.2.39-1) on another. The bridge config looks like this in part (local IPv4 address hidden): Address aa.bb.cc.dd OutboundBindAddress aa.bb.cc.dd ORPort [2a00:1d70:ed15:37:235:53:64:0]:443 At run time the final Tor log entries are: [notice] Tor has successfully opened a circuit. Looks like client functionality is working. [notice] Bootstrapped 100%: Done. In Vidalia the message log entries are: [Notice] Learned fingerprint 24432B99CA2533BC95ABF66C7AFE835F96DD2B2D for bridge 2a00:1d70:ed15:37:235:53:64:0:443 [Notice] no known bridge descriptors running yet; stalling That last line is repeated periodically forever. So I have enough connectivity to correctly determine the fingerprint, bit not enough to get bridge descriptors. What am I doing wrong? Thanks.

2 7

Goodbye list
by Dude 18 Sep '12

18 Sep '12

thanks

1 0

Bad exit
by grarpamp 17 Sep '12

17 Sep '12

Exit (one of these two I think, no guarantees): 109C56AC68DB55D16E79F832E19313E6C3E47363 67FD1D03F922975269F94EC7E4FD38C6D0E5E900 - torservers? It's not occurring now via them, but whatever exit it was generated these... Error: mail.google.com uses an invalid security certificate. The certificate is only valid for the following names: *.mywebdav.de , mywebdav.de (Error code: ssl_error_bad_cert_domain) Erroneous public key presented: aa 94 04 12 c4 32 2b c9 62 48 00 88 16 6f cd 8a 21 22 fe 6d 9d 51 63 6f 85 62 db 9c b5 3f e6 bf 1d 45 ca 51 57 3d 5f 83 97 73 b6 dd 99 86 d8 27 e5 07 71 94 cf d5 a4 92 a6 25 f8 06 fd 50 6c ad 70 2c 71 ca 66 38 1d 35 93 f1 c3 ff 52 6a 90 3d 54 fd 6f 69 34 9f 59 29 aa 05 59 91 95 33 53 8b e6 b6 cf 65 dc 02 1a 31 57 d8 f4 11 70 f5 68 46 13 af c1 dc f0 b0 ce 43 b3 13 61 8a 18 00 84 32 2b 9a 9c aa 49 f3 fc b6 a1 d2 a9 d9 bd b4 53 a0 60 46 e7 e9 22 9d 23 08 5c 91 32 89 e7 85 4e ec 18 b7 d0 b3 6b 74 fa b4 f3 08 11 1f 1b e1 55 e9 7b 90 f4 64 93 08 a2 58 70 e0 c6 41 f9 f9 d0 9c b1 3d e9 b6 ae b3 73 ac 11 d3 f6 91 9e 79 f2 b4 d7 7d 96 8a 83 30 b1 bf 40 6f 18 24 42 43 b7 b1 65 7e 3d 1f d2 47 e9 fb 2e 10 21 7c ce 20 a8 c3 35 f3 d8 91 d1 a6 a1 87 52 4b de 39 1e ec b9 4d

4 3

Exit on Brasil
by guerra＠riseup.net 17 Sep '12

17 Sep '12

It has come to my attention this information on lorea's group at n-1.cc: n-1.cc/mod/threaded_forums/topicposts.php?topic=1396718&group_guid=489432 I am sorry if I am double posting, I just wanted to know how much bandwidth it is needed for this project to make sure I am able to contribute.

1 0

Massive ongoing google groups spamming
by tor-admin 13 Sep '12

13 Sep '12

Hi all, there is a massive spamming of google groups ongoing. I received several complains as below. From the domain list it seems that all major Tor exit nodes are affected. Running an Exit without custom WHOIS, all abuse message are received by my ISP and forwarded. So I have to temporarily ban google groups. How do other operators deal with this? Regards, Torland "This is some voluminous, off-topic flooding and harassment on the ba.broadcast Usenet newsgroup. It is being reported to abuse reporting mailboxes based on the contents of the NNTP-Posting-Host: and X-Complaints-To: headers, and lookup of the originating IP address via WHOIS and the Network Abuse Clearinghouse. They are sometimes also crossposted to unrelated newsgroups such as rec.arts.tv, soc.culture.new-zealand, and several other newsgroups in the nz.* hierarchy. It is disruptive, and completely off-topic, as well as causing disruptive, cascaded flame wars among those unrelated newsgroups. This user has also been posting from other sources, including 100tb.com, 51.net, 62.net, all.de, bahnhof.se, bayern.de, boingboing.net, broadviewnet.net, ccc.de, formlessnetworking.net, hessmo.com, noisetor.net, oceanic.net, plebia.org, privacyrepublic.org, riseup.net, ru.is, sbcglobal.net, servers.com, snydernet.net, solidonetworks.com, stanford.edu, stargrave.org, torland.me, torservers.net, dmzglobal.com, telstraclear.net, xtra.co.nz, clear.net.nz, orcon.net.nz, netgate.net.nz, freeparking.co.nz, powerusenet.com, giganews.com, thundernews.com, altopia.com, comcast.net, groups.google.com, and tigerusenet.com. It appears that you are merely the latest of his victims. The charter of ba.broadcast is as follows: "This group is here for discussions, comments and program reminders about broadcast media in the San Francisco Bay Area, both radio and television. It also includes cable systems and TVRO/BCRO in the SF Bay Area. It does not include scanner, ham radio or other action here in the SF Bay Area; these may be addressed in another newsgroup at another time. Issues of national interest should be posted to one of the groups in rec.arts.tv or rec.radio." (see: http://groups.google.com/group/ba.broadcast/browse_thread/thread/ddfbd8175e…) The charter does not include sexual innuendo and libel, abusive threats, bigotry and minority bashing, or any off-topic discussion of subjects not reasonably related to broadcasting in the Bay Area, which now consitute the overwhelming majority of current message traffic on ba.broadcast, to the detriment and exclusion of on-topic participation by others. Please take appropriate action to put a stop this this misbehavior originating from your site that is disrupting ba.broadcast. [... Offending article removed ...]

3 2

Re: [tor-relays] tor-relays Digest, Vol 18, Issue 1
by Christian 13 Sep '12

13 Sep '12

Hi Roger, > Who owns that socket file? /var/run/tor/control is owned by debian-tor. > Anything else in that other default config file? The tor-service-defaults-torrc file contains: DataDirectory /var/lib/tor PidFile /var/run/tor/tor.pid RunAsDaemon 1 User debian-tor ControlSocket /var/run/tor/control ControlSocketsGroupWritable 1 CookieAuthentication 1 CookieAuthFileGroupReadable 1 CookieAuthFile /var/run/tor/control.authcookie Log notice file /var/log/tor/log > > ORPort 443 NoListen > > > ORPort 0.0.0.0:9090 NoAdvertise > > > ORPort [::]:9090 IPv6Only NoAdvertise > > > > Is this ipv6 bind attempt the one causing problems? > > > > The ipv6 bind attempt was a try to solve the problem. Problem persists with and without ipv6 bind attempt. Thanks a lot! christian > 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. Failed to parse/validate config: failed to bind one of the > listener ports (Christian) > 2. Re: Failed to parse/validate config: failed to bind one of > the listener ports (Roger Dingledine) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 01 Jul 2012 06:14:19 +0200 > From: Christian <brightsidedarkside(a)t-online.de> > To: tor-relays(a)lists.torproject.org > Subject: [tor-relays] Failed to parse/validate config: failed to bind > one of the listener ports > Message-ID: <1341116059.2767.42.camel(a)delusions.local> > Content-Type: text/plain; charset="UTF-8" > > Hi Nick, hi Jean, > > thanks a lot for your fast reaction. I was at my parents' place for a > week, that's why I'm a little late. > > First, I tried port 9001, but in fact it is a port forwarding on the > router from 443 to 9090. > > Following, I post the terminal output when using the given torrc and the > torrc file itself. > Really, no logs are created, independent of the logging options. > The socket unlink issue happens since I use tor and that's for a while > now - it never affected functionality. > Yes, I'm into psychiatric symptoms. A friend of mine uses monsters' > names from films. ;-) > > Again, thanks a lot for your help! > > Thankfully > > christian > > ca@delusions:~$ sudo service tor restart > [sudo] password for ca: > * Stopping tor daemon... > [ OK ] > * Starting tor > daemon... > Jul 01 06:00:13.321 [warn] Could not unlink /var/run/tor/control: > Permission denied > Jul 01 06:00:13.321 [warn] Failed to parse/validate config: Failed to > bind one of the listener ports. > Jul 01 06:00:13.321 [err] Reading config failed--see warnings above. > > [fail] > ca@delusions:~$ > > > > The torrc (complete to prevent me from confusing, but slightly spoiled > by my mail client with line breaks - RunAsDeamon is set by another > default config file): > > > ## Configuration file for a typical Tor user > ## Last updated 22 April 2012 for Tor 0.2.3.14-alpha. > ## (may or may not work for much older or much newer versions of Tor.) > ## > ## Lines that begin with "## " try to explain what's going on. Lines > ## that begin with just "#" are disabled commands: you can enable them > ## by removing the "#" symbol. > ## > ## See 'man tor', or https://www.torproject.org/docs/tor-manual.html, > ## for more options you can use in this file. > ## > ## Tor will look for this file in various places based on your platform: > ## https://www.torproject.org/docs/faq#torrc > > ## Tor opens a socks proxy on port 9050 by default -- even if you don't > ## configure one below. Set "SocksPort 0" if you plan to run Tor only > ## as a relay, and not make any local application connections yourself. > #SocksPort 9050 # Default: Bind to localhost:9050 for local connections. > #SocksPort 192.168.0.1:9100 # Bind to this adddress:port too. > > ## Entry policies to allow/deny SOCKS requests based on IP address. > ## First entry that matches wins. If no SocksPolicy is set, we accept > ## all (and only) requests that reach a SocksPort. Untrusted users who > ## can access your SocksPort may be able to learn about the connections > ## you make. > #SocksPolicy accept 192.168.0.0/16 > #SocksPolicy reject * > > ## Logs go to stdout at level "notice" unless redirected by something > ## else, like one of the below lines. You can have as many Log lines as > ## you want. > ## > ## We advise using "notice" in most cases, since anything more verbose > ## may provide sensitive information to an attacker who obtains the > logs. > ## > ## Send all messages of level 'notice' or higher > to /var/log/tor/notices.log > #Log notice file /var/log/tor/notices.log > ## Send every possible message to /var/log/tor/debug.log > Log debug file /var/log/tor/debug.log > ## Use the system log instead of Tor's logfiles > #Log notice syslog > ## To send all messages to stderr: > #Log debug stderr > > ## Uncomment this to start the process in the background... or use > ## --runasdaemon 1 on the command line. This is ignored on Windows; > ## see the FAQ entry if you want Tor to run as an NT service. > #RunAsDaemon 1 > > ## The directory for keeping all the keys/etc. By default, we store > ## things in $HOME/.tor on Unix, and in Application Data\tor on Windows. > #DataDirectory /var/lib/tor > > ## The port on which Tor will listen for local connections from Tor > ## controller applications, as documented in control-spec.txt. > #ControlPort 9051 > ## If you enable the controlport, be sure to enable one of these > ## authentication methods, to prevent attackers from accessing it. > #HashedControlPassword > 16:872860B76453A77D60CA2BB8C1A7042072093276A3D701AD684053EC4C > #CookieAuthentication 1 > > ############### This section is just for location-hidden services ### > > ## Once you have configured a hidden service, you can look at the > ## contents of the file ".../hidden_service/hostname" for the address > ## to tell people. > ## > ## HiddenServicePort x y:z says to redirect requests on port x to the > ## address y:z. > > #HiddenServiceDir /var/lib/tor/hidden_service/ > #HiddenServicePort 80 127.0.0.1:80 > > #HiddenServiceDir /var/lib/tor/other_hidden_service/ > #HiddenServicePort 80 127.0.0.1:80 > #HiddenServicePort 22 127.0.0.1:22 > > ################ This section is just for relays ##################### > # > ## See https://www.torproject.org/docs/tor-doc-relay for details. > > ## Required: what port to advertise for incoming Tor connections. > #ORPort 443 > ## If you want to listen on a port other than the one advertised in > ## ORPort (e.g. to advertise 443 but bind to 9090), you can do it as > ## follows. You'll need to do ipchains or other port forwarding > ## yourself to make this work. > ORPort 443 NoListen > ORPort 0.0.0.0:9090 NoAdvertise > ORPort [::]:9090 IPv6Only NoAdvertise > > ## The IP address or full DNS name for incoming connections to your > ## relay. Leave commented out and Tor will guess. > #Address noname.example.com > > ## If you have multiple network interfaces, you can specify one for > ## outgoing traffic to use. > # OutboundBindAddress 10.0.0.5 > > ## A handle for your relay, so people don't have to refer to it by key. > Nickname BrightSideDarkSide > > ## Define these to limit how much relayed traffic you will allow. Your > ## own traffic is still unthrottled. Note that RelayBandwidthRate must > ## be at least 20 KB. > ## Note that units for these config options are bytes per second, not > bits > ## per second, and that prefixes are binary prefixes, i.e. 2^10, 2^20, > etc. > #RelayBandwidthRate 100 KB # Throttle traffic to 100KB/s (800Kbps) > #RelayBandwidthBurst 200 KB # But allow bursts up to 200KB/s (1600Kbps) > > ## Use these to restrict the maximum traffic per day, week, or month. > ## Note that this threshold applies separately to sent and received > bytes, > ## not to their sum: setting "4 GB" may allow up to 8 GB total before > ## hibernating. > ## > ## Set a maximum of 4 gigabytes each way per period. > #AccountingMax 4 GB > ## Each period starts daily at midnight (AccountingMax is per day) > #AccountingStart day 00:00 > ## Each period starts on the 3rd of the month at 15:00 (AccountingMax > ## is per month) > #AccountingStart month 3 15:00 > > ## Contact info to be published in the directory, so we can contact you > ## if your relay is misconfigured or something else goes wrong. Google > ## indexes this, so spammers might also collect it. > ContactInfo Sides of the moon <brightsidedarkside AT t-online dot de> > ## You might also include your PGP or GPG fingerprint if you have one: > #ContactInfo 0xFFFFFFFF Random Person <nobody AT example dot com> > > ## Uncomment this to mirror directory information for others. Please do > ## if you have enough bandwidth. > #DirPort 9030 # what port to advertise for directory connections > ## If you want to listen on a port other than the one advertised in > ## DirPort (e.g. to advertise 80 but bind to 9091), you can do it as > ## follows. below too. You'll need to do ipchains or other port > ## forwarding yourself to make this work. > #DirPort 80 NoListen > #DirPort 127.0.0.1:9091 NoAdvertise > ## Uncomment to return an arbitrary blob of html on your DirPort. Now > you > ## can explain what Tor is if anybody wonders why your IP address is > ## contacting them. See contrib/tor-exit-notice.html in Tor's source > ## distribution for a sample. > #DirPortFrontPage /etc/tor/tor-exit-notice.html > > ## Uncomment this if you run more than one Tor relay, and add the > identity > ## key fingerprint of each Tor relay you control, even if they're on > ## different networks. You declare it here so Tor clients can avoid > ## using more than one of your relays in a single circuit. See > ## https://www.torproject.org/docs/faq#MultipleRelays > ## However, you should never include a bridge's fingerprint here, as it > would > ## break its concealability and potentionally reveal its IP/TCP address. > #MyFamily $keyid,$keyid,... > > ## A comma-separated list of exit policies. They're considered first > ## to last, and the first match wins. If you want to _replace_ > ## the default exit policy, end this with either a reject *:* or an > ## accept *:*. Otherwise, you're _augmenting_ (prepending to) the > ## default exit policy. Leave commented to just use the default, which > is > ## described in the man page or at > ## https://www.torproject.org/documentation.html > ## > ## Look at https://www.torproject.org/faq-abuse.html#TypicalAbuses > ## for issues you might encounter if you use the default exit policy. > ## > ## If certain IPs and ports are blocked externally, e.g. by your > firewall, > ## you should update your exit policy to reflect this -- otherwise Tor > ## users will be told that those destinations are down. > ## > ## For security, by default Tor rejects connections to private (local) > ## networks, including to your public IP address. See the man page entry > ## for ExitPolicyRejectPrivate if you want to allow "exit enclaving". > ## > #ExitPolicy accept *:6660-6667,reject *:* # allow irc ports but no more > #ExitPolicy accept *:119 # accept nntp as well as default exit policy > ExitPolicy reject *:* # no exits allowed > > ## Bridge relays (or "bridges") are Tor relays that aren't listed in the > ## main directory. Since there is no complete public list of them, even > an > ## ISP that filters connections to all the known Tor relays probably > ## won't be able to block all the bridges. Also, websites won't treat > you > ## differently because they won't know you're running Tor. If you can > ## be a real relay, please do; but if not, be a bridge! > BridgeRelay 1 > ## By default, Tor will advertise your bridge to users through various > ## mechanisms like https://bridges.torproject.org/. If you want to run > ## a private bridge, for example because you'll give out your bridge > ## address manually to your friends, uncomment this line: > #PublishServerDescriptor 0 > > User debian-tor > > > > tor-relays-request(a)lists.torproject.org: > > 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: Failed to parse/validate config: failed to bind one of > > the listener ports (Nick Mathewson) > > 2. Re: Failed to parse/validate config: failed to bind one of > > the listener ports (Jean Trolleur) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 26 Jun 2012 11:59:22 -0400 > > From: Nick Mathewson <nickm(a)freehaven.net> > > To: tor-relays(a)lists.torproject.org > > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > > bind one of the listener ports > > Message-ID: > > <CAKDKvuyeEBDEO6rrbqVQSZcOy_cbeuGWMX2gisUjjETk0VgJEw(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Sat, Jun 23, 2012 at 7:38 PM, Christian > > <brightsidedarkside(a)t-online.de> wrote: > > > Hi dear fellows, > > > > > > I'm sorry to use again this way of addressing my problem as in Vol 17, > > > Issue 5. It will be the last time. Promise. > > > > > > I can't find any solution on the web. > > > When starting tor, it always reads "Failed to parse/validate config: > > > failed to bind one of the listener ports". > > > > Hm. It really should be saying something more than that on startup; > > there should be a message right before that about *why* it couldn't > > parse or validate the ports. > > > > I just tried the ORPort combination you listed there, and it seemed to > > work out okay for me. It might be easier to diagnose if you could > > upload your entire torrc, and the entire output of starting Tor up to > > the point where it says "failed to parse/validate config:" > > > > hth, > > -- > > Nick > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 26 Jun 2012 15:18:42 -0500 > > From: Jean Trolleur <sigtstp(a)gmail.com> > > To: tor-relays(a)lists.torproject.org > > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > > bind one of the listener ports > > Message-ID: > > <CAPN5qOdaMr==8D-kTz01cAZDHrDXSGuh5T+3DVfscJLx8jLgZA(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Try: > > > > ORPort 443 > > ORListenAddress 0.0.0.0:9001 > > > > On Sat, Jun 23, 2012 at 6:38 PM, Christian > > <brightsidedarkside(a)t-online.de> wrote: > > > Hi dear fellows, > > > > > > I'm sorry to use again this way of addressing my problem as in Vol 17, > > > Issue 5. It will be the last time. Promise. > > > > > > I can't find any solution on the web. > > > When starting tor, it always reads "Failed to parse/validate config: > > > failed to bind one of the listener ports". > > > > > > Furthermore, there are only empty logfiles, independent of the > > > configuration of the logs option "notice". > > > > > > Has anyone else this kind of problem? > > > > > > This is my ORPort section: > > > ORPort 443 NoListen > > > ORPort 0.0.0.0:9090 NoAdvertise > > > > > > I even can't make a control port accessible for e.g. arm running on the > > > same machine, although I didn't use it before. > > > > > > Client functionality is not working either. No connections through tor. > > > > > > Tor is configured as a bridge, my OS is Ubuntu lucid 10.04 and Tor's > > > version is 2.3.17-beta-1~lucid+1. > > > > > > It just worked until the upgrade to the new version through torproject's > > > repository. > > > > > > I really do have forwarded external port 443 to port 9090 on my machine. > > > > > > It nearly has me left in broken state dying. > > > > > > I checked for new requests concerning apparmor allowance, but there were > > > only the ability to chown and access to /sys/devices/system/cpu/ which I > > > granted both. > > > > > > I'm not so really competent with computers and therefore grateful for > > > any help. > > > Strange. No error logs, no function, no topic on the web.. > > > > > > Kind regards, > > > > > > christian > > > > > > > > > _______________________________________________ > > > 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 > > > > > > End of tor-relays Digest, Vol 17, Issue 8 > > ***************************************** > > > > > ------------------------------ > > Message: 2 > Date: Sun, 1 Jul 2012 05:14:22 -0400 > From: Roger Dingledine <arma(a)mit.edu> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Failed to parse/validate config: failed to > bind one of the listener ports > Message-ID: <20120701091422.GB8804(a)moria.seul.org> > Content-Type: text/plain; charset=us-ascii > > On Sun, Jul 01, 2012 at 06:14:19AM +0200, Christian wrote: > > Really, no logs are created, independent of the logging options. > > That's expected -- it's because logs are parsed in the same step as > binding the sockets, and it never gets to the 'setting up the logs' part. > > > The socket unlink issue happens since I use tor and that's for a while > > now - it never affected functionality. > > Who owns that socket file? > > > The torrc (complete to prevent me from confusing, but slightly spoiled > > by my mail client with line breaks - RunAsDeamon is set by another > > default config file): > > Anything else in that other default config file? > > > ORPort 443 NoListen > > ORPort 0.0.0.0:9090 NoAdvertise > > ORPort [::]:9090 IPv6Only NoAdvertise > > Is this ipv6 bind attempt the one causing problems? > > --Roger > > > > ------------------------------ > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > End of tor-relays Digest, Vol 18, Issue 1 > *****************************************

1 1

[OT] ExcludeNodes no longer working
by Scott Bennett 12 Sep '12

12 Sep '12

I know this really belongs on tor-talk, but I haven't been subscribed to it for a long time now. Sorry if posting this here bothers anyone. Back in early July, I upgraded from 0.2.3.13-alpha to 0.2.3.18-rc. I immediately ran into problems with a python script that honors the http_proxy environment variable, which I normally have set to the localhost port for privoxy, which, in turn, connects to tor's SOCKS port. I couldn't really see what was going wrong, but using arm to ask for a new identity seemed to help sometimes to get a circuit that worked. Sending tor a SIGHUP instead also seemed to work about as often. A bit over a week ago, I switched to 0.2.3.20-rc, and the problem still occurs. However, 0.2.3.20-rc now also emits a new message from time to time, the most recent occurrence of which is Sep 06 06:02:45.934 [notice] Low circuit success rate 7/21 for guard TORy0=753E0B5922E34BF98F0D21CC08EA7D1ADEEE2F6B. Wondering whether such circuit-building failures might be related to the other problem, I began a little experiment: each time I saw a "Low circuit success rate" message, I added the key fingerprint of the node in question to my ExcludeNodes list in torrc and sent tor a SIGHUP. The problem is still occurring, though, and when I look at the circuits involved, they all seem to have at least one of the excluded nodes in them, usually in the entry position. So my question is, what changed between 0.2.3.13-alpha and 0.2.3.18-rc (or possibly 0.2.3.20-rc) in the handling of nodes listed in the ExcludeNodes line in torrc? And is there anything I can do to get the ExcludeNodes list to work again the way it used to work? Thanks in advance for any relevant information. 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 * **********************************************************************

5 8

Re: [tor-relays] [OT] ExcludeNodes no longer working
by Scott Bennett 12 Sep '12

12 Sep '12

On Tue, 11 Sep 2012 16:24:36 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: >On Tue, Sep 11, 2012 at 1:12 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: >> Hi Scott, >> >> It is nice to see you posting again, I had wondered where you had gone. >> >> Scott Bennett: >>> I know this really belongs on tor-talk, but I haven't been subscribed >>> to it for a long time now. Sorry if posting this here bothers anyone. >> >> >> Seems like a fine place to discuss relay problems, which is what it >> sounds like, no? > >Maaybe! The very best place would be the bugtracker, of course. (I do >seem to recall that you have some issues with trac -- I'm just >mentioning the bugtracker so that other people don't get the idea that >the mailing lists are the best place for bug reports. But a bug >report on the mailing list is much much better than no bug report at >all.) You switched trackers a year or two ago. I don't recall whether I've tried the new one. Either way, I hesitate to submit a bug report until I'm pretty sure I'm looking at a bug, which is why I asked on this list whether anyone else could suggest anything. > >>> Back in early July, I upgraded from 0.2.3.13-alpha to 0.2.3.18-rc. >>> I immediately ran into problems with a python script that honors the >>> http_proxy environment variable, which I normally have set to the localhost >>> port for privoxy, which, in turn, connects to tor's SOCKS port. I couldn't >>> really see what was going wrong, but using arm to ask for a new identity >>> seemed to help sometimes to get a circuit that worked. Sending tor a >>> SIGHUP instead also seemed to work about as often. >> >> If you use 0.2.2.x - what happens? > >I'm not sure what the bug described here is, fwiw. What is the >behavior for the circuits that don't work, and to what extent is >0.2.2.x better? The problem is that the python script in question often has no trouble, but also often does. When it does, it usually gets a good connection twice and fails on the third connection. (Or at least I *think* that's what it does.) Then I either ask tor nicely with arm for a new set of circuits or I pound on tor with a SIGHUP for same, and then try the python script again. The process is slow, so it's very irritating to have to babysit it repeatedly until it finally gets a good connection. If I've left the script a small list of work to do, the failure may come at any point in the list, which then terminates the script. :-( I think it may have an option to ignore errors, but I don't really see an option like that as being very helpful in this situation because it would just fail its way through the rest of the list from that point, but it would take a long time to do that. Quitting outright is much faster. > >>> A bit over a week ago, I switched to 0.2.3.20-rc, and the problem >>> still occurs. However, 0.2.3.20-rc now also emits a new message from time >>> to time, the most recent occurrence of which is >>> >>> Sep 06 06:02:45.934 [notice] Low circuit success rate 7/21 for guard TORy0=753E0B5922E34BF98F0D21CC08EA7D1ADEEE2F6B. >>> >> >> That is an interesting message - I wonder if the author of that message >> might chime in? > >Looks like bug #6475. > >>> Wondering whether such circuit-building failures might be related to the >>> other problem, I began a little experiment: each time I saw a "Low circuit >>> success rate" message, I added the key fingerprint of the node in question >>> to my ExcludeNodes list in torrc and sent tor a SIGHUP. >>> The problem is still occurring, though, and when I look at the >>> circuits involved, they all seem to have at least one of the excluded >>> nodes in them, usually in the entry position. So my question is, what >>> changed between 0.2.3.13-alpha and 0.2.3.18-rc (or possibly 0.2.3.20-rc) >>> in the handling of nodes listed in the ExcludeNodes line in torrc? And >>> is there anything I can do to get the ExcludeNodes list to work again >>> the way it used to work? >>> Thanks in advance for any relevant information. >>> >> >> It seems that there are two issues - one is that a guard is failing to >> build circuits, the other is that you can't seem to exclude them. I have >> to admit, I'm more interested in the former... Is there a pattern to the >> failures? That is for the 7 successes for that node, did you see >> anything interesting? Were say, the nodes that worked somehow in the >> same country as that guard? Or perhaps were the other failed circuits >> all seemingly unrelated to the guard? >> >> As far as the ExcludeNodes - did you set StrictNodes at the same time? >> Are you also a relay? > >Any other configuration info would be helpful here too. Okay. Skipping over local port and IP address usage, here's some client-side stuff. TunnelDirConns 1 PreferTunneledDirConns 1 UseEntryGuards 1 NumEntryGuards [if you really need the number here, let me know--SB] AllowDotExit 0 LongLivedPorts 20-23,47,115,119,143,144,152,178,194,563,706,989,990,992-994,1863,5050,5190-5193,5222,5223,6000-6063,6523,6667,6697,8021,8300 There are also several NodeFamily statements and extensive ExcludeNodes and ExludeExitNodes statements. If there is other stuff you want, let me know, but depending upon what you ask for, I may choose to send it to you directly rather than post it here. > >(To answer your question: looking through the changelogs, and the >commit logs for src/or/circuitbuild.c and src/or/routerlist.c, I can't >find anything that stands out to me as something that might cause an >ExcludeNodes regression. So more investigation will be needed!) > The only thing remotely related that I saw was the following item in the Changelog for 0.2.3.15-rc. o Minor bugfixes (on 0.2.2.x and earlier): . . . - After we pick a directory mirror, we would refuse to use it if it's in our ExcludeExitNodes list, resulting in mysterious failures to bootstrap for people who just wanted to avoid exiting from certain locations. Fixes bug 5623; bugfix on 0.2.2.25-alpha. It probably has nothing to do with what has been causing me trouble, but it was the only item I found about either of the Exclude{,Exit}Nodes statement that mentioned a change between 0.2.3.13-alpha and 0.2.3.18-rc. Scott

1 0

Tor Weather - Node Down
by torhoste＠tor.host-ed.me 12 Sep '12

12 Sep '12

Hi, this is my very first post to this list. I operate tor exit relays vks24784 and vks24949 and subscribed to Tor Weather Reports. Now, at Sun, September 2, 2012 12:17 am and Thu, September 6, 2012 12:33 am, I received "Node Down" Reports for either of the nodes, 1st report for vks24949, 2nd for vks24784. That said, I noticed that these events reset the respective uptime counters at Atlas web application to "zero" and the nodes would lose the already earned stable, guard, named, etc. flags for a certain time period. The problem is that both nodes definitely were online to the best of my knowledge (they are 24/7 actually), please see the official Atlas logs at https://atlas.torproject.org/#details/AAD948023527A6D33FAA96816E4B5F101A664… and https://atlas.torproject.org/#details/B41CBB97CF4DCFF724F272F28FD3F0D683C2F… I even checked the "uptime" through ssh and there hasn't been any reboots occurring. Also, I'm wondering what actually would happen to guard, stable, named, etc. flags if I'd actually need to reboot the nodes cause of maintenance? I feel it unfortunate to lose these flags (also for the Tor network itself(?)) and would like to ask: 1. What does Tor Weather consider a "Node Down" event? 2. How long does it take to regain the mentioned flags? I.e. does the node start from scratch earning them (so to speak), i.e. does it take as long as initially? Last thing I'd like to ask in that context: Do these "Node Down" events and/or needed maintenance reboots have any effect on a potential Tor T-Shirt claim? I'd actually really like to make myself a communicative, green Tor advertising column at some point in time ;-) Thanks!

2 1

Re: [tor-relays] [OT] ExcludeNodes no longer working
by Scott Bennett 12 Sep '12

12 Sep '12

On Tue, 11 Sep 2012 16:12:36 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: >On Tue, Sep 11, 2012 at 1:52 PM, Steve Snyder <swsnyder(a)snydernet.net> wrote: >> On Tuesday, September 11, 2012 1:12pm, "Jacob Appelbaum" <jacob(a)appelbaum.net> said: >> [snip] >>> It seems that there are two issues - one is that a guard is failing to >>> build circuits, the other is that you can't seem to exclude them. I have >>> to admit, I'm more interested in the former... Is there a pattern to the >>> failures? >> >> I get those same messages occasionally. The following are from last week (v0.2.3.20-rc), seen from a Los Angeles datacenter. I haven't seen this rate of complaint before or since so I wrote it off as a fluke. >> >> Sep 01 05:20:31.000 [notice] Low circuit success rate 3/21 for guard BramaH4=39A0907D409836D7F014364C5FF5AC1DA79E0289. >> Sep 01 05:21:52.000 [notice] Low circuit success rate 6/21 for guard TORy2=F08F537D245A65D9C242359983718A19650A25F7. > >This looks like bug #6475. Those warnings should be suppressed in >0.2.3.31-rc and fixed for real in 0.2.4.x. ^^ Yikes. I do hope that was a typo. 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

Re: [tor-relays] [OT] ExcludeNodes no longer working
by Scott Bennett 12 Sep '12

12 Sep '12

Hi Jacob et al., On Tue, 11 Sep 2012 17:12:06 +0000 Jacob Appelbaum <jacob(a)appelbaum.net> wrote: >It is nice to see you posting again, I had wondered where you had gone. I've been here all along, but didn't have anything to say until this matter came up. > >Scott Bennett: >> I know this really belongs on tor-talk, but I haven't been subscribed >> to it for a long time now. Sorry if posting this here bothers anyone. > > >Seems like a fine place to discuss relay problems, which is what it >sounds like, no? Um, no, it seems to me that Exclude{,Exit}Node matters are client-side stuff. That's where the circuit routes are selected, which is where those torrc lines come into play, right? > >> Back in early July, I upgraded from 0.2.3.13-alpha to 0.2.3.18-rc. >> I immediately ran into problems with a python script that honors the >> http_proxy environment variable, which I normally have set to the localhost >> port for privoxy, which, in turn, connects to tor's SOCKS port. I couldn't >> really see what was going wrong, but using arm to ask for a new identity >> seemed to help sometimes to get a circuit that worked. Sending tor a >> SIGHUP instead also seemed to work about as often. > >If you use 0.2.2.x - what happens? No idea. I haven't built a "stable" version in at least five years, probably longer. > >> A bit over a week ago, I switched to 0.2.3.20-rc, and the problem >> still occurs. However, 0.2.3.20-rc now also emits a new message from time >> to time, the most recent occurrence of which is >> >> Sep 06 06:02:45.934 [notice] Low circuit success rate 7/21 for guard TORy0=753E0B5922E34BF98F0D21CC08EA7D1ADEEE2F6B. >> > >That is an interesting message - I wonder if the author of that message >might chime in? > >> Wondering whether such circuit-building failures might be related to the >> other problem, I began a little experiment: each time I saw a "Low circuit >> success rate" message, I added the key fingerprint of the node in question >> to my ExcludeNodes list in torrc and sent tor a SIGHUP. >> The problem is still occurring, though, and when I look at the >> circuits involved, they all seem to have at least one of the excluded >> nodes in them, usually in the entry position. So my question is, what >> changed between 0.2.3.13-alpha and 0.2.3.18-rc (or possibly 0.2.3.20-rc) >> in the handling of nodes listed in the ExcludeNodes line in torrc? And >> is there anything I can do to get the ExcludeNodes list to work again >> the way it used to work? >> Thanks in advance for any relevant information. >> > >It seems that there are two issues - one is that a guard is failing to >build circuits, the other is that you can't seem to exclude them. I have Right, but the guard's problem really shouldn't be my problem, although I suppose I could try emailing the node's operator about it. >to admit, I'm more interested in the former... Is there a pattern to the >failures? That is for the 7 successes for that node, did you see >anything interesting? Were say, the nodes that worked somehow in the >same country as that guard? Or perhaps were the other failed circuits >all seemingly unrelated to the guard? I haven't the foggiest. I don't even know over how much time tor has been calculating the ratio before it decides to issue that message. It could be minutes, hours, days... The failures I started getting with 0.2.3.18-rc were really irritating, but I didn't have a clue to follow until switching to 0.2.3.20-rc, which issues the interesting messages. That prompted me to turn INFO logging back on and watch what happened when I ran that script. Between the log and looking at arm's display of current circuit routes, I was able to see that nodes were being used that were supposed to have been excluded. > >As far as the ExcludeNodes - did you set StrictNodes at the same time? No. However, there are usually 800 - 900 guards active at any time these days, so I figured that excluding only the ones that gave me trouble would leave plenty of others available for selection. >Are you also a relay? Yes. See MYCROFTsOtherChild in the consensus, descriptors, or tor status pages. It's the same one I've been running for years, apart from short hiatuses in 2007 and 2008. Scott

1 0

Tor Weather - Node Down
by torhoste＠tor.host-ed.me 11 Sep '12

11 Sep '12

Hi, this is my very first post to this list. I operate tor exit relays vks24784 and vks24949 and subscribed to Tor Weather Reports. Now, at Sun, September 2, 2012 12:17 am and Thu, September 6, 2012 12:33 am, I received "Node Down" Reports for one of the nodes, 1st report for vks24949, 2nd for vks24784. That said, I noticed that these event resets the respective uptime counters at Atlas web application to "zero" and the node would lose the already earned stable, guard, named, etc. flags for a certain time period. The problem is that both nodes definitely were online to the best of my knowledge (they are 24/7 actually), see http://tor.host-ed.me/nodes/ and official Atlas logs at https://atlas.torproject.org/#details/AAD948023527A6D33FAA96816E4B5F101A664… and https://atlas.torproject.org/#details/B41CBB97CF4DCFF724F272F28FD3F0D683C2F… I even checked the "uptime" through ssh and there hasn't been any reboots occurring. Also, I'm wondering what actually would happen to guard, stable, named, etc. flags if I'd actually need to reboot the nodes cause of maintenance? I feel it unfortunate to lose these flags (also for the Tor network itself) and would like to ask: 1. What does Tor Weather consider a "Node Down" event? 2. How long does it take to regain the mentioned flags? I.e. does the node start from scratch earning them (so to speak), i.e. does it take as long as initially? Last thing I'd like to ask in that context: Do these "Node Down" events and/or needed maintenance reboots have any effect on a potential Tor T-Shirt claim? I'd actually really like to make myself a communicative, green Tor advertising column at some point in time ;-) Thanks!

1 0

GPG error
by Ottakar 10 Sep '12

10 Sep '12

Hi everyone, my node is actually down and when I want to update my debian, I' got a GPG error: root@foo:/home# apt-get update W: Une erreur s'est produite lors du contrôle de la signature. Le dépôt n'est pas mis à jour et les fichiers d'index précédents seront utilisés. Erreur de GPG : http://deb.torproject.org squeeze Release : Les signatures suivantes ne sont pas valables : KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 W: Impossible de récupérer http://deb.torproject.org/torproject.org/dists/squeeze/Release W: Le téléchargement de quelques fichiers d'index a échoué, ils ont été ignorés, ou les anciens ont été utilisés à la place. Where can I find the procedure to update the GPG key? Thx

3 2

Subsidizezed relay proposal
by Dude 10 Sep '12

10 Sep '12

I want to share my thoughts and get feedback on operating a sponsored dedicated exit relay. 0. register a domain name 1. set up a centos linux based dedicated server at a Tor compatible ISP in the USA a. get myself set up as abuse contact for my IPs (I have worked the abuse alias before) b. "10MB" net connection. Most 100MB give you around 9 MB actual and 10 MB give you 6MB actual 2. set up a 'mostly public' exit node and run it intermittently while I tune and debug it 3. operate node for a month before submitting receipts for funding 4. add more nodes if this works I realized I have no assets, so I am going to hold off from creating a LLC type company for financial protection. Are there any more specifics and how/when subsidies will be released? Cheers!

1 0

Current state of v0.2.3.x IPv6 bridges?
by Steve Snyder 10 Sep '12

10 Sep '12

I'm wondering about the benefit of running abridge on an IPv6 address. Since the big announcement last December that v0.2.3.9 supports IPv6 addresses for bridges, I've read a few comments to the affect that BridgDB doesn't understand IPv6 addresses. So... what is the state of publishing IPv6 bridge addresses? Will clients requesting a bridge address ever be given an IPv6 address? Can a client specifically request an IPv6 address (or IPv4 address, for that matter)? Thanks.

3 2

Repository
by Jörg Frings-Fürst 06 Sep '12

06 Sep '12

Hi, I got the following error on every update. Pls fix it.. Jörg Frings-Fürst W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.torproject.org precise InRelease: The following signatures were invalid: KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 KEYEXPIRED 1346668560 > > W: Failed to fetch http://deb.torproject.org/torproject.org/dists/precise/InRelease > > W: Some index files failed to download. They have been ignored, or old ones used instead. >

2 1

Operating a sponsored relay II
by Dude 31 Aug '12

31 Aug '12

My research is telling me I can not host a Tor relay at most retail ISPs because it is perceived as an "open relay" and these cause a lot of headaches for ISPs. So that leaves colo, but this gets expensive fast. This is very expensive outside the USA. Could I work as an agent of torservers.net? Is there a FAQ listing friendly ISPs? I understand the need for documentation and receipts for expenses. It might be helpful to get quarterly payments instead of monthly. I was thinking of an USA Llc. for protection. Looking at my notes I now remember an 's-corp' is better for a single owner (simple corporation). Here is a link to the US commercial code for s-corps: http://www.gpo.gov/fdsys/pkg/USCODE-2011-title26/html/USCODE-2011-title26-s… I would be happy to document the process of setting up a US s-corp. if I create one. Cheers!

3 2

Has anyone had any success running a relay on an mk802?
by someonelse 30 Aug '12

30 Aug '12

I currently run a relay at home during the day, but would like to run one 24/7. Has anyone had any success doing this with the mk802 or similar device? This site seems to say it's possible: http://romanrm.ru/en/a10/mk802-server "It can run Web/Mail/DNS/DHCP/VPN/Jabber/Mumble/Tor servers..." I think this may work for me since I prefer Debian, something inexpensive (~$70 qualifies), low power and want to run wired Internet. If not the mk802 or mk802-II, then what device would do this better for around the same price? Thanks, Someonelse

1 0

Operating a sponsored relay
by Dude 29 Aug '12

29 Aug '12

Hello, I have experience working at ISPs supporting dedicated servers and am interested in operating a sponsored relay. Potential issues I see: # A true 100mb network connection is going to be expensive. Often a 24 port edge switch has just one 100mb uplink port. # As an operator, I might want an LLC to protect me from personal liability in the USA. # Ideally an ISP outside the USA would be used so the server is in a different legal jurisdiction than the operator. This would make payment and communication more difficult. At this time I imagine a server with an encrypted file system and long term log retention disabled. Reasonably hardened OS, but nothing too exotic. I think $100 a month above other costs would be fair. But I do not know how much attention a node would require once it was set up. If it requires a lot of time, more compensation would be in order. I am not looking to make a lot of money doing this, but I can not do it gratis. Cheers, John

2 1

Re: [tor-relays] "Relay info kit" for Tor exits at universities
by Scott Bennett 25 Aug '12

25 Aug '12

On Sat, 11 Aug 2012 04:08:57 -0400 Roger Dingledine <arma(a)mit.edu> wrote: >I've spent the week talking to my contacts at US universities, to get >them to spin up fast exits. Currently the fast exits in North American >universities are: > >- University of Waterloo (Ian Goldberg) >- Boston University (Leo Reyzin) > >We're now on track to add: >- UPenn (Matt Blaze) >- UMichigan (Alex Halderman) >- CMU (Nicolas Christin) >- Georgia Tech (Dave Dagon) > >and I have professors from George Mason, Illinois, UNM, UMN, UConn, >UW, and others looking into it. > >Wendy and I are talking to some lawyers to try to write up a short >(several paragraph) document targeted toward the university's general >counsel, for preemptive use by the computer science professors who plan >to run the Tor exit. > >What else should go in a "so you want to run a big exit" info kit? > >- Pointers to the legal-faq (and dmca template) and abuse-faq. > >- Pointers to Mike's blog entry: >https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment >and my old Tor-at-universities wiki page: >https://trac.torproject.org/projects/tor/wiki/doc/TorGuideUniversities > >- Is there some document suggesting how to SWIP your address, and >explaining the importance of having your abuse mails go to someplace >other than your general university abuse team? It's touched on in several >places but we should make it even clearer. > >- What are the good answers now to "what hardware should I use, and how >should I configure it?" I've been telling people they'll be happiest with >Debian, and that something 64-bit and/or with AESNI support will be best. Fast relays use lots of memory, which vastly worsens the effects of the "small TLB" problem inherent in all modern CPUs, so running a fast relay on a FreeBSD kernel with superpages support enabled is likely to reduce considerably the CPU load for the traffic served, which is more or less equivalent to increasing the traffic capacity for any given CPU speed. Superpages support has been available since 7.2 for i386 and amd64 platforms, but will likely be available on other platforms at some point. Support on another platform was supposed to appear in 9.0, IIRC, but I don't remember which (ia64?). I'm not sure what will be in later releases, but my understanding is that the kernel development team planned to add superpages support eventually to the rest of the FreeBSD-supported hardware platforms that are capable of it (not, for example, powerpc because that hardware does not support the multiple page sizes involved). Rather than risk triggering OS religious wars here, it might be better to limit OS recommendations to merely which to avoid because they have limitations likely to prevent successful operation of a fast exit node (e.g., non-server versions of Windows). The administrators of fast nodes already know what their current setups are and the current knowledge bases of their staffs are. > >- [remainder deleted -SB] 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

"Relay info kit" for Tor exits at universities
by Roger Dingledine 24 Aug '12

24 Aug '12

I've spent the week talking to my contacts at US universities, to get them to spin up fast exits. Currently the fast exits in North American universities are: - University of Waterloo (Ian Goldberg) - Boston University (Leo Reyzin) We're now on track to add: - UPenn (Matt Blaze) - UMichigan (Alex Halderman) - CMU (Nicolas Christin) - Georgia Tech (Dave Dagon) and I have professors from George Mason, Illinois, UNM, UMN, UConn, UW, and others looking into it. Wendy and I are talking to some lawyers to try to write up a short (several paragraph) document targeted toward the university's general counsel, for preemptive use by the computer science professors who plan to run the Tor exit. What else should go in a "so you want to run a big exit" info kit? - Pointers to the legal-faq (and dmca template) and abuse-faq. - Pointers to Mike's blog entry: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment and my old Tor-at-universities wiki page: https://trac.torproject.org/projects/tor/wiki/doc/TorGuideUniversities - Is there some document suggesting how to SWIP your address, and explaining the importance of having your abuse mails go to someplace other than your general university abuse team? It's touched on in several places but we should make it even clearer. - What are the good answers now to "what hardware should I use, and how should I configure it?" I've been telling people they'll be happiest with Debian, and that something 64-bit and/or with AESNI support will be best. - We should set up a mailing list for university relay operators to share experiences and feel solidarity. I'll also encourage them to sign up here. We might also post a list of university Tor exits somewhere obvious, so new ones can gain more confidence in the idea. What other resources exist already that would be especially useful for new fast exits? What resources don't exist but should? --Roger

7 14

exit node with different IP address
by cmeclax-sazri 22 Aug '12

22 Aug '12

I rebooted my computer with a freshly compiled kernel and world, brought up my browser, and before doing something where I need to know my IP address is hidden, brought up check.torproject.org. It said "You are not using Tor." But the address is 217.148.84.179, which isn't anywhere near me. So I brought up torstatus.blutmagie.de and searched the page. It lists AMORPHIS at 217.148.84.180. I don't see ExitAddress in torrc. Should there be one? cmeclax

2 1

hi
by P.H. H 19 Aug '12

19 Aug '12

tor-relays(a)lists.torproject.org

2 1

Notice of disruption of service
by Dennis Ljungmark 17 Aug '12

17 Aug '12

Hi all, I'm sad to say that I've been forced to disable three of our six relays, and reduce the others to minimal transfer speeds. We are currently being exhorted by our ISP, Bahnhof for a huge amount of money due to "excessive traffic" in order to sign us up on a new contract. This should serve as a warning call for people who are using or considering to use Bahnhof. Contact take(a)deklomp.se for more information about the case. The affected nodes are: ( Reduced speed ) depth 9EDB9965625A06F41D84581BF66CAF7D79919DC4 vandalise 8D3E65A90F455E77DEFAA9ACEAFD7392221E2C9C deklomp1 0A9CB1B43C780634B80390A9093C7490CB503880 ( Offline until the issues are resolved ) deklomp2 EFA394DD66A8147AAEF3604B37CBF77DE2C7D895 deklomp3 FB5BECE11DDCE8444CB2EB0A41303DBB7093EA7A deklomp4 2403121E35A830A7131C388EB643915F06842FB4 Regards, D.S. "Spider" Ljungmark

2 2