- tor-relays - lists.torproject.org

Re: [tor-relays] OpenBSD: tor rc script: don't kill unrelated tor instances (patch)
by teor 23 Jun '15

23 Jun '15

> Date: Tue, 23 Jun 2015 13:09:07 +0200 > From: Fabian Keil <freebsd-listen(a)fabiankeil.de> > > nusenu <nusenu(a)openmailbox.org> wrote: > >>> … >>> Did you test with custom flags like "--+Log ${tor_loglevel} file >>> ${tor_logfile}"? >> >> This should read "--Log" no? > > While I prefer using neither "--Log" nor "--+Log", the latter > is valid syntax and used in the real world: > https://svnweb.freebsd.org/ports/head/security/tor-devel/files/tor.in?view=… > > … >> - From tor's man page: >>> Other options can be specified on the command-line in the format >>> "--option value", in the format "option value", or in a >>> configuration file. > > Looks like the man page is incomplete. See the next section, "THE CONFIGURATION FILE FORMAT" > By default, an option on the command line overrides an option found in > the configuration file, and an option in a configuration file overrides > one in the defaults file. > > This rule is simple for options that take a single value, but it can > become complicated for options that are allowed to occur more than > once: if you specify four SOCKSPorts in your configuration file, and > one more SOCKSPort on the command line, the option on the command line > will replace all of the SOCKSPorts in the configuration file. If this > isn't what you want, prefix the option name with a plus sign, and it > will be appended to the previous set of options instead. > > Alternatively, you might want to remove every instance of an option in > the configuration file, and not replace it at all: you might want to > say on the command line that you want no SOCKSPorts at all. To do that, > prefix the option name with a forward slash. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Re: [tor-relays] OpenBSD: tor rc script: don't kill unrelated tor instances (patch)
by nusenu 23 Jun '15

23 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > Did this reply make the intentions clearer? > >> Yes, thanks. Though my first inclination would be to tell users >> "don't use rc.d if you've got the ansible role configured", I >> suppose it can't hurt to make it foolproof. I'll test your patch >> in different scenarios, and, if it works, commit it. Thank you! -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJViTfhAAoJEFv7XvVCELh0164P/2ORfHYYdh2MbihJP/3yrKoK JuvgHLcRmYHob7s8vFAzdg8KqpriyNGuWCGY1b5ameXNFpy5slwGP0wmTFIe8qIA pfHVO1Oo1r4vFpMq5PEjHZloBLBnjxwDbcuC2D+b4f8YeOMjSeB4Rf6yXWF2EXju 3cEsUb5UguQ6YAcFItlW8Es/XijHp5Ad1e2DUXpl/te8FH7VxoK41ctILP4zs0kM ykPWgq7j5V0/OQS4BOe71i85S37sssejTFyPLV6kTdDUN1zLZKiUZljkgktfjAwm uMGp3FGnVWL0mN6KmK0OM1DesbRsIv0yMU/FIUyaL0vOnh/vgDt/o2seBKo7Evsy Po6w/J5X27M3gsFG5HtNuyrONssndvSsVwNQvpXf2vTiz342fulRnptCjvtNz+iI CGfpJ6i2VHH7ZMY0ZDYIfBrgZDa/HdzlZU9gk4hmORJOpol4jMjqDu44K7RW8PLo hHTqa/gWBKZsOwSpXDjsQyMYCFGvxcCXdqDOa1KNJa4zw/pZur52b7fv0s8/+Lky u19lBODZO/7br1Sg4fwmMjLVUbkQtIwtmBdbRWP6zqEByFEt/LJSt93RXs2rMtX0 IVKWCvh3+G04nZkv0AbF/YeMKe9ABp1pbP7I3M+X0wOdKzpPsBLjjUYxaOpZnhqn 7wJDlcBTqVQ86e1lavlD =WeYu -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] OpenBSD: tor rc script: don't kill unrelated tor instances (patch)
by nusenu 23 Jun '15

23 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Pascal, thanks for the fast reply. I think there is a slight misunderstanding. >> rc.subr(8) does not have multi-instance support, and it will most >> likely stay that way. Correct, and I'm _not_ trying to add that in any way to rc.subr or to your rc script. > What you're trying to do is going against that design >> decision, so I suggest you simply don't use the rc.d subsystem >> if configured for multiple instances. Even if I'm not using it at all, your rc script will kill unrelated tor instances, this is not limited to an ansible environment. The goal is only to be able to have your tor package + the ansible role on the same system without the rc script from the package interfering with unrelated tor instances created via ansible. >> I mean: As soon as you have more than one tor instance running, >> you'll have to implement a way to start/stop/restart/reload all >> of them individually anyway That is already done. Did this reply make the intentions clearer? After all the proposed fix should not generate any new problem or effort for your package, or does it? thanks! -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJViTOUAAoJEFv7XvVCELh0wVUP/1PX+HjEUvDTlg8mKZzCwy4Q pXbSQpqEyuXDLbAYvN2GOnL0Vd8jSH5NxpuRFHnevdEC0/vdAbRRAJRbQwXSneYk 60XCVCLW8IFsNwDNjzDf1oXkcQFIkPQW7uoyFWxn7Km/JITtRIrpmpfdMYQ1ievM DBIEFZZWg1/Oa2NsxYPc1NQHdFoxbRLEwmRT8bZCHuPjB+pULTjZyuCpTcO4xcmt peE5SeE74X4oakrHqjLdoF0Vmcak1NNpulvV/Q/GMhqzucAbnvzoUrEHNn5ffxhC s+dd5kkrOwN61E3vg+1JxdWSK2Bh6Equ8DgIhW4pNOlenmGLQwL8HeuQ6hAJafCt rPAdEP9RtKIB+uj0KvZtngUhlkonnHeu/NGX6wSfwgL1S8SjSBCRCVPWDKs+Bkdx PM4VGBHw9USdXbBPrKvMpvDKxoX5wNJOBArTdz3UfJh+sow5tD0i/+Oq8bVK0s4u cu9TNHH+/SdriGNcwaOTKYdJ3tCQke2ACYREYrVdM6iaBKlhMhEy2oWWa/05Cp+S k5GCdsUWP/ppDK+OGHbxQ5h9xAxjNgF8myh32uMS8e0arG2X8ibnFd+1QYg+pL5s tUby7RMu0p6LsVYL7G0s1nWpaANFn8qcSdIT5AAdEOtCSl1pR973OeMh4xGoYa4+ awnwja7uPHk6DnjPY1yZ =JcuP -----END PGP SIGNATURE-----

1 0

OR port no longer reachable
by Patrick Derwael 22 Jun '15

22 Jun '15

Guys, I've been running a relay since many months without issue (Tor 0.2.6.9 on CentOS 6 fully patched) Since a few weeks, my OR port is no longer reachable without apparent reason (Dirport remains reachable on port 9030) [warn] Your server (xx.xx.xx.xx:9001) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Nothing changed on my network nor on the config... Both Dir & OR port are open and routed properly (Nmap checked from the Net) Selinux & firewalling are disabled, nothing but localhost in /etc/hosts... I'm kinda puzzled... Could you tell me where I should investigate further? Thanks!

1 0

Messages
by Adrian Soh 21 Jun '15

21 Jun '15

Is there a way to send out messages that all tor relays will display to other circuits? Or any mailing system where I could send out to lists and boards?

1 0

Re: [tor-relays] Tor relay is restarting every minute
by teor 19 Jun '15

19 Jun '15

> Date: Fri, 19 Jun 2015 06:42:59 -0500 > From: Michael <mctor(a)biographiks.com> > Jun 19 06:10:34.000 [warn] The communication stream of managed proxy > '/usr/local/bin/obfsproxy' is 'closed'. Most probably the managed > proxy stopped running. This might be a bug of the managed proxy, a bug > of Tor, or a misconfiguration. Please enable logging on your managed > proxy and check the logs for errors. Please provide the obfsproxy logs. You might also find that the tor debug-level logs around the time of the interrupt are useful. > Jun 19 06:11:43.958 [warn] OpenSSL version from headers does not match > the version we're running with. If you get weird crashes, that might > be why. (Compiled with 1000105f: OpenSSL 1.0.1e 11 Feb 2013; running > with 1000106f: OpenSSL 1.0.1f 6 Jan 2014). > Jun 19 06:11:43.958 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) > running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib > 1.2.8. Please run tor with the OpenSSL version it was compiled with, and see if that makes a difference. > Jun 19 06:10:28.722 [notice] We were compiled with headers from > version 2.0.19-stable of Libevent, but we're using a Libevent library > that says it's version 2.0.21-stable. Please try using the same Libevent version tor was compiled with, and seeing if that makes a difference. You might also want to consider the following: tor is shutting down because it's receiving an interrupt signal. Which interrupt is it receiving? What is sending the interrupt signal to tor? Potential options are cron, a memory or server watchdog process, a rogue process, or perhaps a hardware fault. obfsproxy isn't running. Why does the obfsproxy process not start up/not keep running/shut down? Did you do anything else to your server around the time of the move? Upgrade software? Drop it? (I only ask because a hardware fault can trigger certain kinds of interrupts.) Does AT&T block certain types of connections? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

BWAUTH weightings too volatile. . ."twitchy"
by starlight.2015q2＠binnacle.cx 19 Jun '15

19 Jun '15

I'm back to complain further about erratic bandwidth authority behavior, previously [tor-relays] BWauth kookiness https://lists.torproject.org/pipermail/tor-relays/2015-May/007039.html Allowing that BWauths are in a bit of flux, with tor26 replaced by maatuska and moria1 dropping the GuardFraction calculation, the bandwidth calculations evidence wildly erratic swings. Specifically my relay, which is perfectly stable, reliable, fast (9.375 Mbyte/sec) has been assigned a jaggedly random series of consensus weights. https://atlas.torproject.org/#details/4F0DB7E687FC7C0AE55C8F243DA8B0EB27FBF… earlier, fairly sane *gabelmoo Bandwidth=7701 Measured=9960 tor26 Bandwidth=7701 Measured=9340 moria1 Bandwidth=7701 Measured=18000 GuardFraction=66 longclaw Bandwidth=7701 Measured=12800 later, bit high, nutty gablemoo Bandwidth=9375 Measured=17100 moria1 Bandwidth=9375 Measured=77900 GuardFraction=75 *longclaw Bandwidth=9375 Measured=23000 now, sane but undervalued gablemoo Bandwidth=8925 Measured=14900 maatuska Bandwidth=8925 Measured=17200 moria1 Bandwidth=8925 Measured=5330 *longclaw Bandwidth=8925 Measured=7440 moria1 here is downright schizophrenic but other BWauths regularly double and halve the bandwidth value they assign. Graph shows it a more vividly. What the graphs and numbers do not show is that the effective difference between the consensus values of ~7000 and ~23000 is staggering. At the low end of this range the relay shows roughly 2500 active circuits and a average load factor of about 20% of actual bandwidth, while an assignment of 23000 results in almost 8000 circuits and a load factor of more like 50% (both per Blutemagie.de). My point is that BWauths should not be arbitrarily flipping stable, well run relays from the top to the bottom of this steeply sloped sweet-spot of the weighting curve. Perhaps the sweet-spot range has moved over the last couple of years as the price of bandwidth has dropped and faster connections become more prevalent, and this has been overlooked in the algorithm. Regardless, it seems BWauth measurement should be more nuanced in this particular range, such that relays are not slammed constantly between "rather popular" and a "bit boring" irrespective of their actual available capacity. One reason this vexes is that I would like to see how well the relay runs with Address Sanitizer active. ASAN provides obvious benefits w/r/t security, but entails a performance trade-off. With the BWauths throwing darts, eyes closed, when choosing weighting, it's impossible to gauge the performance impact of various adjustments. In the bigger picture view, erratic BWauth weighting can't be adding clarity to the performance, capacity and utilization situation.

1 2

Tor relay is restarting every minute
by Michael 19 Jun '15

19 Jun '15

My Tor relay interrupts and restarts every minute (without my involvement), so it isn't usable by anyone. Nothing new in my obfsproxy log. My relay was running fine until I moved and changed to a new ISP (AT&T). Jun 19 06:10:28.717 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8. Jun 19 06:10:28.717 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jun 19 06:10:28.717 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Jun 19 06:10:28.717 [notice] Read configuration file "/etc/tor/torrc". Jun 19 06:10:28.722 [notice] Based on detected system memory, MaxMemInQueues is set to 2048 MB. You can override this by setting MaxMemInQueues by hand. Jun 19 06:10:28.722 [notice] We were compiled with headers from version 2.0.19-stable of Libevent, but we're using a Libevent library that says it's version 2.0.21-stable. Jun 19 06:10:28.722 [notice] Opening Control listener on 127.0.0.1:9051 Jun 19 06:10:28.723 [notice] Opening Control listener on /var/run/tor/control Jun 19 06:10:28.723 [notice] Opening OR listener on 0.0.0.0:9001 Jun 19 06:10:28.723 [notice] Opening Extended OR listener on 127.0.0.1:0 Jun 19 06:10:28.723 [notice] Extended OR listener listening on port 55831. Jun 19 06:10:28.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Jun 19 06:10:28.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Jun 19 06:10:28.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Jun 19 06:10:29.000 [notice] Your Tor server's identity key fingerprint is [REDACTED] Jun 19 06:10:29.000 [notice] Your Tor bridge's hashed identity key fingerprint is [REDACTED] Jun 19 06:10:29.000 [notice] Bootstrapped 0%: Starting Jun 19 06:10:33.000 [notice] Bootstrapped 80%: Connecting to the Tor network Jun 19 06:10:34.000 [warn] The communication stream of managed proxy '/usr/local/bin/obfsproxy' is 'closed'. Most probably the managed proxy stopped running. This might be a bug of the managed proxy, a bug of Tor, or a misconfiguration. Please enable logging on your managed proxy and check the logs for errors. Jun 19 06:10:34.000 [notice] Failed to terminate process with PID '13164' ('Success'). Jun 19 06:10:34.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Jun 19 06:10:35.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Jun 19 06:10:36.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Jun 19 06:10:36.000 [notice] Bootstrapped 100%: Done Jun 19 06:11:13.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Jun 19 06:11:43.000 [notice] Clean shutdown finished. Exiting. Jun 19 06:11:43.000 [notice] Tor 0.2.6.9 (git-145b2587d1269af4) opening log file. Jun 19 06:11:43.958 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1000105f: OpenSSL 1.0.1e 11 Feb 2013; running with 1000106f: OpenSSL 1.0.1f 6 Jan 2014). Jun 19 06:11:43.958 [notice] Tor v0.2.6.9 (git-145b2587d1269af4) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1f and Zlib 1.2.8.

1 0

Installing Tor-ramdisk
by eldorado 17 Jun '15

17 Jun '15

Installing Tor-ramdisk I have question about installing Tor-ramdisk on Dedicated server in hetzner datacenter. I want install iso file without using USB and DVD . i followed this link[1] . My iso file is in my VPS that LARA could access to iso via SAMBA/CIFS . LARA shows me the iso file attached but after running KVM and press F11 the boot menu have my hard disks not "PepperC Virtual Disc 1 0.01" in boot menu . How i can mount Tor-ramdisk with KVM . i don't want pay € 21.01 for using USB stick/DVD . [1] http://wiki.hetzner.de/index.php/LARA/en

1 0

Questions about GUI monitor
by nks nks 16 Jun '15

16 Jun '15

Dear Sir/Madam: My system is Debian 32bit, Tor non-exit bridge. 1. For Debian, is there any pure Tor service monitoring and analyzing software for the local machine (not the entire Tor network), with/without a GUI ? 2. Does "Vidalia" really end developing? May I ask why? May I install the "Vidalia" which is still could be found in the Debian apt system? 3. https://www.torproject.org/projects/projects.html.en "orlib" the link is dead. 4. About "Tor2web", are there any clearer figures and docs which could explain the security differences between "Tor" and "Tow2web" ? Especially for the client. Thank you.

4 4