Re: [tor-relays] outgooing UDP flooding on middle relay
> On 1 Aug 2016, at 22:47, Tristan wrote: > > How can a Tor relay flood UDP? I thought everything was TCP? Exits can flood an under-resourced DNS server quite easily. That's why we recommend a local DNS resolver / cache. But this particular relay is not an exit. Perhaps it was a (D)DoS attack, and the provider is confused about where it was coming from? Perhaps the server was used in a (D)DoS attack? (Does it serve DNS? Does that DNS have large records?) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmmp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] outgooing UDP flooding on middle relay
> On 1 Aug 2016, at 23:08, Markus Koch wrote: > > Looks like DOS/DDOS.Is it even possible to DDOS over tor? It's possible to (D)DOS any server using ping (or DNS, or any other UDP responder). All an attacker needs is the server's IP address, which is publicly available in the Tor consensus. Then they can attack the relay from the Internet. There's no need to use Tor to tunnel the (D)DOS. In this case, Tor doesn't tunnel UDP, so it's unlikely to be the culprit. Tim > > > 2016-08-01 15:04 GMT+02:00 pa011 : >> yes about the same - sorry for the page brake dont get it solved in my >> thunderbird >> >> h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) h rx (KiB) >> tx (KiB) >> 23 6.559.929 6.748.21507 4.697.285 4.845.89315 35.106.193 >> 35.833.114 >> 00 5.129.384 5.289.45608 12.317.567 12.605.72616 0 >> 0 >> 01 3.709.181 3.843.98809 14.913.172 15.278.07917 0 >> 0 >> 02 4.405.017 4.574.74510 22.218.874 22.738.50818102.138 >> 144.732 >> 03 4.670.091 4.817.78511 25.700.571 26.306.50519275.999 >> 340.633 >> 04 4.711.807 4.853.92112 32.840.796 33.571.99620271.278 >> 382.087 >> 05 4.269.354 4.408.41713 32.910.527 33.637.09221263.147 >> 383.444 >> 06 5.279.142 5.443.89014 40.052.678 40.824.13822176.040 >> 258.865 >> >> >> Am 01.08.2016 um 14:51 schrieb Markus Koch: >>> In and outgoing traffic is the same size? >>> >>> >>> >>> 2016-08-01 14:44 GMT+02:00 pa011 : >>>> The ISP didn’t mention - I would have to ask. >>>> >>>> What I saw was that the traffic was up about linear from usually 30Mbits >>>> to above 100 Mbits over about 6 hours, bringing the CPU to 100% and >>>> dropping. >>>> >>>> >>>> Am 01.08.2016 um 14:36 schrieb Markus Koch: >>>>> How many packets per second? >>>>> >>>>> Markus >>>>> >>>>> >>>>> >>>>> 2016-08-01 14:28 GMT+02:00 pa011 : >>>>>> Hello, >>>>>> >>>>>> one of my middle relays got auto limited by the ISP because of >>>>>> "outgooing UDP flooding ". >>>>>> >>>>>> The VPS is pure debian8, fail2ban, pub key and nothing else installed - >>>>>> so I highly doubt the give reason for the traffic limitation. >>>>>> Also I cant find anything in the log files. >>>>>> >>>>>> Anybody having experience with such an issue? >>>>>> What to check for please? >>>>>> >>>>>> Paul >>>>>> >>>>>> ___ >>>>>> tor-relays mailing list >>>>>> tor-relays@lists.torproject.org >>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>>>>> >>>>> ___ >>>>> tor-relays mailing list >>>>> tor-relays@lists.torproject.org >>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>>>> >>>> ___ >>>> tor-relays mailing list >>>> tor-relays@lists.torproject.org >>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> ___ >>> tor-relays mailing list >>> tor-relays@lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmmp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] is explicit DirPort needed anymore under Tor 0.2.8.6?
> On 3 Aug 2016, at 10:13, Green Dream wrote: > > The release notes for Tor 0.2.8.6 have this tidbit about the DirPort: > > "Previously only relays that explicitly opened a directory port > (DirPort) accepted directory requests from clients. Now all > relays, with and without a DirPort, accept and serve tunneled > directory requests that they receive through their ORPort. You can > disable this behavior using the new DirCache option. Closes > ticket 12538." > > With this new behavior, is there any reason to keep an open DirPort on our > relays? If I just use an ORPort on 443 (or another reachable TCP port) is > this sufficient? Might it make sense to leave the DirPort up for a while for > legacy clients? Will (up-to-date) authorities have any concerns with a > ORPort-only relay? Yes, it is needed. In brief: please keep an IPv4 DirPort on your relay, so that: * older clients and authorities can use the IPv4 DirPort - they may take a year or two to upgrade, * other relays can fetch directory documents from your relay, and * your relay can be selected as a fallback directory mirror. Here are the details: Clients on 0.2.7.6 and earlier still use the IPv4 DirPort. (Tor Browser is still 0.2.7.6, and apps in general may take some time to upgrade.) Authorities on0.2.7.6 and earlier will only assign the HSDir flag to relays with an IPv4 DirPort. (Authorities may take some time to upgrade, because running different versions increases authority diversity.) Fallback directory mirrors must have a DirPort, and we'd only think about changing that when: * all recommended relay versions are 0.2.8 and later, and * relays no longer fetch documents using the DirPort (so maybe never). All relays running any Tor version will continue to use the IPv4 DirPort to fetch consensuses from other relays. So we haven't obsoleted the IPv4 DirPort yet. We've just made sure that clients fetch directory documents over an encrypted channel. (The IPv6 DirPort was briefly introduced in the 0.2.8 alpha series, and then obsoleted in a subsequent alpha, because only clients use IPv6 for directory fetches, and clients only use the IPv6 ORPort. There's no way to advertise an IPv6 DirPort, and no reason for a relay to have one.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmmp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] is explicit DirPort needed anymore under Tor 0.2.8.6?
> On 3 Aug 2016, at 10:35, I wrote: > > Does that mean it is pointless to set-up IPV6 on all relays? IPv6 relays are still very useful for Tor clients. I was only talking about IPv6 DirPorts being obsolete. An IPv6 ORPort allows clients that use IPv6 to connect to the Tor network. An IPv6 Exit allows clients to access sites on IPv6. Some clients are IPv6-only, others can circumvent network blocks using IPv6 (both blocked guards and blocked websites) and others simply prefer IPv6 because it's faster or more reliable on their networks. Please enable IPv6 on your relay, if you can. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmmp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] is explicit DirPort needed anymore under Tor 0.2.8.6?
> On 3 Aug 2016, at 10:29, teor wrote: > > Clients on 0.2.7.6 and earlier still use the IPv4 DirPort. > (Tor Browser is still 0.2.7.6, and apps in general may take some time to > upgrade.) > > Authorities on0.2.7.6 and earlier will only assign the HSDir flag to relays > with an IPv4 DirPort. > (Authorities may take some time to upgrade, because running different > versions increases authority diversity.) For the record, even though the man page entry for HidServDirectoryV2 says the DirPort is not required to be a HSDir, authorities on 0.2.7 and earlier still check for it before assigning the HSDir flag. Authorities on 0.2.8 and later behave in a way that's consistent with HidServDirectoryV2, assigning the HSDir flag to any relay that wants to be a HSDir, and either supports being a directory cache, or has a DirPort. HidServDirectoryV2 0|1 When this option is set, Tor accepts and serves v2 hidden service descriptors. Setting DirPort is not required for this, because clients connect via the ORPort by default. (Default: 1) > Fallback directory mirrors must have a DirPort, and we'd only think about > changing that when: > * all recommended relay versions are 0.2.8 and later, and > * relays no longer fetch documents using the DirPort (so maybe never). > > All relays running any Tor version will continue to use the IPv4 DirPort to > fetch consensuses from other relays. > > So we haven't obsoleted the IPv4 DirPort yet. We've just made sure that > clients fetch directory documents over an encrypted channel. Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] running a relay on a pi/pi2 and it stopped working after upgrading to 0.2.8.6/0.2.8.6-2 ? read this (bugfix)
> On 6 Aug 2016, at 06:24, Peter Palfrader wrote: > > On Fri, 05 Aug 2016, Jens Kubieziel wrote: > >> * Hack-Tic schrieb am 2016-08-05 um 21:19 Uhr: >>> edit /lib/systemd/system/tor@default.service and change TimeoutStartSec= >> >> Please don't write in /lib. Better create a new file >> /etc/systemd/system/tor@default@default.service.d/override.conf >> and add your change there. When you update Tor at some point, your >> settings won't be overwritten with this method. > > I just changed git to raise it to 300 too. So maybe this once changing > /lib was actually ok :) Hi weasel, It looks like you changed it in https://gitweb.torproject.org/debian/tor.git/tree/debian/systemd/tor@.service but not in: https://gitweb.torproject.org/debian/tor.git/tree/debian/systemd/tor@default.service Is this intentional? Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] High speed Tor relay advice
> On 15 Aug 2016, at 06:54, Green Dream wrote: > > - You should install ntp make sure your clock is synced. Alternately, run ntpdate via cron every few hours, to avoid running an unnecessary network service. (Recent security issues in ntp remain unpatched in some distributions.) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Local DNS on Exit logs failed user queries
Hi,
When I set up a Tor Exit, I set up a local resolver (BIND) as a cache.
Today, I was monitoring the syslog, and I noticed that BIND logs DNS names when
resolution fails.
(I have since removed these entries from the logs.)
One way to prevent this is to disable logging on BIND entirely:
logging { category default { null; }; };
Another is to isolate the categories that log DNS names, and disable them
individually:
logging {
// these categories log DNS names
category dnssec { null; };
category edns-disabled { null; };
category lame-servers { null; };
category resolver { null; };
category security { null; };
// also ignore uncategorised log messages
category unmatched { null; };
};
I've updated the Tor wiki page on BIND with this configuration:
https://trac.torproject.org/projects/tor/wiki/doc/BIND
Does anyone know how to work out all the BIND categories that log DNS names?
(All of the documentation I found online was helping people log *every* DNS
query.)
Or is it safer just to log a few essential categories?
(Can anyone recommend any?)
Has anyone checked if the logs on other resolvers (like unbound) have the same
issue?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guard Flag without stable Flag
> On 18 Aug 2016, at 07:10, tmbates12 wrote: > > My relatively new Tor relay has somehow managed to get a Guard flag without > having the Stable flag, I'm not sure if this is supposed to happen though..? > > https://atlas.torproject.org/#details/ABF5C38A93F2D7E77A226871AB0ADB052279B48F Looks like the issue is fixed now - no Guard flag. (Possibly because you restarted it?) I've also seen some relays get the Stable flag much earlier than I expected (after 4 days). I think the flags might change a bit more than they used to, with only 7 directory authorities up. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Problems with isp's onestrike policy
> On 18 Aug 2016, at 08:23, majacobs wrote: > >>> >>> Cut off three times because of worm spread alert. I ran an exit node for >>> just a couple of weeks. First came in while i was away on holiday . Could >>> not connect to my vpn but noticed that one of my consumer routers send a >>> reboot message around the first day of my vacation and didn't think about >>> it again , that is till I got home and really started to run the node . >>> Node 0d0a was running fine and well when the net was cut of for a second >>> time just a few days before the third and last time. I contacted support , >>> sought advice I was told to better run a relay. >>> No way! I thought! >>> To cut a story short, I know run in bridged mode (obsfs4proxy) but I am >>> looking for solutions as to how Tor can help not seeing exit-nodes coming >>> and going because of worm spreading? Tor doesn't discriminate based on traffic, so this is a hard problem. Over the long term, encourage destinations (or server providers) to block particular problematic traffic, rather than entire IP addresses or servers. Over the short term, block the ports that the worm uses to spread. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Local DNS on Exit logs failed user queries
> On 18 Aug 2016, at 15:46, Andrew Deason wrote: > > On Wed, 17 Aug 2016 12:23:15 +1000 > teor wrote: > >> Has anyone checked if the logs on other resolvers (like unbound) have >> the same issue? > > On my exit running unbound, I haven't seen any messages from unbound > beyond the startup/shutdown messages for the past several weeks, but > maybe I just haven't gotten the right errors. I didn't see anything in > the code that looked like logging requested names, but I only took a > quick glance. The default verbosity seems kinda low, but of course > that's no guarantee. > > What kind of resolution errors are you talking about? Plain NXDOMAIN > failures, failing to reach nameservers, DNSSEC failed signatures, or > anything else? I'm not sure if NXDOMAIN was showing up in the BIND logs by default or not. But the rest were, as were reducing packet sizes to 512 bytes (BIND's edns-disabled). > Do you know of any domains handy that could be used to > test the relevant failure cases? (e.g. a dns entry that points to an > unreachable server, or results in an invalid DNSSEC response, etc.) That > would make it easy for exit operators to test what happens and take out > some guesswork. I don't have a record of those domains any more, and I can't turn logging back on. However, any domain which doesn't have name servers, or has broken DNSSEC, was being logged by default by BIND. I was seeing a few domains logged every few minutes with BIND's default logging, on an exit running at 5 - 10 MBytes per second. So if you're not seeing them in a day of log entries, you're probably safe. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Problems with isp's onestrike policy
> On 18 Aug 2016, at 18:24, majacobs wrote: > > Block ports that spread worm(like) virii would also mean closing ports 80 and > 443. I am afraid that is no option Sadly, there's not much we can do then. Tor relays don't inspect traffic in general - there are legal and ethical consequences to traffic selection. Tim > > the white rider > (Het leuke van ... is > > > > the white rider > (Het leuke van ... is > On 18 aug. 2016, at 01:30, teor wrote: > >> >>> On 18 Aug 2016, at 08:23, majacobs wrote: >>> >>>>> >>>>> Cut off three times because of worm spread alert. I ran an exit node for >>>>> just a couple of weeks. First came in while i was away on holiday . Could >>>>> not connect to my vpn but noticed that one of my consumer routers send a >>>>> reboot message around the first day of my vacation and didn't think about >>>>> it again , that is till I got home and really started to run the node . >>>>> Node 0d0a was running fine and well when the net was cut of for a second >>>>> time just a few days before the third and last time. I contacted support >>>>> , sought advice I was told to better run a relay. >>>>> No way! I thought! >>>>> To cut a story short, I know run in bridged mode (obsfs4proxy) but I am >>>>> looking for solutions as to how Tor can help not seeing exit-nodes >>>>> coming and going because of worm spreading? >> >> Tor doesn't discriminate based on traffic, so this is a hard problem. >> >> Over the long term, encourage destinations (or server providers) to block >> particular problematic traffic, rather than entire IP addresses or servers. >> >> Over the short term, block the ports that the worm uses to spread. >> >> Tim >> >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >> ricochet:ekmygaiu4rzgsk6n >> xmpp: teor at torproject dot org >> >> >> >> >> >> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay vs exit node
> On 19 Aug 2016, at 06:50, majacobs wrote: > > Is my understanding correct that is NOT possible to run an accesspoint that > connects to tor running a relay instead of an exit-node? > I am able to torify programs running on the system , but need the acces point > to be torified for some clients that need to go through tor. I am aware that > this is possible if I run an exit node but my isp is seeing malware traffic > every week or do if I do so… It's entirely ok for Tor clients to send traffic to tor exits on the other side of the world. It's also ok to set up a bridge for your local tor clients, and have them access the tor network through that bridge. There's no need to run an exit relay locally. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Atlas
> On 30 Aug 2016, at 03:00, John Ricketts wrote: > > Hello, > > Does anyone know how often the Whois database is updated for atlas? The AS > number listed for my relay is reporting the incorrect information. > > John Hi John, We use the MaxMind GeoIP database, so upstream changes will automatically be included in Atlas. (I'm not sure what our update schedule is for Atlas.) We're working on getting better AS information here: https://trac.torproject.org/projects/tor/ticket/19437 Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new relay package for Ubuntu 16.04+
> On 31 Aug 2016, at 15:20, Chad MILLER wrote: > > But it can never look in your ~/.gnupg/ dir or grab your scanner or wipe your > yubikey or turn on your camera or whatever, as another program, rogue or > compromised, could do. None of that even seems to exist. If it shares physical RAM with other processes or VMs, it can modify their RAM, under certain conditions: https://www.schneier.com/blog/archives/2016/08/powerful_bit-fl.html Unfortunately, VMs and similar isolation techniques aren't great at preventing hardware-based side-channels. But in most cases, for most threat models, yes, it's quite secure. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Useful metrics for relay operators
> On 1 Sep 2016, at 02:51, Alison wrote: > > I'd like to hear directly from relay operators about what kinds of > metrics they might like to see involved in a project like this. Have you > achieved milestones with your relays that you wished Tor Project would > have given you some recognition for? Have there been specific times > you'd wished for a checkin email, like the one Roger sent (eg 3 months > after starting a new relay)? Anything else that you think Onionoo could > measure that would be valuable for you as an operator? We already use Onionoo to identify and choose fallback directory mirrors. Every release, we identify operators of long-term stable relays, and ask them if they are able to be a fallback directory mirror. Then we choose a slightly different set of fallbacks for each release. These fallbacks help new clients contact the Tor network when the directory authorities are blocked. While it's not a t-shirt, it does recognise an important contribution to the network. And we do hard-code the relay details in the Tor source code. When we do the 0.2.9 fallback update, I'll make sure I keep others on the Tor team in the loop, so that relay operators know who to contact if I'm away. (Oh, and please let us know if you're getting *too much* email!) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New tor relay not showing up on Atlas
uses > ## 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 *:* > > ## 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 > > # more fingerprint > greedygertie 27376BCE3867E999330C53981FA0A226870F042F > > greedygertie is not showing up on atlas > > > --- Marina > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Useful metrics for relay operators
> On 1 Sep 2016, at 13:36, I wrote: > > Did someone mention t-shirts? > > > When is the last time anyone got a t-shirt? I'm pretty sure Jon has been sending them out on a regular basis. (We're trying to automate the process a bit more.) If you want one, please feel free to get in touch with him, I've CC'd him on this email. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] total relay bandwidth
> On 3 Sep 2016, at 05:55, grarpamp wrote: > > On Fri, Sep 2, 2016 at 7:30 AM, Michael Armbruster wrote: >> On 2016-09-02 at 13:18, jensm1 wrote: >>> which shows that the advertised relay bandwidth in the whole network is >>> more than double the actually used bandwidth. While it's certainly nice >>> to have a bit of breathing space to absorb load spikes, I'm wondering, > >> it's always good to have even more relays or exit nodes, as more "hop >> points" for connections means more diversity throughout the network > > Once a net reaches adequate bandwidth capacity, adding more > nodes can do a few things among others... > Good: > - Gives operators deployment experience till their bw is needed, at $cost. > - More non-evil relays gives better odds of building a non-evil path, but tor > weight's things so not exactly. > - May add some capacity for directory operations etc > Bad: > - Yields rather unused nodes making it easier for passive > observer to see you tack up and use a path through them, > especially if you're crafting paths. > > One key here is probably that we don't have a good idea as to the > quantity of evil nodes, or the hard interest and real capabilities of PA's. > > To make the call you'd need that, and perf metrics of your net under > different ratios of advertised:consumed:nodecount, and min/avg/max/stddev > of idle/random/full paths, to find any sweet spots / ranges. > > Also considerations of impact adding nodes of less bandwidth or > more latency than average, versus a campaign to fund replace them. > > At 42% util by one metric, it may be money and time better spent > elsewhere, even on better qualifying the default 'more nodes good' idea. There are also latency and contention considerations: an network that runs at 40% capacity has much better latency properties than one at 90% capacity. Also, in the Tor network, as soon as cells are dropped due to any relay being over capacity, this adds a significant delay, because of how Tor retransmits along the entire path, not just the busy relay's hop. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guard vs Exit Bandwidth
> On 3 Sep 2016, at 03:53, Tristan wrote: > > But hidden service traffic makes up about 0.01% of Tor traffic. 0.9 Gbps / 75 Gbps = 1.2% > Total is about 75Gb/s: http://rougmnvswfsmd4dq.onion/bandwidth.html > > Hidden services are about 900Mb/s: > http://rougmnvswfsmd4dq.onion/hidserv-rend-relayed-cells.html Hidden Service traffic goes through two Guards and no Exits, Exit traffic goes through one of each. That said, the most likely explanation isL * almost every Exit has the Guard flag, but only a proportion of Guards have the Exit flag, and * the bandwidth allocation algorithms give relays with Exit and Guard flags all Exit and no Guard traffic, because Exits are rarer than Guards. Tim > > On Fri, Sep 2, 2016 at 12:51 PM, Green Dream wrote: > Don't forget that some traffic enters through guards but lands on > hidden services, skipping Exits. > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > -- > Finding information, passing it along. ～SuperSluether > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why can't I see more traffic? (is my banana too weak?)
> On 4 Sep 2016, at 04:35, Farid Joubbi wrote: > > It seems as if Cpu1 is almost idle most of the time. > Cpu0 is somewhere between 5 and 20. > This is a rather high snapshot: > > %Cpu0 : 17.2 us, 2.0 sy, 0.0 ni, 79.5 id, 0.0 wa, 0.0 hi, 1.3 si, 0.0 > st > %Cpu1 : 2.4 us, 0.3 sy, 0.0 ni, 97.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 > st > > I have had the guard flag before. > Maybe I lost it since I rebooted twice and changed ISP a bit more than a week > ago. > > The IP address does not change unless I reboot or release the current address > manually > > I used to have 250Mbit/s downstream and 10Mbit/s up with my old ISP. > > How does the algorithm that checks the bandwidth work? Your relay reports a bandwidth based on the amount of traffic it has sustained in any 10 second period over the past day. You can also set a maximum advertised bandwidth on your relay. (Don't do this if you're trying to pick up more traffic.) Five bandwidth authorities measure each relay each week, and report how fast it is. Each of these factors can restrict the amount of bandwidth that the network assigns to your relay. Here's one way of testing what your relay is capable of: Run a Tor client as close to your relay as possible: tor DataDirectory /tmp/tor.$$ SOCKSPort [IPv4:]1 EntryNodes your-relay-name Then download a large file using port 1 as a socks proxy. That will give you some idea of how much traffic your relay can sustain, but it's worth noting that each client is limited to about 1 Mbps (I think - I can't find the manual page entry). Tim > Does anyone else reading this run a Banana Pro, Raspberry or similar hardware > with better results than me? > > Regards, > Farid > > > From: Roman Mamedov > Sent: 03 September 2016 17:14 > To: Aeris > Cc: Farid Joubbi; tor-relays@lists.torproject.org > Subject: Re: [tor-relays] Why can't I see more traffic? (is my banana too > weak?) > > On Sat, 03 Sep 2016 16:53:25 +0200 > Aeris wrote: > >>> Could it be that it is due to the quite slow hardware, even though I know >>> that it is able to push more traffic? >> >> Yep, surely. >> >> You currently push 3Mbps of traffic, which is correct for this kind of >> hardware. >> All "cheap" hardware (raspi, banana, olimex, pine…) suffer of the fact they >> don’t have crypto hardware acceleration and do software encryption. And so is >> very slow (10-100× factor) even compared to low end amd64 CPU with AES-NI >> extension. > > According to 'openssl speed aes-128-cbc' the Allwinner A20 CPU in Banana Pro > is > capable of about 25 MBytes/sec in AES performance. While that won't translate > 1:1 into Tor performance, as Farid noted in his case the CPU isn't being a > bottleneck, with only 10-20% CPU load observed. > > @Farid, > >> According to top the CPU hovers around 10-20% most of the time. > > I wonder is it 20% across both cores, which could be 40% of one core (since > Tor is not multithreaded enough), and at least somewhat closer to not being > practically idle. Can you launch 'top' and press '1' there to check? > > Also seems unclear why it didn't get the guard flag for so long, does your > public IP address change from time to time? Or do you turn the relay off and > on for whatever reason. > > -- > With respect, > Roman > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor-relays Digest, Vol 68, Issue 12
> Am 04.09.2016 um 06:52 schrieb daniel boone:
>> Ok, 1st on to MATT
>> "I missed your SOCKS question."
>> Well that doesnt matter because I took you advice on the first reply you
>> sent explaing things so I commented all again as suggested. So all is well
>> now on that part of the torrc file.
Disabling SOCKSPort on a relay is a good idea.
You're not really anonymous if you use your relay as a client - its IP address
is public, and so is its uptime/downtime.
And there are statistical ways of matching relay and client traffic hiccups.
>> What I did do was kept the ORPort at 9001. I tried 443 but in the terminal
>> it showed me it could not bind so it would not work.
>> As for the question on "hope this helps" you bet and well appricated. Thank
>> you.
Likely your tor process is running as a non-root user (this is good) without
the CAP_NET_BIND_SERVICE capability, or your OS equivalent.
And 9001 is a fine port, there's no need to change it to 443.
>> {Sep 04 00:11:56.000 [notice] Your network connection speed appears to have
>> changed. Resetting timeout to 60s after 18 timeouts and 104 buildtimes.}
>>
>> > using anything to set it back. Right with the MB too.}
> On 4 Sep 2016, at 22:17, jensm1 wrote:
>
> Nice to see your relay is running now! Though I must admit that I have no
> idea what these "connection speed" notices mean. Probably nothing important,
> or they'd be warnings.
Your network connections are timing out on a regular basis.
This isn't great for a relay, it means that clients using your relay will be
slowed down.
This could be your ISP having poor connectivity, or actively closing long-lived
connections.
Or perhaps other traffic on your connection competes with the Tor traffic, and
causes it to time out?
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Useful metrics for relay operators
> On 4 Sep 2016, at 22:55, pa011 wrote: > > > > Am 01.09.2016 um 05:39 schrieb teor: >> >>> On 1 Sep 2016, at 13:36, I wrote: >>> >>> Did someone mention t-shirts? >>> >>> >>> When is the last time anyone got a t-shirt? >> >> I'm pretty sure Jon has been sending them out on a regular basis. >> (We're trying to automate the process a bit more.) >> >> If you want one, please feel free to get in touch with him, I've CC'd him on >> this email. >> >> Tim >> >> Tim Wilson-Brown (teor) > > Hi Tim, > > if not changed the person in charge should be Juris not Jon - a little bit > similar :-) Jon is sending out T-Shirts from the Tor office in Seattle. Juris was sending them out from torservers.net in Berlin. I believe there's been a transition recently, after Jon was employed to help out with administrative tasks like t-shirts. > I would bet nobody got a T-shirt this year - otherwise there wouldn’t be a > moaning every now an then, especially from Robert. > > I, waiting for a shirt as well, was offering my help on June, 13th in this > group - nobody ever came back on that. I'm sorry about that. There has been a transition between different people. Also, our automated t-shirt email system Tor Weather wasn't working correctly, and we're doing it manually for the moment. I've CC'd Jon on this email as well. You can get in touch with him to arrange a t-shirt. Tim > Rgds > > Paul > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-relays-universities] Legal issues relevant to UK
> * Duncan Guthrie schrieb am 2016-09-01 um 01:09 Uhr: >> I'm hoping to run a Tor relay here at a University in the UK. >> Is there anyone here who might have some experience with this in the >> past? I have been researching legal issues but information is >> extremely sparse (mostly relating to the DMCA). All I can really work >> out is that the issues relating to ISPs apply more generally, and more >> strictly to a Tor exit node operator. >> What protections, if any, exist here in the UK for a Tor exit node >> operator? > On 5 Sep 2016, at 05:08, Jens Kubieziel wrote: > > X-Post from tor-relays-universities@ > > I ran some relays at Geman universities in the past. I guess my > experiences won't help here. Maybe someone on tor-relays has experience > with running a relay at an UK university, so I send this mail to > tor-relays@ too. I can't help with UK-specific legislation, but if it hasn't diverged too far from Australia, the answer is likely the same: "there are some legal protections for carriage services, but the protections applying to an open proxy operator have not been testing in court yet". (Of course, you should get UK-specific legal advice on that.) One other option is to try setting up a non-exit relay first, which is what we've done recently in Australia. Another option is to have a talk with your local police (or the relevant police group dealing with Internet activities), and let them know about Tor and your Exit relay. And let them know you don't keep any logs, and Tor can't identify the end user anyway by design. That keeps them informed, and gives them someone to contact if there are ever any concerns about your relay. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor and Diplomatic Immunity
> On 5 Sep 2016, at 11:31, Mirimir wrote: > > On 09/04/2016 09:11 AM, Kenneth Freeman wrote: >> Do embassies and consulates run Tor nodes? AFAIK no studies have been >> done on this, but diplomatic immunity and Tor would seem to be a match >> made in Heaven. > > Well, they need uplinks, right? I doubt that diplomatic immunity forces > ISPs to serve them. Private routing is possible, of course, but is > probably too expensive for most. As wikileaks discovered, they definitely use Tor clients... > >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor bridge and obfs4proxy
> On 5 Sep 2016, at 11:49, Arisbe wrote: > > I need someone's bridge experience. I had an HD crash and lost one of my Tor > bridges. So, I'm rebuilding on a leased VPS. First I tried with Debian 8 > and then with ubuntu 16.04 when Debian didn't work. With both operating > systems I get a warning message when I start Tor. Tor is the latest version > as is obfs4proxy: > > Sep 04 13:39:41.641 [warn] Strange ServerTransportPlugin type 'obfs4' > Sep 04 13:39:41.641 [warn] Failed to parse/validate config: Invalid server > transport line. See logs for details. > > There are no log entries. Apparently Tor starts without the proxy. I have > configured torrc as follows: > > ServerTransportPlugin obfs3 obfs4 exec /usr/bin/obfs4proxy > > ExtORPort auto > > /usr/bin/ does contain the obfs4proxy file. > > Does anyone know my problem? Is there a 'tell-all' explanation of obfs4proxy? From the tor manual page: ServerTransportPlugin transport exec path-to-binary [options] The Tor relay launches the pluggable transport proxy in path-to-binary using options as its command-line options, and expects to receive proxied client traffic from it. You're only allowed one space-separated transport name for "transport", you have two: "obfs3" and "obfs4". Tim > > Thanks, Arisbe > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] write-history for exit relays only?
> On 7 Sep 2016, at 06:36, Philipp Winter wrote: > > On Tue, Sep 06, 2016 at 12:10:06PM -0400, Aaron Johnson wrote: >>> I suspect that one could approximate this number by accounting for the >>> probability of all exits being selected as guard, middle, and exit, but >>> I would prefer a simpler and more reliable approach. >> >> This doesn’t seem like a bad approximation to me, given that for as >> long as I have been aware, exits have had zero probability of being >> chosen in any position other than the exit position. > > Thanks, Aaron. You are right. Section 3.8.3 in dir-spec has the answer: > <https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2611> > > I just proved this to myself with the small attached Python script. > Currently, exit bandwidth is the network's scarce resource, which is not > surprising since running an exit is riskier than running a guard or a > middle. Since exits are scarce, the bandwidth weights in case 3, > subcase A are currently in place: > <https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2726> > > In that case, the specification hard-codes the probability of an exit > taking on a non-exit role (Wgd, Wmd, and Wme) to 0. > It's also worth noting that Exits will serve directory documents and hidden service descriptors, and act as introduction and rendezvous points, so your estimates could be a few percentage points off. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor-relays Digest, Vol 68, Issue 22
> On 7 Sep 2016, at 22:01, daniel boone wrote: > > > tks John. I am not interested in sticking my neck out like that so I hope the > project moves forward. I just don't understank why the top 10 relays never > show anything like that. Likely because they run out of a datacentre at a large provider, rather than someone's home internet connection. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to include files into torrc?
> On 10 Sep 2016, at 04:50, Ralph Seichter wrote: > > On 09.09.16 20:37, tor-ad...@torland.is wrote: > >> There is a ticket that handles this feature: >> https://trac.torproject.org/projects/tor/ticket/1922 > > Thank you for pointing me to the issue tracker, and thanks also to the > other list members who replied. I was pretty certain that I was not the > first person to ask for such a feature. > > -Ralph If you're trying to apply the same policies across a number of relays on the same box, --defaults-torrc FILE can be used to provide default settings, and then each torrc can contain only the unique settings. But on some OSs / distributions (like Debian), the defaults torrc file is in /usr/share/tor, not /etc/tor. So if you want to modify it permanently, you'll need to protect that file from your package manager (using something like dpkg-divert), or change the --defaults-torrc path in your service manager (and if you're on Debian, that file is in /lib/systemd/system, and so you'll need to do dpkg-divert on it). Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Moving multiple instances to another VPS
> On 12 Sep 2016, at 06:06, s7r wrote: > > Hello, > > Thanks for running exits! > > Pay attention that each instance has its own datadirectory, this means > you need to have multiple 'keys' subdirectories depending on the number > of your instances. Usually /var/lib/tor should contain some subfolders > like 1, 2 or instance1, instance2, whatever and each containing another > subfolder with the related keys for each instance. In Debian, using tor-instance-create and systemd, there is a separate directory, /var/lib/tor-instances You'll need to copy both /var/lib/tor and /var/lib/tor-instances to preserve the keys, and /etc/tor to preserve the configs. That said, please consider rotating keys when you move (that is, only copying /etc/tor). If your old relay or those keys were ever compromised, you'll have a fresh start. And even if it wasn't, some of your network reputation will be reset when you move IP addresses anyway. Tim > > So you need to make sure you backup and move the keys for all instances. > There's no problem if you copy the entire directory, as long as the keys > are there, Tor will just overwrite the expired cached/consensus data. > > On 9/11/2016 4:08 PM, pa011 wrote: >> I have to move a multiple instances Exit from one VPS to another. >> >> Apart from creating the same instances on the new machine with >> **tor-instance-create** I would then just copy the whole directory >> /var/lib/tor/keys to the new VPS - or should I copy all /var/lib/tor/ to not >> miss anything from the original one? >> >> Am I miss anything else? >> >> Thanks >> >> Paul >> >> > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Moving multiple instances to another VPS
> On 12 Sep 2016, at 22:41, pa011 wrote: > > Thank you both. > > @Tim: You would kind of argue, that the advantage of carrying the old keys to > the new machine is not that important (to keep old level of traffic from > start) and that it might be even better to start from scratch? There is some value in maintaining the same level of traffic. But there will be an adjustment to your consensus weight anyway. In fact, if your new provider is too different (particularly less connected or slower), keeping your old weight would be a disadvantage for the network. There is also significant value to making a fresh start: new SSH keys and new relay keys mean that even if your old provider has a backup, or your old relay was compromised, or you have a backup of your keys, it's not much use to anyone. Particularly on an exit, your traffic will recover fairly quickly. It's completely up to you - I just wanted to describe the security advantages of a fresh start, versus the traffic advantages (or disadvantages) of keeping the same relay keys. Tim > > Paul > > > Am 12.09.2016 um 03:53 schrieb teor: > >> In Debian, using tor-instance-create and systemd, there is a separate >> directory, /var/lib/tor-instances >> You'll need to copy both /var/lib/tor and /var/lib/tor-instances to preserve >> the keys, and /etc/tor to preserve the configs. >> >> That said, please consider rotating keys when you move (that is, only >> copying /etc/tor). >> >> If your old relay or those keys were ever compromised, you'll have a fresh >> start. >> And even if it wasn't, some of your network reputation will be reset when >> you move IP addresses anyway. >> >> Tim > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor path selection upon failure
> On 13 Sep 2016, at 14:02, Liu, Zhuotao wrote: > > Hi Folks, Hi, Please don't cross post to multiple lists, it makes it hard for people to follow all the responses. Can I suggest that everyone replies to tor-dev, as it's the list for Tor development, feature, and issue discussion. (The other list you used is for Tor relay operators to discuss relay operation and configuration.) Tim > > There have been some technical reports about how to deal with the problem > when a botnet uses Tor as its primary C&C channel. In this case, the CPU of > some relays is exhausted, causing circuit creation failure. > > I am wondering currently how a client reacts when its circuit creation fails? > Does the client simply resend another create cell or it will re-select new > path instead? > > Thanks > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] relay lost most of its consensus weight
> On 13 Sep 2016, at 18:05, jensm1 wrote: > > Hi, > > I just realised that my relay 'itwasntme' lost most of its consensus > weight yesterday morning. The relay is only three weeks old, but it was > finally picking up some traffic, which now is gone again. > What could be the cause for this? Is there a problem with my relay or > configuration? It looks like you just recently gained some consensus weight, then temporarily lost it after you restarted your relay. We're working on improving the stability algorithm so these temporary downtimes don't affect relays as much. But in any case, wait a week or two, and it will be back. (If not, please let us know.) Tim > > Thanks for your help! > > > https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911E2 > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] relay lost most of its consensus weight
> On 13 Sep 2016, at 23:30, jensm1 wrote: > > I last restarted the relay five days ago (update to 0.2.8.7). Can a restart > really cause the consensus weight to drop several days later? If it drops > within a few hours, I'd get that, but what would delay that response that > much? > (Not complaining, just genuinely curious.) I'm really not sure - any flag changes should have an impact within an hour. Several days later is more likely to be bandwidth authority measurement - is your relay up and capable of transmitting as much traffic as it was before it was restarted? Are its ports open to all other relays? Can it open connections to other relays, regardless of their ports? Did you make any other config changes at the same time? Tim > > Am 13.09.2016 um 10:37 schrieb teor: >>> On 13 Sep 2016, at 18:05, jensm1 >>> wrote: >>> >>> Hi, >>> >>> I just realised that my relay 'itwasntme' lost most of its consensus >>> weight yesterday morning. The relay is only three weeks old, but it was >>> finally picking up some traffic, which now is gone again. >>> What could be the cause for this? Is there a problem with my relay or >>> configuration? >>> >> It looks like you just recently gained some consensus weight, then >> temporarily lost it after you restarted your relay. >> We're working on improving the stability algorithm so these temporary >> downtimes don't affect relays as much. >> But in any case, wait a week or two, and it will be back. >> (If not, please let us know.) >> >> Tim >> >> >>> Thanks for your help! >>> >>> >>> >>> https://atlas.torproject.org/#details/F46C312E279185364F46EA06C58F7925280911E2 >>> >>> >>> >>> ___ >>> tor-relays mailing list >>> >>> tor-relays@lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >> ricochet:ekmygaiu4rzgsk6n >> xmpp: teor at torproject dot org >> >> >> >> >> >> >> >> >> >> ___ >> tor-relays mailing list >> >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. > www.avast.com > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] relay lost most of its consensus weight
> On 14 Sep 2016, at 11:34, jensm1 wrote: > > Addendum: Did a bit of research (or rather checked some random relays on > Atlas). > > It seems like it's not only my relay that experienced a significant drop at > the same time. I can't find anything obvious these relays have in common. > new/old, large/small, guard/exit/middle, different countries and ASes. > So it might be BWAuth related after all. I don't think you need to worry about this in the short term - it is entirely normal for a relay's consensus weight to fluctuate. But here's my analysis, based on recent authority votes. 8 authorities vote on your relay 8 have the relay's observed bandwidth as 1112 (kilobytes per second) 4 measure your bandwidth, as: 377 394 1680 2820 https://collector.torproject.org/recent/relay-descriptors/votes/ The consensus has your weight as the low-median of these values: 394. https://collector.torproject.org/recent/relay-descriptors/consensuses/2016-09-14-00-00-00-consensus When your relay is measured again in another week, it might be that a figure closer to ~1500 becomes the low-median. If so, your observed bandwidth might end up being used as your consensus weight. The long-term fix for bandwidth measurement this is for the Tor network to geographically distribute more bandwidth authorities, or use a distributed bandwidth measurement system (this is an unsolved problem for untrusted distributed networks). It is possible that connections between your relay and other relays are blocked or slowed by some kind of firewall. This seems unlikely, because you're on the default ports. Do you block any outgoing ports from your tor instance? Has your provider imposed a bandwidth cap? Tim > > Am 14.09.2016 um 02:49 schrieb jensm1: >> That's exactly what baffles me. I didn't make any changes to the relay >> configuration since updating to 0.2.8.7. I've always had some fluctuations >> in the Advertised Bandwidth as reported by Atlas, but I assume these are >> from the BWAuth measurements? >> >> The only thing on my end, that I could imagine, is that the VPS provider >> changed something in his configuration. But since I don't see any >> interruption of the servers uptime (neither in Tor, nor in Debian, nor in >> the VPS control panel), I assume this couldn't be anything drastic like >> moving the VM to a different host machine. >> >> >> >> Am 14.09.2016 um 02:10 schrieb teor: >>>> On 13 Sep 2016, at 23:30, jensm1 >>>> wrote: >>>> >>>> I last restarted the relay five days ago (update to 0.2.8.7). Can a >>>> restart really cause the consensus weight to drop several days later? If >>>> it drops within a few hours, I'd get that, but what would delay that >>>> response that much? >>>> (Not complaining, just genuinely curious.) >>>> >>> I'm really not sure - any flag changes should have an impact within an hour. >>> Several days later is more likely to be bandwidth authority measurement - >>> is your relay up and capable of transmitting as much traffic as it was >>> before it was restarted? >>> Are its ports open to all other relays? >>> Can it open connections to other relays, regardless of their ports? >>> Did you make any other config changes at the same time? >>> >>> Tim >>> >>> >>>> Am 13.09.2016 um 10:37 schrieb teor: >>>> >>>>>> On 13 Sep 2016, at 18:05, jensm1 >>>>>> >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I just realised that my relay 'itwasntme' lost most of its consensus >>>>>> weight yesterday morning. The relay is only three weeks old, but it was >>>>>> finally picking up some traffic, which now is gone again. >>>>>> What could be the cause for this? Is there a problem with my relay or >>>>>> configuration? >>>>>> >>>>>> >>>>> It looks like you just recently gained some consensus weight, then >>>>> temporarily lost it after you restarted your relay. >>>>> We're working on improving the stability algorithm so these temporary >>>>> downtimes don't affect relays as much. >>>>> But in any case, wait a week or two, and it will be back. >>>>> (If not, please let us know.) >>>>> >>>>> Tim >>>>> >>>>> >>>>> >>>>>>
Re: [tor-relays] DigitalOcean pricing (Re: tomhek - the (new) biggest guard relay operator)
> On 14 Sep 2016, at 15:49, Matthew Walker wrote: > > If you're interested in knowing what happens when you scale up (in the USA), > I recently went on a quest to move from a collection of virtual private > servers to some sort of dedicated solution. > > * The cheapest I found in a tor friendly fully dedicated server is 70$/mo for > 1Gbps transit (via OVH) This is somewhat inaccurate: OVH only allows 500Mbps download and 1Gbps upload, and does not even guarantee that 500Mbps for Tor and other (open) proxies. Guaranteed 1Gbps transit both ways will cost you another $105 per month until the end of September 2016, and $210 per month afterwards. > * The cheapest 1 rack collocation I've found is 400$/mo for 1Gbps transit > (via HurricaneElectric); this was substantially cheaper than most quarter and > half rack colo options as well. > > This cost is broken out into two things > * transit (when not using a discount network like HE) you can expect to pay > upwards of $1000 / Gbit > * power (and cooling), somewhere between 10~50$/mo per amp depending on how > dense you are and if you want redundant A/B power. > > For not particularly dense installs on modern hardware, you can thumb about > 1.5A per rack U. And that modern server is going to set you back a couple > thousand as well (though you can get cheap 5year old hardware for a couple > bucks if you have the power/cooling to spare.) > > I'm continually surprised by how cheap VPS providers can go. Either they're > massively over-provisioning, or they get really good deals in bulk; probably > both. > > ~Mwalker > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Node families and guard flags
> On 16 Sep 2016, at 07:58, Ralph Seichter wrote: > > I have made some measurements. Downloading large files through Tor did > not appear to show significant differences between both nodes, which > could mean that Tor clients are either capped in general or the circuits > were overall not fast enough to make my nodes reach their limits. > > I also tried several iperf3 bandwidth measurements between the two Tor > nodes and a third server which I know to be reliably fast. My Tor node > #1 averaged 697 Mbits/sec, and #2 averaged 505 Mbits/sec -- while Tor > was running on both nodes. I tried this with both IPv4 and IPv6, the > latter being slightly faster. > > It would appear that even though #2 has less bandwidth than #1, the > available bandwidth of #2 is more than 10 times the bandwidth utilized > by Tor on this machine. I still don't understand why TorRelay02HORUS is > just limping along. A few things that affect consensus weight happen at random: * client usage, which affects observed bandwidth, which limits consensus weight, * the timing and pairing of bandwidth authority measurement, which limits consensus weight, It's possible that by chance, 02 got a bad measurement a week ago, and 01 got a good one. Give it a few more weeks, and see if the measurements even out. Tim > > -Ralph > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Rampup speed of Exit relay
> On 21 Sep 2016, at 20:01, D.S. Ljungmark wrote: > > Hi all, > > I'm looking at some traffic patterns for my Exit relay, and I'm frankly > a bit disappointed with the utilization. > > Currently it's running at a load average of 0.3-0.5, and CPU idle at > 70-80%. > > > We're not limited on Bandwidth (tests show that our max cap is more than > safe to produce), yet, we're barely reaching 20% of our potential > allocated traffic. > > > We've reached "fast" and "guard", and got the "stable" flag as well, so > in theory we ought to see traffic move a bit higher than currently. > > > So, how do we get tor to move past 100-200Mbit? Is it just a waiting game? How long has the relay been up? What's the fingerprint of your Exit relay? Where is it located? Have you read: https://blog.torproject.org/blog/lifecycle-of-a-new-relay Does your processor have AES-NI? Is it reasonably fast? Does Tor have enough sockets available? Does it warn you about any other potential performance issues in its logs? Have you tried running 2 Tor instances per IPv4 address? Also, have you tried searching the mailing list archives? This question gets asked and answered at least once a month. Tim > > //D.S. > > -- > 8362 CB14 98AD 11EF CEB6 FA81 FCC3 7674 449E 3CFC > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Caching new entry debian-tor...
> On 21 Sep 2016, at 22:46, Tristan wrote: > > Well, according to this question I asked on Tor's StackExchange, version > 0.2.4.26 is still technically in the recommended consensus. And it will be the next to go, likely when the next directory authority's details change, or a serious security issue is discovered. > At any rate, running an older version is better for diversity, isn't it? Sort of, but the accumulated security fixes and performance improvements in later versions tend to outweigh the benefit of running a really old version. You'd actually contribute more to Tor's diversity by running 0.2.6, and even 0.2.7 isn't the most common version any more. Tim > > > On Sep 21, 2016 2:13 AM, "shraptor" wrote: > On 2016-09-20 20:58, Roger Dingledine wrote: > On Tue, Sep 20, 2016 at 07:20:03PM +0200, shraptor wrote: > What's up with these messages I get in tor-arm and log? > > Caching new entry debian-tor for debian-tor [62 duplicates hidden] > > What is tor doing?? > > Sep 20 19:10:21.000 [notice] Caching new entry debian-tor for debian-tor > > It looks like this notice-level entry was changed to an info-level entry > starting in Tor 0.2.7.1-alpha: > > ... > > > So it looks like you are running an old version of Tor? You should > upgrade and the line should go away. In any case it should be harmless. > > > Yeah well I'm running on rpi3 and it says in tor-arm that 0.2.5 is the > recommended > version for this architecture. > > Anyway I checked out your public repo's of armhf compiled tor packages. > These packages are unfortunately dependent on libsystemd that is not welcome > on my systems. > I am running devuan as OS. > > So I have looked into building a newer version myself but it is a bit of > jungle > to setup the tool chain for me. > > > I hadn't noticed this log-message before and had some trouble with my relay > so felt the need to seek information. > > /scooby > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Rampup speed of Exit relay
> On 22 Sep 2016, at 05:41, nusenu wrote: > >>>> So, how do we get tor to move past 100-200Mbit? Is it just a waiting game? > > I'd say just run more instances if you still have resources left and > want to contribute more bw. > (obviously also your exit policy influences on how much your instance is > used) In my experience, a single Tor instance can use between 100Mbps and 500Mbps. It's highly dependent on the processor, OpenSSL version, and various network factors. There are also some random factors in the bandwidth measurement process, including the pair selection for bandwidth measurement. And clients also choose paths randomly. This means some relays get more bandwidth than others by chance. If you want to use the full capacity of your Exit, run multiple Tor instances. You can run 2 instances per IPv4 address, using different ports. Many people choose ORPort 443 and DirPort 80 as their secondary instance ports (this can help clients on networks that only allow those ports), but you can choose any ports you want. Have you considered configuring an IPv6 ORPort as well? (It's unlikely to affect traffic, but it will help clients that prefer IPv6.) >>> How long has the relay been up? >> >> 4 years or so. ( current uptime: 11 hours since reboot, it reboots weekly ) > > This relay (5989521A) has been first seen on 2014-04-10 according to > https://onionoo.torproject.org (still long enough). > > Why do you reboot weekly? Memory leak workaround? If you reboot weekly, you will take time each week to re-gain consensus weight and various other flags. For example, you will only have the HSDir flag for ~50% of the time. (The Guard flag is also affected, but it's somewhat irrelevant for Exits.) I'd avoid the reboots if you can, there's a known bug affecting at least the Guard flag and restarts, where a long-lived stable relays are disproportionately impacted compared with new relays. I haven't seen any evidence that it affects other flags or consensus weight, but you could try not restarting and see if that helps. > ... > >>> Have you tried running 2 Tor instances per IPv4 address? >> >> Previously, currently only one to see what throughput we could get a >> single Tor exit at. > > OK, so this email is about speed optimizations of a single tor instance > and not about increasing usage a tor exit server? Tor is not entirely multi-threaded yet. We still recommend running multiple instances on connections faster than 100 - 300Mbps. (And the Tor network currently only uses about 40% of capacity anyway, slightly more on Exits - this utilisation level helps keep latency low.) Later versions have better multithreading and crypto optimisations - thanks for keeping your relay up-to-date. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Rampup speed of Exit relay
> On 22 Sep 2016, at 04:40, D. S. Ljungmark wrote: > > On tor, 2016-09-22 at 12:08 +0200, Aeris wrote: >>> >>> Scaling up on more hardware is always an option, but I really want >>> to >>> push the limit of the exit node, as the others won't be exits >>> (Local >>> network design, really) , and exit traffic is always more >>> interesting. >> >> When I say another instance, it’s on the same hardware. >> Because Tor is not fully multi-thread/multi-core, you have to run >> another Tor >> daemon on the same host to use 1 more CPU core and so drain another >> 150-300Mbps. >> Currenly, you can start up to 2 Tor daemons per IP, there is a >> limitation to >> avoid Sybil attack. >> >> Regards, > > > Yes, I'm aware of this, but if I can't get Tor to scale up to even > 300Mbps on a single instance, adding another instance on the same > hardware isn't going to magically make it reach saturation. It might > improve things, seen from the network scaling it from 120Mbps to > 250Mbps, but it's certainly not going to push it to 700Mbps. It could - I started the exits radia0 and radia1 about a month ago, at almost the same time, with the same config (different IPs and ports), on the same gigabit link, with plenty of processor. radia0 (350 Mbps) is pushing almost double that of radia1 (200 Mbps): https://atlas.torproject.org/#search/radia > First, I want to find _why_ I'm not peaking either CPU usage, or > bandwidth usage. That the network is a stochastic and semi-random > limiter, I'm quite aware of, and adding more resources to pool that up > is doable. Please see my other email for details of how to measure your capacity locally. That said, these random factors are genuinely random, and have quite a wide range of results. We're working on measuring relay capacity better. > ( Though I can't add more ipv4 addresses right now, ipv6 is plentiful, > sadly, tor doesn't do very well on ipv6. ) You can run two tor instances per IPv4 address. Alternately, if your relay fingerprint has had a particularly bad set of random selections, you could try deleting the RSA and Ed25519 identity keys, and starting again. This will reset your reputation on the network. But that's effectively like starting another Tor instance, which you can already do without destroying your existing one. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Rampup speed of Exit relay
Hi, I wanted to highlight the following parts of my reply: The Tor network is quite happy to allocate around 47 MByte/s (yes, 376 MBit/s) to your relay based on its bandwidth measurements, but it won't do that until your relay shows it is actually capable of sustaining that traffic over a 10-second period (the observed bandwidth). At the moment, your relay can only do 19.83 MByte/s, so that's what it's being allocated. Maybe your provider has good connectivity to the bandwidth authorities, but bad connectivity elsewhere? Maybe your provider is otherwise limiting output traffic? Do you run a local, caching, DNS resolver? That could be a bottleneck, as almost all of your observed bandwidth is based on exit traffic. The details are below: > On 22 Sep 2016, at 03:58, D. S. Ljungmark wrote: > > On tor, 2016-09-22 at 06:29 +1000, teor wrote: >>> >>> On 22 Sep 2016, at 05:41, nusenu wrote: >>> >>>> >>>>> >>>>>> >>>>>> So, how do we get tor to move past 100-200Mbit? Is it just a >>>>>> waiting game? >>> >>> I'd say just run more instances if you still have resources left >>> and >>> want to contribute more bw. >>> (obviously also your exit policy influences on how much your >>> instance is >>> used) >> >> In my experience, a single Tor instance can use between 100Mbps and >> 500Mbps. >> It's highly dependent on the processor, OpenSSL version, and various >> network factors. > > Acknowledged, the question is, how do you measure that. There's a tool called "chutney" that can calculate an effective local bandwidth based on how fast a Tor test network can transmit data. Using it, I discovered that two machines that were meant to be almost identical had approximately 1.5 Gbps and 500 Mbps capacity, because one had a slightly older processor. This is how I test the local CPU capacity for Tor's crypto: git clone https://git.torproject.org/chutney.git chutney/tools/test-network.sh --flavor basic-min --data 1000 This is how I test the local file descriptor and other kernel data structure capacity: chutney/tools/test-network.sh --flavor basic-025 This is how I test what a single client can push through a Tor Exit (I think Exits limit each client to a certain amount of bandwidth, but I'm not sure - maybe it's 1 Mbit/s or 1 MByte/s): tor DataDirectory /tmp/tor.$$ PidFile /tmp/tor.$$/tor.pid SOCKSPort 2000 ExitNodes sleep 10 curl --socks5-hostname 127.0.0.1:"$1" >> There are also some random factors in the bandwidth measurement >> process, including the pair selection for bandwidth measurement. And >> clients also choose paths randomly. This means some relays get more >> bandwidth than others by chance. > > That's interesting, how does the bandwidth scaling / metering work? > Where/how does it decide how much bandwidth is available vs. what it > announces to the world? Tor has 5 bandwidth authorities that measure each relay around twice per week. Then the median measurement is used for the consensus weight, which is the weight clients use to choose relays. (The relay's observed bandwidth is also used to limit the consensus weight.) In particular, your relay is currently limited by its observed bandwidth of 19.83 MByte/s. Mouse over the "Advertised Bandwidth" figure to check: https://atlas.torproject.org/#details/5989521A85C94EE101E88B8DB2E68321673F9405 The gory details of each bandwidth authority's vote are in: https://collector.torproject.org/recent/relay-descriptors/votes/ Faravahar Bandwidth=1 Measured=43800 gabelmoo Bandwidth=1 Measured=78200 moria1 Bandwidth=1 Measured=47200 maatuska Bandwidth=1 Measured=40100 longclaw Bandwidth=1 Measured=49500 (I usually look these up by hand, but I'm sure there's a faster way to do it using stem.) So the Tor network is quite happy to allocate around 47 MByte/s (yes, 376 MBit/s) to your relay based on its bandwidth measurements, but it won't do that until your relay shows it is actually capable of sustaining that traffic over a 10-second period (the observed bandwidth). At the moment, your relay can only do 19.83 MByte/s, so that's what it's being allocated. Maybe your provider has good connectivity to the bandwidth authorities, but bad connectivity elsewhere? Maybe your provider is otherwise limiting output traffic? Do you run a local, caching, DNS resolver? That could be a bottleneck, as almost all of your observed bandwidth is based on exit traffic. > Right now I can comfortable pull/push 700Mbit in either direction on > this node, so that's where I left the setting, if there is a penalty > for stating more bandwidth
Re: [tor-relays] Rampup speed of Exit relay
> On 22 Sep 2016, at 11:55, Dennis Ljungmark wrote: > > On Thu, Sep 22, 2016 at 6:30 PM, teor wrote: >> ... >> >>>> Have you considered configuring an IPv6 ORPort as well? >>>> (It's unlikely to affect traffic, but it will help clients that >>>> prefer IPv6.) >>> >>> Not sure right now, I've had _horrid_ experiences with running Tor on >>> ipv6, ranging from the absurd ( Needing ipv4 configured to set up >>> ipv6) >> > >> IPv4 addresses are mandatory for relays for a few reasons: >> * Tor assumes that relays form a fully-connected clique - this isn't >> possible if some are IPv4-only and some are IPv6-only; >> * some of Tor's protocols only send an IPv4 address - they're being >> redesigned, but protocol upgrades are hard; >> * until recently, clients could only bootstrap over IPv4 (and they still >> can't using microdescriptors, only full descriptors); >> * and IPv6-only clients have poor anonymity, because they stick out too much. > > >>> to the inane ( Config keys named "Port" not valid for both ipv6 >>> and ipv4, horrid documentation) >> >> We're working on the IPv6 documentation, and happy to fix any issues. >> What particular Port config? >> What was bad about the documentation? > > DirPort tor.modio.se:888 won't actually bind on ipv6, even when it's > resolving to both ipv4 and ipv6 On most OSs, you can only bind to one IP address per socket. Tor tends to choose the IPv4 address when resolving domain names, because it's what most operators want. So I'd encourage you to use an explicit IPv4 or IPv6 address. Tor tries not to depend too much on DNS, because it's not particularly secure in general. > DirPort 888 ; won't actually bind on ipv6. > DirPort [::]:888; Won't actually bind on ipv6 The binding does work with explicit IPv4 and IPv6 addresses. But an IPv6 DirPort will never be used by any other Tor client or relay. Clients use the IPv4 or IPv6 ORPort, and relays use the IPv4 DirPort. We have an open ticket to clarify this in the DirPort documentation. > Adding more DirPort statements means that you have to pick and choose, > ipv6 or ipv4. Can only broadcast one. Yes, the relay descriptor syntax only supports one IPv4 address, with one DirPort. However, it is possible to supply an IPv6 ORPort using an explicit IPv6 address. > ORPort same as above. Have you tried explicit IPv4 or IPv6 addresses? > Having to actually hard-code ipv6 (in the dynamic nature that it is) > in the config files is a pure failure, and I ended up writing a way > too annoying template file to fill it in a boot, simply because Tor > can't bind to a port when it's told. The current default is IPv4 0.0.0.0, as documented in the ORListenAddress man page entry. Tor doesn't detect your IPv6 address at the moment, so you have to supply it explicitly. There's an open ticket for that, but address autodetection is fraught with confusion. We really do encourage operators to provide explicit, known stable addresses. Although it looks like we could also improve the resolution and binding when relay operators supply a domain name. Feel free to open a ticket with the issues that you're seeing: https://trac.torproject.org/ >>> My general consensus from last I looked in depth at this is that "Tor >>> doesn't support ipv6. It claims to, but it doesn't." >> >> Choosing anonymous, random paths through a non-clique network (mixed >> IPv4-only, dual-stack, and IPv6-only) is an open research problem. We can't >> really implement IPv6-only relays until there are some reasonable solutions >> to this issue. Until then, we have dual-stack relays. >> >> And IPv6-only Tor clients can connect using IPv6 bridges, or bootstrap over >> IPv6 with ClientUseIPv4 0 and UseMicrodescriptors 0. >> >> That's pretty much the limit of what we can do with IPv6, until researchers >> come up with solutions to the non-clique issue. > > You can fix the daemon to actually be capable of binding to ports, and > to not require us to jump through annoying settings just to get it to > even _listen_ to ipv6. IPv6 DirPorts are not used. IPv6 ORPorts work like this: ORPort [IPv6 address]:Port I'm not sure what we could improve, given that the operator really needs to nominate a stable IPv6 address. >>> How much downtime can the node have before losing consensus >>> weight/flags? >> >> A restart loses the HSDir flag for 72 hours, and the Guard flag for a period >> that is dependent on how old your relay is. (It should be inv
Re: [tor-relays] How to get rid of 'Family' entries?
> On 30 Sep 2016, at 09:38, theonion...@gmx.com wrote: > > Hi there! > > For testing purposes (The Onion Box) I've added a family entry to the > configuration of my relay. > As this other (family) relay doesn't exist I removed the entry from my torrc > again - and thought it would be removed from the onionoo information as well. > But - surprisingly - it's still in the data (several days after removal from > my torrc). > > Is there a way to actively reset that information - or will it be forgotten > by the consensus after some time? The family line isn't in your relay descriptor: https://collector.torproject.org/recent/relay-descriptors/server-descriptors/2016-09-30-21-05-00-server-descriptors Nor is it in the consensus: https://collector.torproject.org/recent/relay-descriptors/microdescs/consensus-microdesc/2016-09-30-21-00-00-consensus-microdesc It may just be that OnionOO is out of date, or updates family entries on a slower schedule. > Additionally: Tor accepted - without complaining - a false entry. Shouldn't > there be any procedure to verify this data? What do you mean by a false entry? What behaviour are you expecting? Any use of a nickname in the family line generates a warning that nicknames are not verifiable and that fingerprints should be used. Tim > > Best regards, Ralph > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] help #3
> On 30 Sep 2016, at 14:01, Green Dream wrote: > > Have you double-checked the ulimit was applied correctly? Including > making sure it's applied to the user account running Tor? Here's how I > do that on Ubuntu/Debian, assuming the user account is "debian-tor": > > sudo su debian-tor --shell /bin/bash --command "ulimit -Sn" > sudo su debian-tor --shell /bin/bash --command "ulimit -Hn" > > Those should return the actual hard and soft limits being applied to > the debian-tor user. In my case it returns 64000, but you'll just want > to make sure it's what you're expecting. > >> nothing works and now I am running out of ideas > > It would be easier for people to help if you elaborate a bit -- > perhaps the exact commands you've already tried and the log messages > (if there are any other error or warning messages besides the one you > already listed). The debian packages should set the appropriate file descriptors for you. How are you launching your tor services? T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] help #3
> On 30 Sep 2016, at 14:37, Markus Koch wrote: > > Installed with apt-get and started simply as a demon aka service tor start > Thank you for helping Have you tried: >>> sudo su debian-tor --shell /bin/bash --command "ulimit -Sn" >>> sudo su debian-tor --shell /bin/bash --command "ulimit -Hn" What are the file descriptor limits set to? How much RAM does the system have? What are the TCP buffer limits in the kernel? Here's some background: In Tor, there are the 4 C/Linux error return values that can trigger that message: EMFILE ENFILE ENOBUFS ENOMEM On my system, "man 2 intro" lists them as: Too many open files...the limit on the number of open files per process... Too many open files in system. Maximum number of file descrip- tors allowable on the system has been reached... No buffer space available. An operation on a socket or pipe was not performed because the system lacked sufficient buffer space or because a queue was full. Cannot allocate memory. The new process image required more memory than was allowed by the hardware or by system-imposed mem- ory management constraints… T > > Markus > > > > > > > 2016-09-30 23:33 GMT+02:00 teor : >> >>> On 30 Sep 2016, at 14:01, Green Dream wrote: >>> >>> Have you double-checked the ulimit was applied correctly? Including >>> making sure it's applied to the user account running Tor? Here's how I >>> do that on Ubuntu/Debian, assuming the user account is "debian-tor": >>> >>> sudo su debian-tor --shell /bin/bash --command "ulimit -Sn" >>> sudo su debian-tor --shell /bin/bash --command "ulimit -Hn" >>> >>> Those should return the actual hard and soft limits being applied to >>> the debian-tor user. In my case it returns 64000, but you'll just want >>> to make sure it's what you're expecting. >>> >>>> nothing works and now I am running out of ideas >>> >>> It would be easier for people to help if you elaborate a bit -- >>> perhaps the exact commands you've already tried and the log messages >>> (if there are any other error or warning messages besides the one you >>> already listed). >> >> The debian packages should set the appropriate file descriptors for you. >> How are you launching your tor services? >> >> T >> >> -- >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >> ricochet:ekmygaiu4rzgsk6n >> xmpp: teor at torproject dot org >> >> >> >> >> >> >> T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Help configuring a relay on OS X
> On 1 Oct 2016, at 06:06, Surf Norway wrote: > > A few years ago I tried setting up a relay as a way to contribute back to the > community, I have fast symmetrical fiber and a Mac mini running as a light > file server. I never was able to get it to work and gave up. > > I recently bumped up the RAM to max and put an SSD drive in, upgraded to > 10.11 and thought I'd give another go at setting up a relay. You'll need around 512 MB - 768 MB of RAM for the tor process. > I've installed Xcode and the command line tools, installed MacPorts and used > that to install Tor. Using these instructions? https://www.torproject.org/docs/tor-doc-osx.html.en > I configured the torrc file as best I could and expect that's probably the > problem with my setup. When I start Tor (v0.2.8.8) it identifies the OS, > reads the torrc file and grabs a chunk of memory for MaxMemInQueues. Can you provide your torrc file? Please feel free to leave out specific IP addresses if you would like - but your IP address will become public when your relay gets on the network. > Then it opens OR listener but on an invalid IP (0.0.0.0), 0.0.0.0 means "bind to all interfaces" - it's an entirely valid IP address for this purpose. > complains that it can't write to the log file (permission denied), Can you please copy and paste all the log messages, rather than describing them? The specific details are often important. > and closes partially-constructed OR & directory options. > > Before I go and change the log file permissions, what user should I be > running as when I start Tor as a relay? On OS X, create a new system user called "tor", and run tor as that user. This isolates tor from the other processes running on that machine. (We recommend ) > Ideally I want it to start with the system and run by default in the > background and uncommented "RunAsDaemon 1" in the torrc file. The mini sits > and serves files normally and isn't usually in use as a normal > computer/console. When I run Tor myself it's from a different machine in > order to use the Tor browser. All I want the mini to do is act as a relay, > nothing more. Here's how you can start a relay on OS X on boot: https://trac.torproject.org/projects/tor/wiki/doc/MacRunOnBoot T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Question about relay speed + quick question about IPV6
> On 2 Oct 2016, at 17:17, Sheesh wrote: > > Thanks for everybody's input. I decided to move the relay keys to the > new server but I'm not entirely sure if I start another slow (500KB/s) > one or just seed some Linux distros or do something else helpful. > > Also I do have a question about IPv6: > If I read right I just have to add > ORPort [IPv6]:Port > DirPort [IPv6]:Port You only need the ORPort, the IPv6 DirPort isn't needed any more. (It was used by a few of the 0.2.8 alpha series, but removed before the stable release.) > is this correct? > Can I specify the same ports I use for IPv4 (443 and 80)? Yes, this should work on most OSs, if it doesn't, please file a bug. > Also since I have a couple of IPv6 available but a non-exit relay is it > still necessary to set OutboundBindAddress? OutboundBindAddress can be used twice, once with an IPv4 address and once with an IPv6 address. Outbound traffic on a non-exit relay is all IPv4, and it will use the routing table if you don't use OutboundBindAddress. Unless you have multiple IPv4 addresses, it won't make any difference. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Question about relay speed + quick question about IPV6
> On 2 Oct 2016, at 18:59, Sheesh wrote: > > Thank you! Two last questions, though (hope it's okay): Do I need to put > ExitPolicy reject6 *:* in my torrc or is this covered by ExitPolicy reject > *:*? ExitPolicy reject *:* applies to both IPv4 and IPv6. And your relay won't exit on IPv4 unless you set ExitRelay to 1, and won't exit on IPv6 unless you set IPv6Exit and ExitRelay to 1. > Also why do I always have 4 or 8 circuits open? At least that's what tor-arm > shows me. Because tor preemptively builds circuits for you to use when you need them. When your relay publishes a descriptor, it will make more circuits as needed to relay client traffic. Tim > > On 03.10.2016 03:34, teor wrote: >>> On 2 Oct 2016, at 17:17, Sheesh >>> wrote: >>> >>> Thanks for everybody's input. I decided to move the relay keys to the >>> new server but I'm not entirely sure if I start another slow (500KB/s) >>> one or just seed some Linux distros or do something else helpful. >>> >>> Also I do have a question about IPv6: >>> If I read right I just have to add >>> ORPort [IPv6]:Port >>> DirPort [IPv6]:Port >>> >> You only need the ORPort, the IPv6 DirPort isn't needed any more. >> (It was used by a few of the 0.2.8 alpha series, but removed before the >> stable release.) >> >> >>> is this correct? >>> Can I specify the same ports I use for IPv4 (443 and 80)? >>> >> Yes, this should work on most OSs, if it doesn't, please file a bug. >> >> >>> Also since I have a couple of IPv6 available but a non-exit relay is it >>> still necessary to set OutboundBindAddress? >>> >> OutboundBindAddress can be used twice, once with an IPv4 address and once >> with an IPv6 address. Outbound traffic on a non-exit relay is all IPv4, >> and it will use the routing table if you don't use OutboundBindAddress. >> >> Unless you have multiple IPv4 addresses, it won't make any difference. >> >> T >> >> -- >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >> ricochet:ekmygaiu4rzgsk6n >> xmpp: teor at torproject dot org >> >> >> >> >> >> >> >> >> >> >> ___ >> tor-relays mailing list >> >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Question about relay speed + quick question about IPV6
> On 2 Oct 2016, at 19:10, Tristan wrote: > > Um, yes it will. I don't have ExitRelay in my torrc file at all, and it exits > just fine. Yes, you're right, ExitRelay is auto by default, which means Exit, but warn. Tim > > On Sun, Oct 2, 2016 at 9:03 PM, teor wrote: > > And your relay won't exit on IPv4 unless you set ExitRelay to 1 > > -- > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > > > > > > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > -- > Finding information, passing it along. ～SuperSluether > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata
> On 5 Oct 2016, at 18:10, wrote: > > We're back to IPS, which can drop the specific malicious traffic. I've been > speaking with the lawyer few minutes ago. He told me that there is a pressure > to put all the responsibility for the traffic to the ISPs. Well ... what are > the ISPs most probably going to do ... ? They can ban all tor exit nodes, or > they will force the owners to clear the traffic. > > When you're worried about being accused, why you don't use fake information > during registration and payments with bitcoins? Then you can also filter the > traffic by IPS ... and everybory will be happy. There are a few things wrong with your suggested solution: * it's really, really hard to stay anonymous on the Internet as an individual, and impossible for many corporations (it's hard to be transparent about how you spend money as a charity, and be anonymous at the same time), * if all Tor Exit Nodes are anonymous, ISPs may block them more, not less, * filtering will likely get your Exit marked as a BadExit, * IPS aren't perfect - they let some unwanted traffic through, and block other traffic that is totally ok. Tim > > What should a tor exit op do? Ban the user? exits get the traffic from middle > nodes and we cant tell (by design) who anyone is. We can block ips but that > is not really helping with bots who tries to find vulnerabilities and scan > large blocks. > > markus > > Sent from my iPad > > On 4 Oct 2016, at 23:55, wrote: > > If I understand that well ... if tor operator is avare, that his tor node is > used for illegal activity (when their ISP told them about that) and he's not > going to do anything abou that, he wont be guity by complicity? > > > On 04.10.16 22:37, oco...@email.cz wrote: > > > Tor and IPS has both it's own nature and you shouldn't be punished, if > > your intension was just to filter the bad traffic. > > And who is to decide what constitutes "bad traffic"? I am not a lawyer, > but in Germany one of the cornerstones of not being held responsible > for traffic passing through a Tor node is § 8 of the Telemediengesetz: > http://www.gesetze-im-internet.de/tmg/__8.html -- sometimes referred to > colloquially as the "provider privilege". > > One only is free of responsibility if one neither initiates a transfer, > nor selects the transfer's destination, nor selects or modifies the > transmitted data. That's what "passing through" means. > > According to two lawyers I spoke to, exit policies might already be > borderline breaking these rules for exit nodes, but the technical basis > at least guarantees that traffic will never reach an exit node that does > not let it pass. Now think of a firewall that interferes with transfers > once the data has already reached the exit node. Wouldn't you agree that > this means selecting/modifiying the transmitted data? > > That's just one national law that I am aware of, I imagine other > countries have similar regulations in place. Any internet service > provider interfering with net neutrality risks lawsuits, because it is > not an ISP's prerogative to decide what traffic is "good" or "bad". > > -Ralph > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > = > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Dealing with OVH Abuse Complaints
Hi, Does anyone have experience running a long-lived Exit on OVH / So You Start? We've just received a threat to shut down our OVH Exit due to abuse complaints. We were responding to these automated reports (mainly SSH brute force) with template responses, offering to block the destination IP and port if the remote site wanted us to. We never received a reply. What does OVH expect its Exit operators to do with complaints? Should we have blocked each complaining IP address as soon as we received a complaint? Tim T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay uptime after restarting Tor service
> On 8 Oct 2016, at 06:15, I wrote: > > Nothing you do actually gets you a tshirt. > The knowledge that you qualified for a tshirt is your only badge of honour. Contacting Jon has got a few people t-shirts, although he was working hard on the Tor meeting for the past month. We're working on replacing Tor Weather with a script that works out when relay operators are eligible for t-shirts. Tim > >> -Original Message- > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata
> On 7 Oct 2016, at 05:07, Green Dream wrote: > > If we're going to change anything I think it needs to happen within > Tor software. Operators could leverage the existing "Exitpolicy > reject" rules, or Tor could add functionality there if it's missing. > Whatever we do, I think it needs to be uniform and transparent. I had a conversation with someone at the recent tor meeting about rate-limiting Tor traffic. There are all sorts of drawbacks (blocking popular sites, for example), but I wonder if there are rate-limiting settings that would eliminate the majority of abuse reports based on default fail2ban and similar reporting system settings. For example, I wonder if the complaints I receive about SSH could be eliminated by slowing down repeated SSH connections to the same host by a second or so. Clearly more research is needed to work out if this is even feasible, and, if it is, what rate limits should apply to what ports. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Intrusion Prevention System Software - Snort or Suricata
> On 9 Oct 2016, at 11:00, Markus Koch wrote: > > Would not help. These are bots, you can slow them down but this will > not stop them at all. Ah, but the point isn't to stop the bots, it's to stop the abuse complaints by coming in under the abuse report automated thresholds. In my experience, the abuse complaints are auto-generated, and no-one replies to my offer to block the site. So why not eliminate the complaints? Then everyone will be happy. Except the bot-herders. Tim > > Markus > > > 2016-10-09 1:57 GMT+02:00 teor : >> >>> On 7 Oct 2016, at 05:07, Green Dream wrote: >>> >>> If we're going to change anything I think it needs to happen within >>> Tor software. Operators could leverage the existing "Exitpolicy >>> reject" rules, or Tor could add functionality there if it's missing. >>> Whatever we do, I think it needs to be uniform and transparent. >> >> I had a conversation with someone at the recent tor meeting about >> rate-limiting Tor traffic. There are all sorts of drawbacks (blocking >> popular sites, for example), but I wonder if there are rate-limiting >> settings that would eliminate the majority of abuse reports based on >> default fail2ban and similar reporting system settings. >> >> For example, I wonder if the complaints I receive about SSH could be >> eliminated by slowing down repeated SSH connections to the same host >> by a second or so. >> >> Clearly more research is needed to work out if this is even feasible, >> and, if it is, what rate limits should apply to what ports. >> >> T >> >> -- >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >> ricochet:ekmygaiu4rzgsk6n >> xmpp: teor at torproject dot org >> >> >> >> >> >> >> >> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] RPi Relay Maximum Speed
> On 13 Oct 2016, at 06:07, diffusae wrote: > > Hi! > > On 12.10.2016 07:18, Manny wrote: >> Oh and since I'm bugging you anyways - would it be useful to add ORPort >> [IPv6] as well? (same port as for 4 i guess?) > > Yes, I've done this already. There are only a few number of IPv6 > Clients, but I guess it would be useful. Most of the time, there are the > same. I don't know why? > > https://lists.torproject.org/pipermail/tor-relays/2015-May/007027.html That mailing list post was about an IPv6 ExitPolicy bug that we fixed in 0.2.7. This is how it works now on Tor Exits: For IPv4 and IPv6: ExitPolicy reject *:80 For IPv6 only: ExitPolicy reject6 *:80 > You cannot advertise the same DirPort on IPv4 and IPv6, but the ports > could be the same. No current tor version uses an IPv6 DirPort to connect to the network. Relays always use IPv4 to connect to the tor network, and they use IPv4 DirPorts to bootstrap. Clients gained the ability to use IPv6 ORPorts for bootstrap in 0.2.8, and we made client bootstrapping ORPort-only in the same release. So, in 0.2.7 and earlier, IPv6-only clients can use: * bridge IPv6 ORPorts by configuring a bridge with an IPv6 address. And in 0.2.8 and later, IPv6-only clients can use: * bridge IPv6 ORPorts by configuring a bridge with an IPv6 address, or * authority, fallback directory, and relay IPv6 ORPorts by configuring: ClientUseIPv4 0 UseMicrodescriptors 0 (IPv6-only clients can't bootstrap using microdescriptors yet, see: https://trac.torproject.org/projects/tor/ticket/19608 ) This is experimental - being one of the rare IPv6-only clients on the network may harm your anonymity. (This is why you see the same few clients all the time.) But if your priority is local network censorship-evasion, then IPv6 might just work for you. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] OBFS4 Bridge
> On 13 Oct 2016, at 10:53, p...@sigaint.org wrote: > > Have been running an obfs3 bridge for a while. Since I was building a new > Debian server wanted to add obfs4, but when I configure TBB to point to > the obfs4 port [Z] I get "general SOCKS failure" in the TBB log. Changing > it back to use obfs3 and port [Y] works fine. How can I fix it so obfs4 > works too? > > Here are the relevant lines from torrc: > --- > ORPort [X] > > BridgeRelay 1 > PublishServerDescriptor bridge > > ServerTransportPlugin obfs3 exec /usr/bin/obfs4proxy managed Here, you ask obfs4proxy yo of obfs3 for you, but not obfs4. Try obfs3,obfs4 instead. And then give tor browser the full line from the bridge line file in the obfs4proxy directory (the exact file name is in the obfs4proxy readme). T > ServerTransportListenAddr obfs3 0.0.0.0:[Y] > ServerTransportListenAddr obfs4 0.0.0.0:[Z] > ExtORPort auto > --- > > If I do netstat -pan, I see obfs4proxy is listening on both ports on all > interfaces. I tried to add "--log-file logfile" after /usr/bin/obfs4proxy > in torrc but then it wouldn't start the proxy at all. I'm not finding any > other log messages showing a problem. Tor's log is clean, just shows it > starting both proxy instances (which netstat confirms.) Obfs4proxy is the > packaged version 0.0.6. > > Not sure where else to look or change. I'd like to get it working but have > commented out the obfs4 line for now. > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] RPi Relay Maximum Speed
> On 14 Oct 2016, at 08:05, diffusae wrote: > > Hello! > > Thanks a lot for your explanation. > > It was a kind of misunderstanding the subject (Please enable IPv6 on > your relay!) and also the instructions, what was written on the wiki > (IPv6RelayHowto). > > In other words, for non-exit relays, there is no need to enable IPv6 at > this time, only if you use it as a bridge and/or as an IPv6-only client. No, that's not what I said. On non-exit relays, please enable the IPv6 ORPort. There's no need to enable an IPv6 DirPort. Tim > > Regards > > > On 13.10.2016 01:46, teor wrote: >> >>> On 13 Oct 2016, at 06:07, diffusae wrote: >>> >>> Hi! >>> >>> On 12.10.2016 07:18, Manny wrote: >>>> Oh and since I'm bugging you anyways - would it be useful to add ORPort >>>> [IPv6] as well? (same port as for 4 i guess?) >>> >>> Yes, I've done this already. There are only a few number of IPv6 >>> Clients, but I guess it would be useful. Most of the time, there are the >>> same. I don't know why? >>> >>> https://lists.torproject.org/pipermail/tor-relays/2015-May/007027.html >> >> That mailing list post was about an IPv6 ExitPolicy bug that we fixed >> in 0.2.7. This is how it works now on Tor Exits: >> >> For IPv4 and IPv6: >> ExitPolicy reject *:80 >> >> For IPv6 only: >> ExitPolicy reject6 *:80 >> >>> You cannot advertise the same DirPort on IPv4 and IPv6, but the ports >>> could be the same. >> >> No current tor version uses an IPv6 DirPort to connect to the network. >> >> Relays always use IPv4 to connect to the tor network, and they use >> IPv4 DirPorts to bootstrap. >> >> Clients gained the ability to use IPv6 ORPorts for bootstrap in 0.2.8, >> and we made client bootstrapping ORPort-only in the same release. >> >> So, in 0.2.7 and earlier, IPv6-only clients can use: >> * bridge IPv6 ORPorts by configuring a bridge with an IPv6 address. >> >> And in 0.2.8 and later, IPv6-only clients can use: >> * bridge IPv6 ORPorts by configuring a bridge with an IPv6 address, or >> * authority, fallback directory, and relay IPv6 ORPorts by configuring: >> ClientUseIPv4 0 >> UseMicrodescriptors 0 >> >> (IPv6-only clients can't bootstrap using microdescriptors yet, see: >> https://trac.torproject.org/projects/tor/ticket/19608 >> ) >> >> This is experimental - being one of the rare IPv6-only clients on the >> network may harm your anonymity. (This is why you see the same few >> clients all the time.) But if your priority is local network >> censorship-evasion, then IPv6 might just work for you. >> >> T >> >> -- >> Tim Wilson-Brown (teor) >> >> teor2345 at gmail dot com >> PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >> ricochet:ekmygaiu4rzgsk6n >> xmpp: teor at torproject dot org >> -- >> >> >> >> >> >> >> >> >> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] OffTopic: onionoo.torproject.org as HS?
> On 16 Oct 2016, at 03:30, nusenu wrote: > > > > Ralph Wetzel: >> Hi there! >> This might be a bit offtopic - yet as it's related to the dev of The Onion >> Box, >> I'm asking this here: Anyone knows of a hidden service that offers the (same) >> data as onionoo.torproject.org? I found 'onionoorcazzotwa.onion' but this is >> heavily outdated (status time is 2016-09-26 18:00:00). Any other proposals? >> Best regards, Ralph > > > https://trac.torproject.org/projects/tor/ticket/20275 All of the official torproject onions are here: https://onion.torproject.org/ T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] relay lost most of its consensus weight
> On 14 Oct 2016, at 22:23, Tor User wrote: > > I apologize for what is probably bad form in replying to an older thread that > has sort of fallen off, but I've been trying to figure out why I just can't > seem to get any consensus weight on our middle relay (ByTORAndTheSnowDog). I prefer context, and I prefer knowing you've read the old thread. > We moved in May to another city and have a different internet provider now. > We had gigabit symmetrical internet at the last place and I *get* that a drop > in bandwidth and consensus should be expected, but our internet bandwidth > here is not that bad. 300mbit down/20mbit up. > > Consensus weight is mostly a function of your upstream bandwidth, right? Not quite, it's a function of your bandwidth to the bandwidth authorities, your latency to the bandwidth authorities, and the actual utilisation of your relay. The minimum of your downstream and upstream bandwidth can be used as a first approximation. > Do the bandwidth auth testers ever "get it wrong"? Oh yes, they are consistently inaccurate, typically on a geographical or network basis. And they are somewhat random for individual servers over short timeframes. (The bandwidth authorities are in North America and Europe on 5 particular networks. If you're a long way from those networks, your measurements are lower than other servers with similar capacity.) We're working on some improvements right now. > I'm not sure where to look to see what kind of bandwidth is being measured > from us. https://collector.torproject.org/recent/relay-descriptors/votes/ w Bandwidth=344 Measured=19 w Bandwidth=344 Measured=49 w Bandwidth=344 Measured=50 w Bandwidth=344 Measured=50 w Bandwidth=344 Measured=232 (low-)median: 50 We could make this easier for relay operators by showing the measured bandwidth in consensus health. https://trac.torproject.org/projects/tor/ticket/20372 > It seems unlikely however that we are only able to push out the paltry rates > I see in our atlas entries. Your relay's observed bandwidth is exactly the rate seen in your atlas entry: http://24.74.79.53:9030/tor/server/authority https://atlas.torproject.org/#details/B735643D239170947669269A78F8478EC5343219 > These are the rate limiting-related settings I'm running in torrc: > > RelayBandwidthRate 2300 KB > RelayBandwidthBurst 2500 KB > > BandwidthRate 2300 KB > BandwidthBurst 2500 KB > > Not using any MaxAdvertisedBandwidth settings anymore -- I commented them out > a week or so ago at last restart after reading that you shouldn't set these > if you are looking to get more traffic. You can reload tor's config using: kill -HUP `cat /var/run/tor.pid` Or the equivalent service command on your OS/distribution. This avoids a restart. > The most likely explanation is, we just don't have the upstream bandwidth we > think we do. It would certainly seem that way. Or you have bad upstream connectivity to some ports or IP addresses. Or your provider limits the number of simultaneous connections you can make. Or your provider rate-limits your connections. Or your provider drops long-lived connections. > But I consistently get speedtest.net upstream tests above 20 megabits/sec to > different speedtest sites around eastern US "hubs" (atlanta, virginia, ie, > places that have bandwidth). So I don't understand. I would say "ask your provider", but I doubt they'll be sympathetic. Perhaps finding another provider would help? Or a cheap VPS? Tim > > Thanks > > > > On 09/13/2016 09:38 PM, teor wrote: >>> On 14 Sep 2016, at 11:34, jensm1 >>> wrote: >>> >>> Addendum: Did a bit of research (or rather checked some random relays on >>> Atlas). >>> >>> It seems like it's not only my relay that experienced a significant drop at >>> the same time. I can't find anything obvious these relays have in common. >>> new/old, large/small, guard/exit/middle, different countries and ASes. >>> So it might be BWAuth related after all. >>> >> I don't think you need to worry about this in the short term - it is >> entirely normal for a relay's consensus weight to fluctuate. >> >> But here's my analysis, based on recent authority votes. >> 8 authorities vote on your relay >> 8 have the relay's observed bandwidth as 1112 (kilobytes per second) >> 4 measure your bandwidth, as: >> 377 >> 394 >> 1680 >> 2820 >> >> https://collector.torproject.org/recent/relay-descriptors/votes/ >> >> >> The consensus has your weight as the low-median of these values: 394. >> >> https://collector.torproje
Re: [tor-relays] Why do 40% of Tor exits uses 8.8.8.8 for DNS resolving ?
> On 17 Oct 2016, at 13:37, Jesse V wrote: > > On 10/16/2016 04:54 PM, Petrusko wrote: >> Thx for this share. >> >> But I'm not sure how Unbound is "speaking" with the roots DNS servers... >> Somewhere I've read that DNS queries can be forwarded by a "man in the >> middle", and the server operator can't be sure about this :s >> An ISP is able to do it with your "private server" hosted behind your >> ISP's router... >> >> I see DNSsec to crypt DNS queries from a client to a server, but for >> sure it's not possible to use it with roots DNS servers... > > My VPS host uses 8.8.8.8 for DNS by default. I think it's configured in > their DHCP settings or something because 8.8.8.8 will end up in > /etc/resolv.conf every time the VPS restarts. Consequently, I have to > keep an eye on /etc/resolv.conf to ensure that it always points to my > Unbound instance. I take immediate action if this is not the case. You might find ServerDNSResolvConfFile useful if you want to avoid using the default system resolver file /etc/resolv.conf T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] I think I my relay is broken
> On 17 Oct 2016, at 15:31, Tamara West wrote: > > Earlier today I installed my relay and thought everything was good. Now > looking at the arm I no longer think so. > > (1) Events (TOR/ARM NOTICE - ERR): > x 23:07:41 [ARM_NOTICE] Unable to prepopulate bandwidth information > (insuffic- > x ient uptime) This is a normal notice for new relays. > x 23:07:41 [ARM_WARN] The torrc differs from what tor's using. You can issue > a > x sighup to reload the torrc values by pressing x. > qj - torrc value differs on line: 3 What is on line 3 of your torrc? It would help if you sent us your entire torrc. > (2) Events (TOR/ARM NOTICE - ERR): > x 23:13:17 [WARN] Your server (207.172.253.216:80) has not managed to confirm > x that its DirPort is reachable. Relays do not publish descriptors until > x their ORPort and DirPort are reachable. Please check your firewalls, > x ports, address, /etc/hosts file, etc. Your relay's DirPort is not reachable from the outside. So it won't join the tor network. What is the configured Address in your torrc? Is it 207.172.253.216? Is 207.172.253.216 the public IPv4 address of your relay? What is the configured DirPort of your relay? Does port 80 on 207.172.253.216 map to port 80 on your relay? (if you are behind a NAT) > qj 23:07:41 [ARM_NOTICE] Unable to prepopulate bandwidth information > (insuffic- > > If I hit x twice to reload the values it only seems to refresh for the moment > but when I restart it's back to the errors. > > Anyhelp would be greatly appreciated. Tell us what you think the issue is, and what you've tried doing to fix it. Then we can be more helpful. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Smallest, cheapest, lightest computer for tor relay
> On 18 Oct 2016, at 00:49, Tristan wrote: > > "Windows" and "Tor relay" don't really go together. The Windows bufferevents code rotted due to lack of testing, so it's hard to run a performant Tor relay on Windows. But we'd welcome patches to get Tor working better on Windows. After all, a large number of Tor clients, and some hidden services, are on Windows. Tim > On Oct 17, 2016 8:47 AM, "Petrusko" wrote: > RPi 2/3 if I'm not wrong are around 3 Watts (fanless) > An old P4... For sure it's not lower than 60 Watts power consumption > > And if he wants to run only a Tor relay, advantage to have Windows OS is > relative ;) > Not really agree... > > But agree about cpu speed ;) > I don't remember, RPi v3 has the famous AES-NI that make everything > faster for Tor ? :s > > > 17/10/2016 14:18, Neel Chauhan : > > The disadvantage of the PC approach is space and higher power > > consumption, but the advantage is that you can use *BSD and Windows, > > and can possibly take advantage of faster speeds. > > -- > Petrusko > PubKey EBE23AE5 > C0BF 2184 4A77 4A18 90E9 F72C B3CA E665 EBE2 3AE5 > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Smallest, cheapest, lightest computer for tor relay
> On 18 Oct 2016, at 08:26, diffusae wrote: > > AES-NI is an extension to the x86 architecture for CPUs from Intel and > AMD. The Pi 3 is build with a ARM Cortex-A53 CPU (ARMv8-A). This has > NEON SIMD extension (Advanced SIMD 128 bit registers) with instruction > level support for AES (which implement AES rounds) and SHA-1/SHA-256. > > So, I think it should be faster with Tor. It would depend on whether your OpenSSL/LibreSSL was built with the appropriate accelerated instruction support. That said, the rest of Tor's crypto doesn't have NEON acceleration yet. Tim > > On 17.10.2016 15:47, Petrusko wrote: >> I don't remember, RPi v3 has the famous AES-NI that make everything >> faster for Tor ? :s > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Why do 40% of Tor exits uses 8.8.8.8 for DNS resolving ?
> On 18 Oct. 2016, at 13:25, Jesse V wrote: > > On 10/17/2016 12:34 PM, Hoshpak wrote: >>> # chattr +i /etc/resolv.conf >>> >>> Exact it works fine :) >> >> Please only do this if your are sure your server is not running in a >> Virtuozzo/OpenVZ container environment. On Virtuozzo, the startup >> procedure includes scripts that rewrite resolv.conf and fail if they >> can't write to it. In these cases you could be left with an unbootable >> container and have to raise a support ticket with your ISP to make them >> "fix" the issue by removing the immutable bit and starting the container >> again. > > Thank you very much for that tip. Cronjob is probably the way to go then. Configuring tor with a separate ServerDNSResolvConfFile may be more reliable, and would avoid race conditions. Of course, that doesn't change the resolver for the rest of your system. Tim > > -- > Jesse > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] assign_to_cpuworker failed. Ignoring.
> On 19 Oct. 2016, at 16:25, Felix wrote: > > Hi everybody > > May be someone can help with this warning: > > The security update (Tor v0.2.8.9 running on FreeBSD with Libevent > 2.0.22-stable, OpenSSL LibreSSL 2.4.3 and Zlib 1.2.8.) shows the following > log entry each hour: > > Oct 19 02:51:07.000 [warn] Your system clock just jumped 136 seconds forward; > assuming established circuits no longer work. > Oct 19 02:51:07.000 [warn] assign_to_cpuworker failed. Ignoring. > ... > Oct 19 02:51:07.000 [warn] assign_to_cpuworker failed. Ignoring. > Oct 19 02:51:15.000 [notice] Tor has successfully opened a circuit. Looks > like client functionality is working. > ... > Oct 19 03:51:10.000 [warn] Your system clock just jumped 138 seconds forward; > assuming established circuits no longer work. > Oct 19 03:51:11.000 [warn] assign_to_cpuworker failed. Ignoring. > ... > Oct 19 04:50:37.000 [warn] Your system clock just jumped 105 seconds forward; > assuming established circuits no longer work. > Oct 19 04:50:37.000 [warn] assign_to_cpuworker failed. Ignoring. > ... > Oct 19 05:51:14.000 [warn] Your system clock just jumped 142 seconds forward; > assuming established circuits no longer work. > Oct 19 05:51:15.000 [warn] assign_to_cpuworker failed. Ignoring. > ... > > The warning first appeared on 2.8.7 after update on September 13th (Tor > v0.2.8.7 running on FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL > 2.4.2 and Zlib 1.2.8.). That time I switched back (Tor v0.2.7.6 running on > FreeBSD with Libevent 2.0.22-stable, OpenSSL LibreSSL 2.4.2 and Zlib 1.2.8.) > and the warning disappeared. > > What can I do? > > The warning is reproted in tor-talk: > https:// lists.torproject.org/pipermail/tor-talk/2016-October/042425.html Thanks for reporting this issue - you could open a bug on our bug tracker under Core Tor/Tor: https://trac.torproject.org/projects/tor/newticket It would help us to know if it's just FreeBSD, or just LibreSSL. Maybe mention the bug number on tor-talk, so that poster can provide more details? Tim > > -- > Best regards, Felix > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] assign_to_cpuworker failed. Ignoring.
> On 19 Oct. 2016, at 16:46, Felix wrote: > > Thanks for picking up. > > > It would help us to know if it's just FreeBSD, or just LibreSSL. > It's both LibreSSL on FreeBSD 10.1. Same setup worked fine since months > through serveral versions of Tor (2.6.x and 2.7.x) and LibreSSL (2.2.x until > today). Ok, thanks. I suspect that it's LibreSSL, because my FreeBSD/OpenSSL and Linux/OpenSSL boxes don't have that issue in their logs. Tim > > > Maybe mention the bug number on tor-talk, so that poster can provide > more details? > Might be. > > -- > Felix > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] relay lost most of its consensus weight
> On 19 Oct. 2016, at 21:47, Tor User wrote: > > Tim thank you for the reply. Lots of good info in there. It is not good > news for me but at least now I understand. The main problem is likely > my ISP (TWC). Traceroutes are typical for TWC, you have to go through at > least 5-7 hops going anywhere before you get to leave their network This > is the same tor box we had at the other place when we had much much better > bandwidth measurement on our relay - reported bandwidth was a lot closer to > what I had the limits set to in torrc. > > Google fiber is in mid-deployment now in our neck of the woods but I think we > would probably have to move to be able to get it. The place we are now has a > contract with TWC and... it wouldn't surprise me if they signed a long term > contract, given the (ahem) quality of judgement we have seen demonstrated by > management since we have been here. Brand new apartment complex that is > falling apart, literally. For what it's worth, another relay operator on TWC was complaining about low bandwidth measurements today on IRC. Looks like the provider might be the common factor. Sorry we can't do much to help. Tim > > Thanks again. > > > > On 10/15/2016 09:08 PM, teor wrote: >>> On 14 Oct 2016, at 22:23, Tor User >>> wrote: >>> >>> I apologize for what is probably bad form in replying to an older thread >>> that has sort of fallen off, but I've been trying to figure out why I just >>> can't seem to get any consensus weight on our middle relay >>> (ByTORAndTheSnowDog). >>> >> I prefer context, and I prefer knowing you've read the old thread. >> >> >>> We moved in May to another city and have a different internet provider now. >>> We had gigabit symmetrical internet at the last place and I *get* that a >>> drop in bandwidth and consensus should be expected, but our internet >>> bandwidth here is not that bad. 300mbit down/20mbit up. >>> >>> Consensus weight is mostly a function of your upstream bandwidth, right? >>> >> Not quite, it's a function of your bandwidth to the bandwidth authorities, >> your latency to the bandwidth authorities, and the actual utilisation of your >> relay. The minimum of your downstream and upstream bandwidth can be used as >> a first approximation. >> >> >>> Do the bandwidth auth testers ever "get it wrong"? >>> >> Oh yes, they are consistently inaccurate, typically on a geographical or >> network basis. And they are somewhat random for individual servers over short >> timeframes. >> >> (The bandwidth authorities are in North America and Europe on 5 particular >> networks. If you're a long way from those networks, your measurements are >> lower than other servers with similar capacity.) >> >> We're working on some improvements right now. >> >> >>> I'm not sure where to look to see what kind of bandwidth is being measured >>> from us. >>> >> https://collector.torproject.org/recent/relay-descriptors/votes/ >> >> >> w Bandwidth=344 Measured=19 >> w Bandwidth=344 Measured=49 >> w Bandwidth=344 Measured=50 >> w Bandwidth=344 Measured=50 >> w Bandwidth=344 Measured=232 >> >> (low-)median: 50 >> >> We could make this easier for relay operators by showing the measured >> bandwidth >> in consensus health. >> >> https://trac.torproject.org/projects/tor/ticket/20372 >> >> >> >>> It seems unlikely however that we are only able to push out the paltry >>> rates I see in our atlas entries. >>> >> Your relay's observed bandwidth is exactly the rate seen in your atlas entry: >> >> http://24.74.79.53:9030/tor/server/authority >> https://atlas.torproject.org/#details/B735643D239170947669269A78F8478EC5343219 >> >> >> >>> These are the rate limiting-related settings I'm running in torrc: >>> >>> RelayBandwidthRate 2300 KB >>> RelayBandwidthBurst 2500 KB >>> >>> BandwidthRate 2300 KB >>> BandwidthBurst 2500 KB >>> >>> Not using any MaxAdvertisedBandwidth settings anymore -- I commented them >>> out a week or so ago at last restart after reading that you shouldn't set >>> these if you are looking to get more traffic. >>> >> You can reload tor's config using: >> kill -HUP `cat /var/run/tor.pid` >> >> Or the equivalent service co
Re: [tor-relays] IP address change
> On 24 Oct. 2016, at 23:12, balbea16 wrote: > > Hi There > My ISP changes my IP address about every 24 hours. It takes 10 minutes until > my tor server recognises this, and an hour until all usual connections are > reestablished. How can I speed this up? The tor directory authorities vote on relays every hour. There is no way to speed this up. > Does it help to use a DNS? No, Tor uses your IP address. > To pay for a static address is not an option. > Any ideas? Thank you. Mike I'm sorry, this is just how Tor is designed. But you are still contributing to the network. You could try renting a cheap server in a data centre. Most of them offer static IP addresses. Tim T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] cryptsetup some folders
> On 25 Oct. 2016, at 21:03, Duncan Guthrie wrote: > > Hi folks, > > I am not sure it is more secure. What are we trying to protect here? As long > as the relay is running,it is unencrypted. Disk encryption only prevents > physical access - are you at risk of this? At any rate, the relay shouldn't > be storing personal data. > > Having it encrypted also makes remote management an absolute pain. > > Can someone clarify this? I am not a lawyer, but I've heard that it helps to prove you have no personal data. This is harder when there is encrypted data on the machine. Tim > -- D > > On 24 October 2016 08:53:14 BST, Petrusko wrote: > Hey all, > > I'm planning to customise a RPi with Raspbian already running, and using > cryptsetup (LUKS) to have a partition more secure for some reasons... > So the goal is to move some existing sensitive folders to this new > encrypted partition. > Some sym-links will be used for those directories. > > About Tor, if I'm not wrong, those directories can be moved to this > encrypted partition : > /var/lib/tor : so I'm planning to move /var... > > So at final, planning to move : > /home > /var > /tmp > (why not swap file ?) > > Any suggestions and master's thoughts are welcome :) > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] cryptsetup some folders
> On 25 Oct. 2016, at 21:16, Toralf Förster wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 10/25/2016 12:03 PM, Duncan Guthrie wrote: >> >> Having it encrypted also makes remote management an absolute pain. > Depends on - an encrypted ext4fs needs just to be decrypted after boot as I > tried in [1]. > > And the use case is to avoid that the private key of the tor exit relay can > be accessed by somebody having physical access to the hard disk. ... while the machine is unpowered. If the machine is powered, physical access likely gives them physical access to the contents of memory as well. (Not just cold boot-style attacks, but DMA hardware as well.) Tim > > > [1] https://github.com/toralf/torutils/blob/master/unlock_tor.sh > > - -- > Toralf > PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7 > -BEGIN PGP SIGNATURE- > > iHYEAREIAB4FAlgPMQsXHHRvcmFsZi5mb2Vyc3RlckBnbXguZGUACgkQxOrN3gB2 > 6U46ZwD+O8iItKweJ9xC90enAgEA28Q0jqBw4wN5LMtMKz0o+XEBAIdP9oe7KKBh > AX5Qf4PQ2wUKB49Ut0Il2nBKOyA0C3bs > =4jom > -END PGP SIGNATURE- > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Rampup speed of Exit relay
> On 25 Oct. 2016, at 22:26, D.S. Ljungmark wrote: > > So, Now I've taken some steps to adjust the state of the relay, and > try to balance this. > > To reiterate a point previously, before I start adding more tor > daemons or servers to this, I want to know how to scale and optimise > what is already there. > > - Set up unbound in cache mode rather than use our local network unbound > - Disabled on machine firewall (stateful) > - Ensured AES acceleration worked > - Boosted amount of open files allowed even more > - Stopped doing regular reboots and only reboot on kernel change > - Bound Tor to a single core Tor is multi-process, so I wouldn't recommend binding it and its cpuworkers to the same core. That could degrade performance. > The exit is till this one: > https://atlas.torproject.org/#details/5989521A85C94EE101E88B8DB2E68321673F9405 > > CPU utilization of a single core on the machine never goes > 22% > > Thus while it may be CPU bound, it's never maximising the CPU usage. > > CPU and network are still scaling together with each other. > > Load ( not cpu usage) is fairly stable and load1 hasn't gone > 0.2 > > It's holding between 5k and 16k sockets in use, Having connections to 6000 relays is normal, and then there are more sockets for Exit traffic. > and ~3.5k sockets in > TIME_WAIT state. (Fairly high amount?) Quite normal for an Exit. > So far, I'm not sure _why_ it's capping itself on bandwidth, and > that's the one thing that I want to figure out before I start scaling > out horizontally. If you hover over the Advertised Bandwidth in atlas, your relay's advertised bandwidth is equal to its observed bandwidth. Your relay's observed bandwidth is listed as 19.98 MByte / second in its descriptor: http://193.15.16.4:9030/tor/server/authority The bandwidth authorities seem to think your relay can handle twice that, nominally 38100 KByte / second: https://consensus-health.torproject.org/consensus-health-2016-10-25-10-00.html#5989521A85C94EE101E88B8DB2E68321673F9405 (This is a large page) Last time we emailed, your relay's observed bandwidth was 19.83 MByte / second. This is suspiciously stable. Your observed bandwidth should vary a lot more. But it seems capped at 20 MByte / second. Perhaps your network link throttles traffic. Or, the throttling is happening via CPU limiting. Or, you have an option set that is limiting Tor's bandwidth usage directly. Did you ever try using chutney to measure your local bandwidth? That will tell you what your CPU is capable of. (Leaving you to distinguish between config and network.) Alternately, set up a relay with the same config at another provider. Or, set up a relay with the same config on the same machine. Or, set up a relay with a minimal config on the same machine. (Try commenting-out lines in the config one at a time. Start with RelayBandwidthRate and RelayBandwidthBurst.) But other relays achieve much faster speeds, so it's likely something unique to your situation. Tim > On Fri, Sep 23, 2016 at 11:28 AM, nusenu wrote: >>>>>>>>>>> So, how do we get tor to move past 100-200Mbit? Is it just a >>>>>>>>>>> waiting game? >>>>> >>>>> I'd say just run more instances if you still have resources left and >>>>> want to contribute more bw. >>>>> (obviously also your exit policy influences on how much your instance >>>>> is >>>>> used) >>> Mainly, I want to scale up a single exit first, before I start adding >>> more resources. >> >> As Aeris, teor and me tried to explain, this is _not_ about "adding more >> resources", but since you keep ignoring that it is a bit pointless to >> state that over and over again. >> >> teor gave some rather comprehensive answers and has said pretty much >> anything relevant I guess. >> >> In the end it should be about optimizing exit bandwidth cost (many >> MBit/s for fewer $) no matter how many tor processes it requires to get >> the most out of your hardware, number of available IPs and uplink >> connectivity. >> >>> It might well be that I've missed something, some tuning I should have >>> remembered ( Like increasing the conntrack hash table size ) >> >> I'm not sure I would run a stateful firewall on an dedicated exit server >> at all. >> https://www.torservers.net/wiki/setup/server >> >> >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-rela
Re: [tor-relays] cryptsetup some folders
> On 26 Oct. 2016, at 10:31, Mirimir wrote: > >> Any particular reason to let the mailing list know you have useful >> information but not share it here and make it available for future >> list archive searches? ;-) > > I'm assuming that the list doesn't accept attachments :) It turns them into links. They work fine. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Rampup speed of Exit relay
> On 27 Oct. 2016, at 00:32, D. S. Ljungmark wrote:
>
> On tis, 2016-10-25 at 22:52 +1100, teor wrote:
>>>
>>> On 25 Oct. 2016, at 22:26, D.S. Ljungmark
>>> wrote:
>>>
>>> So, Now I've taken some steps to adjust the state of the relay, and
>>> try to balance this.
>>>
>>> To reiterate a point previously, before I start adding more tor
>>> daemons or servers to this, I want to know how to scale and
>>> optimise
>>> what is already there.
>>>
>>> ...
>>> It's holding between 5k and 16k sockets in use,
>>
>> Having connections to 6000 relays is normal, and then there are more
>> sockets
>> for Exit traffic.
>
> Is 6k normal/high/low for an exit? I'm trying to find the cause of the
> low performance here.
6K - 7K is expected for any relay, as there are that many relays in the
network.
And then an Exit has a socket for every outgoing Internet connection as
well.
>>> and ~3.5k sockets in
>>> TIME_WAIT state. (Fairly high amount?)
>>
>> Quite normal for an Exit.
>
> check.
These are likely from short-lived outgoing Exit connections.
>> Or, the throttling is happening via CPU limiting.
>>
>> Or, you have an option set that is limiting Tor's bandwidth usage
>> directly.
>
> Not as far as I'm aware, the only one I've set on purpouse are
> BandwidthBurst / BandwidthRate, both to 92MB.
Clearly you're not hitting these, so you could turn them off.
> On 27 Oct. 2016, at 01:31, D. S. Ljungmark wrote:
>
> On ons, 2016-10-26 at 15:32 +0200, D. S. Ljungmark wrote:
>> On tis, 2016-10-25 at 22:52 +1100, teor wrote:
>>> ...
>>> Did you ever try using chutney to measure your local bandwidth?
>>> That will tell you what your CPU is capable of.
>>> (Leaving you to distinguish between config and network.)
>>
>> No, will do that now to see.
>
> Chutney in networks/basic-min mode gives me the following on a 500MB
> transfer
>
> Single Stream Bandwidth: 42.09 MBytes/s
> Overall tor Bandwidth: 168.38 MBytes/s
>
> Which seems to be in line with where I'd expect things to be CPU wise.
> Not optimum, but at least twice higher than what I see in reality.
You probably want the "Overall tor Bandwidth", which is the bandwidth
of the stream multiplied by the number of tor instances that it goes
through (4: client, guard, middle, exit).
It doesn't account for CPU usage by the python test harness, or the
latency in connection establishment, or any other processes on the
machine. So it will always read lower.
Have you tried monitoring the reliability of connections through your
Exit?
You can run a Tor client with "ExitNodes {fingerprint}", then use Tor
Browser through it. This would help you find out the error messages
clients are getting (if any).
You can also use this to do a bulk transfer test through your exit,
to see if it has any spare bandwidth.
It might also be worth checking what happens to the bandwidth usage
on your Exit over the day and week. A tool like vnstat or munin could
help here.
(Normally, the tor network has daily and weekly peaks.)
T
--
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
--
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Abuses: Suspicious botnet ramnit attack
> 2016-10-27 20:24 GMT+02:00 pa011 : >> Hi, >> >> got the abuse below on three different exits. Anybody having any idea what >> to do and how to possibly to stop this in the future? >> Thanks Paul >> >> >> CERT-EU has received information regarding an infected IP belonging to your >> network, which may have security problems. The information regarding the >> problems >> is also included as attachments in both CSV and XML formats. All timestamps >> are in >> UTC. >> At this time we do not have any more information. >> >> Where: >> - ASN: is the Autonomous System Number; >> - IP: the Internet Protocol address associated with this activity; >> - TIME: discovery time of the malicious activity; >> - PTR/DNAME: PTR/DNAME record >> - CC: ISO 3166-1 alpha-2 two-letter country code; >> - TYPE: type of the security problem or threat; >> >> - INFO: provides any additional information, if >> available.asn|ip|time|ptr|cc|type|info|info2 >> >> ASx|xxx.xxx.xxx.xxx|25-10-2016 12:10:09Z|XX|botnet drone|Description: >> Ramnit botnet victim connection to sinkhole details, Timestamp : >> 1477397409.72, City : none, Count: 8, First Seen: 25-10-2016 12:10:09, Last >> Seen: 25-10-2016 > On 28 Oct. 2016, at 09:33, Markus Koch wrote: > > No. Thats my problem too, around 90% of my abuse mails are bot related > and you cant do anything about it. If you know the destination IP address, and it's a bot Command & Control server, you could block it. The problem is, many use multiple C&C servers, some with dynamic DNS. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blocking Domains
> On 1 Nov. 2016, at 07:42, SuperSluether wrote: > > They give me the IP address to block. The problem is yesterday it was on > s01.panelboxmanager.com. Today it was s502.panelboxmanager.com. I was hoping > for a way to block all sub-domains of panelboxmanager.com to prevent further > abuse on that particular network. Guess I'll keep going per-IP for now. > > > On 10/31/2016 03:38 PM, Jason Jung wrote: >> You need to block them via IP address. Do a DNS lookup of the domain in >> question if the e-mail doesn't contain it. >> >> On Mon, Oct 31, 2016 at 07:55:43AM -0500, Tristan wrote: >>> Is it possible to block domain names in Tor's ExitPolicy? I've been getting >>> abuses on *.panelboxmanager.com, and I'd like to be proactive about this if >>> possible. If you run a local caching resolver, you can tell it not to answer requests for these domains. (Or, more precisely, answer them with NXDOMAIN.) And you should block the IP addresses for the netblock in your exit policy as well, so the blocking is at least somewhat transparent. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor bandwith question
> On 1 Nov. 2016, at 15:58, wrote: > > In order to clarify this once and for all: If I setup a Tor relay with 200 > kBps, do I slow down the Tor network? What amount of bandwith is needed in > order to not slow down the network? In order to get the Fast flag, you need a relay capable of 2 megabytes per second. Most clients won't use you for anything if you don't have the Fast flag, so you'll have minimal impact on the network. That said, each extra relay adds to the directory download overhead. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] manual vs. automated updates
> On 1 Nov. 2016, at 16:44, Greg wrote: > > Hi, > I'm very interested in setting up unattended upgrades for tor. I tried > searching for instructions on how to do it. But the only instructions I could > really find didn't work (on the Library Freedom git project). > How do I write the config so that the tor repo (or whatever it's called) is > updated by unattended upgrades? If you are using Debian or Ubuntu (or apt): 1. Modify your sources.list to include the tor repository https://www.torproject.org/docs/debian.html.en 2. Modify Debian: Unattended-Upgrade::Origins-Pattern Ubuntu: Unattended-Upgrade::Allowed-Origins to include the packages you want updated: $EDITOR /etc/apt/apt.conf.d/50unattended-upgrades Tim > Thanks. > > > On Oct 26, 2016 1:23 AM, "nusenu" wrote: > > 32 relays updated (Debian + Tor compiled to latest version) > > > > I am getting too old for this without a server management system > > not all relays with your contactinfo seem to be updated properly > doing it manually is slow and error prone. > Maybe consider using the 'unattended-upgrades' package? > > (only found 28 relays) > > +-+-++ > | version | nickname| restarted | > +-+-++ > | 0.2.8.7 | niftychipmunk | 2016-10-26 | > | 0.2.8.7 | niftymouse | 2016-10-26 | > | 0.2.8.7 | niftygerbil | 2016-10-26 | > | 0.2.8.7 | niftyquokka | 2016-10-26 | > | 0.2.8.9 | testnode2 | 2016-10-23 | > | 0.2.8.9 | DOESaDEworkWITHtor1 | 2016-10-20 | > | 0.2.8.9 | niftypedetes| 2016-10-26 | > | 0.2.8.9 | niftyeuropeanrabbit | 2016-10-26 | > | 0.2.8.9 | niftychinchilla | 2016-10-26 | > | 0.2.8.9 | 2ndTRYdeEXIT| 2016-10-20 | > | 0.2.8.9 | niftysugarglider| 2016-10-26 | > | 0.2.8.9 | niftyvolcanorabbit | 2016-10-26 | > | 0.2.8.9 | niftyrat| 2016-10-26 | > | 0.2.8.9 | niftypatagonianmara | 2016-10-25 | > | 0.2.8.9 | niftywoodmouse | 2016-10-25 | > | 0.2.8.9 | niftysquirrel | 2016-10-25 | > | 0.2.8.9 | mullahspinymouse| 2016-10-26 | > | 0.2.8.9 | niftybankvole | 2016-10-25 | > | 0.2.8.9 | capespinymouse | 2016-10-26 | > | 0.2.8.9 | niftyhedgehog | 2016-10-25 | > | 0.2.8.9 | niftycapybara | 2016-10-26 | > | 0.2.8.9 | testnode| 2016-10-23 | > | 0.2.8.9 | cairospinymouse | 2016-10-26 | > | 0.2.8.9 | niftykangaroorat| 2016-10-25 | > | 0.2.8.9 | niftypika | 2016-10-26 | > | 0.2.8.9 | niftyjerboa | 2016-10-26 | > | 0.2.8.9 | niftyguineapig | 2016-10-26 | > | 0.2.8.9 | niftycottontail | 2016-10-26 | > +-+-++ > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor bandwith question
> On 1 Nov. 2016, at 23:12, Louie Cardone-Noott wrote: > > On Tue, 1 Nov 2016, at 11:42 AM, teor wrote: >> >>> On 1 Nov. 2016, at 15:58, wrote: >>> >>> In order to clarify this once and for all: If I setup a Tor relay with 200 >>> kBps, do I slow down the Tor network? What amount of bandwith is needed in >>> order to not slow down the network? >> >> In order to get the Fast flag, you need a relay capable of 2 megabytes >> per >> second. Most clients won't use you for anything if you don't have the >> Fast >> flag, so you'll have minimal impact on the network. > > Do you mean 2 megabit/s? > > Last time I checked 2 Mbps was the minimum for Fast, i.e. 256 KBps. Note > the differing units. I ran a 2 Mbit relay from home for a while and it > got the Fast flag. Oops, you're right, Fast is 100 KByte/second, Guard is 2 MByte/second. To get the fast flag, you also need to be in the top 7/8ths fastest relays. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blocking Domains
> On 2 Nov. 2016, at 01:54, SuperSluether wrote: > > So, I tried putting the IPs into my exit policy like this: > > xx.xx.xx.xx-xx.xx.xx:* > > But Tor doesn't like that syntax. What's the correct way to block address > ranges in the exit policy? The man page is your friend: ExitPolicy policy,policy,... Set an exit policy for this server. Each policy is of the form "accept[6]|reject[6]ADDR[/MASK][:PORT]". If /MASK is omitted then this policy just applies to the host given. PORT can be a single port number, an interval of ports "FROM_PORT-TO_PORT", or "*". If PORT is omitted, that means "*". -- > > On 11/01/2016 07:32 AM, Ralph Seichter wrote: >> On 01.11.2016 12:56, hwertiout695 wrote: >> >>> https://whois.arin.net/rest/org/PANEL-2/nets [...] >> This appears to be the most comprehensive list of assigned networks >> I have seen so far for panelboxmanager.com; thank you. >> >> -Ralph >> ___ >> tor-relays mailing list >> tor-relays@lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] assign_to_cpuworker failed. Ignoring.
> On 2 Nov. 2016, at 01:56, Felix wrote: > ... > > My log says: > Oct 19 01:04:52.527 [notice] Read configuration file > "/usr/local/etc/tor/torrc". > Oct 19 01:04:52.566 [notice] Opening OR listener on 0.0.0.0:1234 > for > ORPort 443 NoListen > ORPort 1234 NoAdvertise > My Tor finds 0.0.0.0 and looks further out ... > > I see yours telling: > Oct 31 22:48:44.752 [notice] Opening OR listener on a.b.c.d:9021 > > Hm. Can you please share your torrc line for the "ORPort [address:]PORT|auto > [flags]" directive? Can you give an example which is your a.b.c.d, is it the > external or a local (lo#) and how do you set NoListen/NoAdvertise ? I want to > avoid Tor guessing the ip. To set the public IPv4 address in your descriptor, use Address: Address IPv4 Otherwise, Tor will guess your address. To set the public IPv6 address in your descriptor, use the first IPv6 ORPort: ORPort [IPv6]:Port Otherwise, Tor will not advertise your IPv6 address. To set an ORPort on an address that's on the host, use: ORPort IP:Port To set a public ORPort on an address that's on a middlebox, use: ORPort IP:Port NoListen To set a private ORPort on an address that's not public, use: ORPort IP:Port NoAdvertise T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blocking Domains
> On 2 Nov. 2016, at 02:01, Tristan wrote: > > So what mask would I use then? I've been trying to wrap my head around it, > but I just don't understand what /24 means, or how it's different from /27 or > any other number. You have a list in IP-IP (IP range) format, and you want to convert it into IP/Mask (CIDR) format. Here is a tool that will do that: http://ipaddressguide.com/cidr If you want to learn more, or check the tool's work: https://en.wikipedia.org/wiki/CIDR_notation > On 2 Nov. 2016, at 02:06, Tristan wrote: > > Wow this is confusing. If I'm understanding this correctly, 0.0.0.0/24 would > mean any address from 0.0.0.0 to 0.0.0.255, correct? Yes. Imagine each of the numbers in an IPv4 address is a byte. Put them together, you have 32 bits. Count each bit starting from 1, and when you reach the mask number, the IP range is all the possible combinations of all the remaining bits. Tim > On Nov 1, 2016 9:58 AM, "teor" wrote: > > > On 2 Nov. 2016, at 01:54, SuperSluether wrote: > > > > So, I tried putting the IPs into my exit policy like this: > > > > xx.xx.xx.xx-xx.xx.xx:* > > > > But Tor doesn't like that syntax. What's the correct way to block address > > ranges in the exit policy? > > The man page is your friend: > >ExitPolicy policy,policy,... >Set an exit policy for this server. Each policy is of the form >"accept[6]|reject[6]ADDR[/MASK][:PORT]". If /MASK is omitted then >this policy just applies to the host given. > >PORT can be a single port number, an >interval of ports "FROM_PORT-TO_PORT", or "*". If PORT is omitted, >that means "*". > > -- > > > > On 11/01/2016 07:32 AM, Ralph Seichter wrote: > >> On 01.11.2016 12:56, hwertiout695 wrote: > >> > >>> https://whois.arin.net/rest/org/PANEL-2/nets [...] > >> This appears to be the most comprehensive list of assigned networks > >> I have seen so far for panelboxmanager.com; thank you. > >> > >> -Ralph > >> ___ > >> tor-relays mailing list > >> tor-relays@lists.torproject.org > >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > ___ > > tor-relays mailing list > > tor-relays@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > T > > -- > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > -- > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Guard before Stable flag?
> On 2 Nov. 2016, at 23:42, John Ricketts wrote: > > Hello Everyone, > > When looking at my list on Atlas (21 entries) I'm seeing that some of my > relays are getting the Guard flag before they become stable. > > https://atlas.torproject.org/#search/quintex > > I'm going to make the assumption this is normal behavior but I still find it > odd. > > I also find it odd that I haven't received the stable flag all of the relays > given their uptime. Thoughts, anyone? There's a known bug with the Stable flag where downtime has a greater impact the longer the relay has been up. It really should be the other way around. Ideally, we want any previous uptime to be better than switching relay identities. Otherwise, a new relay is better than one with history. (Which is sometimes how it works at the moment.) Or, perhaps we want to assume that new relays will have the network average uptime. So any uptime that's better than average should improve your relay's chances of getting the Guard flag. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Drop in consensus weight
> On 8 Nov. 2016, at 22:52, r1610091651 wrote: > > Hi all > > The consensus weight of the relay I'm running drop recently (5th of nov) to > almost half of previous value. To my knowledge there was no changes on my end. > > https://atlas.torproject.org/#details/36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE If you look at the 1 month graph, this does not seem to be unusual for your relay. > Is there a way to identify the cause of this drop? The bandwidth authorities measured your relay as being able to handle approximately 2490 KByte/s. (High 4370, Low 1410, Median 2490.) (large page) https://consensus-health.torproject.org/consensus-health-2016-11-08-11-00.html#36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE Your relay's observed bandwidth is also 2.39 MByte/s (hover over the bandwidth heading in atlas for these details), so its consensus weight will be limited to approximately ~2447 (KByte/s) anyway. If you want to increase these measurements, try increasing the BandwidthRate and BandwidthBurst in your relay's torrc, and waiting a week. > Is there anyone else in same situation? The system is functioning as designed: your relay's observed maximum bandwidth is almost identical to the bandwidth measured by the bandwidth authorities. If you want to fix this, add more bandwidth. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Drop in consensus weight
> On 8 Nov. 2016, at 23:15, Markus Koch wrote: > > https://atlas.torproject.org/#details/B771AA877687F88E6F1CA5354756DF6C8A7B6B24 > > the same, others are perfectly fine. no clue why :/ (This conversation might make more sense if you replied below the original email, which is known as bottom-posting.) >> Is there a way to identify the cause of this drop? > > The bandwidth authorities measured your relay as being able to handle > approximately 9960 KByte/s (High 17500, Low 5470, Low-Median 9960.) > (large page) https://consensus-health.torproject.org/consensus-health-2016-11-08-11-00.html#B771AA877687F88E6F1CA5354756DF6C8A7B6B24 > Your relay's observed bandwidth is also 12.37 MByte/s > (hover over the > bandwidth heading in atlas for these details), so its consensus weight > will be limited to approximately ~12667 > (KByte/s) anyway. > > If you want to increase these measurements, try increasing the actual traffic your relay can handle. >> Is there anyone else in same situation? > > The system is functioning as designed: your relay's observed maximum > bandwidth is approximately the same as > the bandwidth measured by the bandwidth > authorities. > > If you want to fix this, add more bandwidth. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Drop in consensus weight
> On 8 Nov. 2016, at 23:32, r1610091651 wrote: > > The previous drops, i know why they happened (related to server > unavailability) so I know the cause. For 5th however I have no clue. As far as I can tell, the relay is accurately measured. Sometimes, this means that you get a lower measurement than you might have had before. Accurate bandwidth measurements are a good thing for tor users, even if the changes in the measurement are sometimes (temporarily) disappointing to relay operators. If you want to improve the measurements, try adding more bandwidth. For your relay, this means increasing BandwidthRate and BandwidthBurst. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Automatic IPv6 address detection in Tor
> On 9 Nov. 2016, at 05:40, diffusae wrote: > > Hi! > > Is this already solved in 0.2.8.9-1 for addresses with global scope? > > https://trac.torproject.org/projects/tor/ticket/17153 No, that's a ticket related to private IPv6 addresses on test networks. You want this one, which is not fixed: https://trac.torproject.org/projects/tor/ticket/5940 > I was trying to configure a global reachable IPv6 address, but getting > the following error: > > "unable to use configured ipv6 address "[::]" in a descriptor." > > The only way ist to set a clear global address in the config. Yes, the only way to have an IPv6 ORPort is for the operator to explicitly configure an ORPort with a globally routable IPv6 address. Address autodetection is error-prone. IPv4 address autodetection is the source of many accidental misconfigurations by relay operators. IPv6 autodetection would be worse, because relays don't ever use IPv6 to connect to directory servers or other relays, so they would have to scan their local interfaces, and pick an arbitrary IPv6 address. This doesn't work well in the IPv4 case, so it really is better for operators to select a routable IPv6 address. > The ISP is changing the 64 bit prefix a bit from time to time and I > don't want to configure it manually every two weeks or so. It probably is best to avoid configuring IPv6, or get a better ISP. (There's no reason for an ISP to change prefixes for IPv6, they should have plenty of address space. Sounds like they're treating it just like IPv4.) T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor relay balks with "router_pick_published_address(): Success: chose address x.x.x.x"
> On 9 Nov. 2016, at 09:00, Tobias Sachs wrote: > > Hey, > > my Tor relay > https://atlas.torproject.org/#details/B567E8E39641F61091C1F2CAAAF73D3D1BF9CFE1 > balks with the following message which is repeated in the log with the > "info" logging level up to 23251 times at the exact same millisecond. I assume you are talking about the router_pick_published_address message. > The relay responds at :9030/tor/server/authority with a 503 error. This is a temporary error when your relay is overloaded. I just tried http://167.114.245.102:9030/tor/server/authority and it delivered the descriptor fine, with no error. I logged a ticket: Relays should log a message when they return a 503 error to a client https://trac.torproject.org/projects/tor/ticket/20611 > router_pick_published_address(): Success: chose address 'x.x.x.x' This message is not an error, it is a success. But I can see how it would be annoying: Rate limit router_pick_published_address log message https://trac.torproject.org/projects/tor/ticket/20610 > This is a counting from the log with the corresponding timestamp. > > Nov 01 18:37:13.000 - 23251 > Nov 01 18:37:22.000 - 59 > Nov 01 18:38:17.000 - 23195 > Nov 01 18:38:22.000 - 57 > Nov 01 19:19:22.000 - 50 > Nov 01 19:19:23.000 - 312 > Nov 01 19:19:24.000 - 333 > Nov 01 19:19:25.000 - 74 > Nov 01 19:20:22.000 - 52 > Nov 01 19:38:17.000 - 23207 > Nov 01 20:38:17.000 - 23232 > > 140 times exactly 49 repeats in around 2 hours. > > Interesting is that there is no error about this 503 error in the log > only my monitoring is aware of the issue. > > I hope you coul'd help me out with this issue. Maybe you should turn your log level down to notice? The less you log, the better. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Drop in consensus weight
(It really would help if you posted your replies below the previous reply.) > On 9 Nov. 2016, at 10:07, r1610091651 wrote: > > Based on found numbers, some thoughts: > * shouldn't there be more authority servers? DNS system has 13 root servers > spread over the globe… There are 5 bandwidth authorities, we're working on getting more. > * not all authority servers are equal: > ** reported data varies greatly between servers > https://consensus-health.torproject.org/consensus-health-2016-11-08-19-00.html#36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE: > maatuska=1400 <> gabelmoo=4060 Yes, the speed measured by a bandwidth authority depends on: * location of the bandwidth authority, * time of measurement, * randomly chosen relay pair, * latency and bandwidth through that pair to the remote download site, * other load on the bandwidth authority and relays at the time. In general, the further away your relay is from the bandwidth authority, the lower the measurement will be. > ** some authorities vary greatly in reported data: > https://consensus-health.torproject.org/consensus-health-2016-11-08-19-00.html#36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE: > gabelmoo=4060 > https://consensus-health.torproject.org/consensus-health-2016-11-08-18-00.html#36EE8D47E570B8D5515460A9972F3CFD9EDFDFCE: > gabelmoo=2110 Yes, measurements are timing and load dependent. > * authority participating in consensus change, and with only few active (4-5) > at a time, impact of a single authority on network is amplified This is why the median is used. > By having more servers > * consensus would be more stable (low-median) > * leading to more accurate assessment of nodes > * and wider utilisation of the available nodes > * leading to higher network throughput > > Does that sound plausible? The first two, yes, the last two, perhaps. Maybe lower latency is more important than throughput? But each bandwidth authority uses bandwidth that would otherwise be available to clients. So there is a tradeoff. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Automatic IPv6 address detection in Tor
> On 10 Nov. 2016, at 09:17, diffusae wrote: > > Hi, > > I didn't read this to the end: > > https://trac.torproject.org/projects/tor/ticket/18387 > > "Just so you know, we want to implement this enhancement in the next > release (0.2.9)." > > So, hopefully 0.2.9 stable will be released soon. This feature will not be in 0.2.9. It was something we wanted to do 8 months ago, but no-one actually worked on it, so the ticket was triaged out of 0.2.9. You can watch here for any progress: https://trac.torproject.org/projects/tor/ticket/5940 T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Automatic IPv6 address detection in Tor
> On 10 Nov. 2016, at 10:12, diffusae wrote: > > Hi! > > Thanks a lot for you reply. > > On 08.11.2016 22:56, teor wrote: > ... > >> You want this one, which is not fixed: >> https://trac.torproject.org/projects/tor/ticket/5940 > > Maybe it will be fixed or something in this direction. No-one is working on it, as far as I know. >> Address autodetection is error-prone. > > That sounds logical. Also, if you have configured IPv6 privacy extensions. That just changes the IPv6 address selected by the OS. I can't see how it's relevant - unless you have *not* configured privacy extensions, and so autodetection exposes your MAC address to the world. >> IPv4 address autodetection is the source of many accidental >> misconfigurations by relay operators. > > Especially, if you are behind a CGN and your ISP DNS returns an private > IPv4 address. No, Tor ignores private addresses during autodetection, and relies on other relays to provide the external address. This only works for IPv4, because relays almost always use IPv4. >> ... T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Automatic IPv6 address detection in Tor
> On 11 Nov. 2016, at 05:39, diffusae wrote: > > Hello, > > thanks for your help. > > On 10.11.2016 02:31, teor wrote: > >> No-one is working on it, as far as I know. > > All right, now I see. It's a "nice to have feature", but I don't rely on > it. If it disturbs, than I will find a solution. The other drawback of autodetection is that if we turned it on by default, operators with broken IPv6 configs might find their relays being excluded from the consensus because they are unreachable on IPv6. We'd have to teach Tor to test IPv6 reachability, and stop advertising IPv6 if it was unreachable. But this is counted as an address change by OnionOO, so it has flow-on effects in systems that analyse relay stability. It's quite a challenge to get this right. >> That just changes the IPv6 address selected by the OS. >> >> I can't see how it's relevant - unless you have *not* >> configured privacy extensions, and so autodetection >> exposes your MAC address to the world. > > The second point might only be relevant to me in this case with a bad > ISP. I am using SLAAC and can't change the MAC address, due to a driver > bug. And that's only if you haven't fixed IP addresses or such strange > kind of dynamically created address space. > >> No, Tor ignores private addresses during autodetection, and >> relies on other relays to provide the external address. > > Ahh, that's good to know, than it also ignores the Shared Address Space > for use in ISP CGN: 100.64.0.0/10. As I remember it was recognized, but > I've used FQDNs with the Address option. Does autodetection take really > longer, than to configure a static IP address? Some autodetection options resolve hostnames using DNS, or wait for directory documents to download. So yes, it takes longer. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Questions regarding arm on Debian
> On 11 Nov. 2016, at 05:27, Dennis Christ wrote: > > Hi, > > i have installed a new relay on Debian 8 and playing around with the arm tool. > > ... > > > 2. Issue: It always says this message in the arm logs even if the service is > just started a moment ago. If i reload the config it says the same thing > shortly after. > > 17:18:59 [ARM_WARN] The torrc differs from what tor's using. You can issue a > sighup to reload the torrc values by pressing x. > - torrc values differ on lines: 118, 127 What is on lines 118 and 127? This could be a bug in Tor, where it changes the options it would write out, (if you asked it to write out your torrc file) rather than changing its internal idea of those options. Please log a ticket under Core Tor / Tor with the names of those options at: https://trac.torproject.org/projects/tor/newticket > 3. Issue: I dont understand this message. Nickname is edited by me so it does > not match its default value. Also why is it unneeded? > > 17:18:59 [ARM_NOTICE] Unneeded torrc entries found. They've been highlighted > in blue on the torrc page. > - entry matches its default value: Nickname (line 117) What is on line 117? This could be a bug in Tor, or it could be a bug in arm. The default nickname is NULL, which gets changed to "Unnamed" on relays. So if your nickname is different to "Unnamed", log a bug against Core Tor / Nyx (the new name for arm). https://trac.torproject.org/projects/tor/newticket And please also log a ticket under Core Tor / Tor saying that we are modifying Nickname from its default value, and writing it out again, rather than modifying our idea of it internally. https://trac.torproject.org/projects/tor/newticket T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Fails to Start on Ubuntu 16.04
> On 13 Nov. 2016, at 12:17, heartsucker wrote: > > Hey everyone > > I have a fresh install of Ubuntu 16.04 that is unable to start Tor. > > Some useful output: > > root@tor-1 ~ # uname -a > Linux tor-1 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:39:52 UTC 2016 > x86_64 x86_64 x86_64 GNU/Linux > root@tor-1 ~ # apt-cache policy tor > tor: > Installed: 0.2.8.9-1~xenial+1 > Candidate: 0.2.8.9-1~xenial+1 > Version table: > *** 0.2.8.9-1~xenial+1 500 >500 http://deb.torproject.org/torproject.org xenial/main amd64 > Packages >100 /var/lib/dpkg/status > root@tor-1 ~ # journalctl -u tor > ... > Nov 13 00:52:39 tor-1 systemd[1]: Starting Anonymizing overlay network > for TCP (multi-instance-master)... > Nov 13 00:52:39 tor-1 systemd[1]: Started Anonymizing overlay network > for TCP (multi-instance-master). > > > Tor fails to get beyond this message for any config I have tried > (including the default). I tried replacing the systemd unit file with > one of my own and was able to start Tor, however it would crash every 5 > minutes (though the logs. The commands used in the systemd file and the > command init.d script are both able to start Tor correctly if I run them > in a TTY as I can see from a second terminal. > > Is anyone else running Tor on Xenial, and if so, have they run into this > problem? Do you have apparmor installed? If so, what are the logs? In any case, what does Tor try to do every 5 minutes? (Look at the info or debug logs.) T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] obfs4 - how to from source
> On 15 Nov. 2016, at 21:41, Petrusko wrote: > > Hey! > > Coming here to take some good tips about obfs4 compil from source... > Not enough time since > http://archives.seul.org/or/relays/Jul-2016/msg00101.html > Now it's ok to try another time ! > > On the Raspbian set up, I've started with : > apt-get install git golang-go golang-go.crypto-dev golang-go.net-dev > golang-goptlib-dev golang-ed25519-dev golang-siphash-dev > > After this, with root account : > go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy Try not using root. > Result is : > package git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy: cannot > download, $GOPATH not set. For more details see: go help gopath > > I've tried many things, GOPATH=/home/petrusko and may be > GOPATH=/home/petrusko/obfs4 > Tried too to clone git with git clone > https://git.torproject.org/pluggable-transports/obfs4.git > > And now I'm lost with this GOPATH problem ! $ go help gopath ... Here's an example directory layout: GOPATH=/home/user/gocode ... Try using GOPATH=/home/petrusko/gocode And running go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy As user petrusko. Tim > Is there a wiki explaining how to compil/install this obfs4proxy from source. > I've found nothing about it... > > From readme, I don't understand this... > To build: > `go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy` > > To install: > Copy `$GOPATH/bin/obfs4proxy` to a permanent location (Eg: `/usr/local/bin`) > > > > Many thx for help :) > > -- > Petrusko > EBE23AE5 > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] obfs4 - how to from source
> On 15 Nov. 2016, at 23:53, Petrusko wrote: > > Thx Tim for help. > > Now I'm using another user than root... > But I'm still in a black hole (+headache), sadly without finding any document > about how using this "go" software + obfs4 :'( > > Sooory, I'm not really nice with source compiling... :s go will set up the directories in the GOPATH for you. You do not need to do anything to set them up yourself. Please run the following commands as the normal user petrusko: mv /home/petrusko/gocode /home/petrusko/gocode.old mkdir /home/petrusko/gocode export GOPATH=/home/petrusko/gocode go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy What does it say when you run those commands? Tim > > > go help gopath : > [...] > Each directory listed in GOPATH must have a prescribed structure: > > The src/ directory holds source code. The path below 'src' > determines the import path or executable name. > > The pkg/ directory holds installed package objects. > As in the Go tree, each target operating system and > architecture pair has its own subdirectory of pkg > (pkg/GOOS_GOARCH). > [...] > > But I don't see any /src or /pkg in the downloaded git folder ? > > Here the content downloaded : > $ dir -R /home/petrusko/obfs4/ > > obfs4/: > ChangeLog common docLICENSE obfs4proxy README.mdtransports > > obfs4/common: > csranddrbg log ntor probdist replayfilter socks5 uniformdh > > obfs4/common/csrand: > csrand.go > > obfs4/common/drbg: > hash_drbg.go > > obfs4/common/log: > log.go > > obfs4/common/ntor: > ntor.go ntor_test.go > > obfs4/common/probdist: > weighted_dist.go weighted_dist_test.go > > obfs4/common/replayfilter: > replay_filter.go replay_filter_test.go > > obfs4/common/socks5: > args.go args_test.go rfc1929.go socks5.go socks_test.go > > obfs4/common/uniformdh: > uniformdh.go uniformdh_test.go > > obfs4/doc: > obfs4proxy.1 obfs4-spec.txt > > obfs4/obfs4proxy: > obfs4proxy.go proxy_http.go proxy_socks4.go pt_extras.go termmon.go > termmon_linux.go > > obfs4/transports: > base meekliteobfs2 obfs3 obfs4 scramblesuit transports.go > > obfs4/transports/base: > base.go > > obfs4/transports/meeklite: > base.go meek.go > > obfs4/transports/obfs2: > obfs2.go > > obfs4/transports/obfs3: > obfs3.go > > obfs4/transports/obfs4: > framing handshake_ntor.go handshake_ntor_test.go obfs4.go packet.go > statefile.go > > obfs4/transports/obfs4/framing: > framing.go framing_test.go > > obfs4/transports/scramblesuit: > base.go conn.go handshake_ticket.go handshake_uniformdh.go hkdf_expand.go > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] obfs4 - how to from source
> On 16 Nov. 2016, at 00:12, Petrusko wrote: > > >> Please run the following commands as the normal user petrusko: >> >> mv /home/petrusko/gocode /home/petrusko/gocode.old >> mkdir /home/petrusko/gocode >> export GOPATH=/home/petrusko/gocode >> go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy >> >> What does it say when you run those commands? >> >> Tim > Thx! > It looks like better, > Here is the result of the last command line : > $ go get git.torproject.org/pluggable-transports/obfs4.git/obfs4proxy > # github.com/dchest/siphash > gocode/src/github.com/dchest/siphash/blocks_arm.s:2 5a: No such file or > directory: textflag.h > # golang.org/x/crypto/poly1305 > gocode/src/golang.org/x/crypto/poly1305/sum_arm.s:8 5a: No such file or > directory: textflag.h textflag.h is an internal go header. https://golang.org/src/runtime/textflag.h Maybe your go install is broken, or you need the go dev packages? Maybe your version of go is too old? Maybe your compiler doesn't work with go? I really don't know if I can help - I don't know enough about go. These seem vaguely related: https://github.com/derekparker/delve/issues/56 https://stackoverflow.com/questions/28265225/go-get-sys-textflag-h-missing Tim > There is new content inside the /home/petrusko/gocode ... > I see /pkg + /src inside. > > -- > Petrusko > EBE23AE5 > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] DoS from my tor guard VPS
> On 16 Nov. 2016, at 07:57, Pascal Terjan wrote: > > On 15 November 2016 at 20:41, Arisbe wrote: >> One of my tor guard relays is a medium size VPS operating in the Czech >> Republic. It's been up and stable for several years. Several weeks ago I >> was notified that my VPS was a source of UDP DoS traffic. It was shut down. >> Logs showed no intrusions. >> >> I installed a different instance of linux, changed my SSH port, added >> fail2ban and even installed clamav. I did not make changes to the tor exit >> policy. Then, this week I received the following: >> >> "Hello, >> surveillance system detected a disproportionate outgoing DoS traffic on your >> VPS torexitcz and then our network under a DDoS attack. Your server >> torexitcz has been stopped. This is another problem with your VPS. Your >> service will be terminated. >> Thanks for understanding." >> >> Can anyone offer an opinion as to how my relay was used for DoS? How can I >> avoid this in the future? My goal, as always is to provide stable nodes to >> the tor network while protecting myself and my VPS supplier. >> >> 4061C553CA88021B8302F0814365070AAE617270 >> 185.100.85.101 > > Your relay allows exit, and based on the name that seems intentional > If you don't want it to possibly be used for attacks, you should not run an > exit Tor Exits only produce one kind of UDP traffic: DNS requests on behalf of clients. If you were using the provider's DNS servers directly, this could look like a DoS attack, particularly if the DNS servers are under-provisioned (or the intrusion detection system too sensitive). Install a caching resolver on your relay, accessible only from localhost, and either edit /etc/resolv.conf, or use the ServerDNSResolvConfFile torrc option. (Editing /etc/resolv.conf can be unreliable, because some processes overwrite it using DHCP data. It's probably best to use a separate file and ServerDNSResolvConfFile.) If your provider is that sensitive about DNS traffic, it might be best to point your resolver at some other public DNS servers. But please don't use Google, they see too much Tor DNS traffic already. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bug Log
> On 19 Nov. 2016, at 09:52, Kevin Zvilt wrote: > > 11/18/2016 17:28:08 PM.600 [NOTICE] Bootstrapped 85%: Finishing handshake > with first hop > 11/18/2016 17:28:08 PM.900 [NOTICE] Bootstrapped 90%: Establishing a Tor > circuit > 11/18/2016 17:28:10 PM.300 [NOTICE] Tor has successfully opened a circuit. > Looks like client functionality is working. > 11/18/2016 17:28:10 PM.300 [NOTICE] Bootstrapped 100%: Done > 11/18/2016 17:28:11 PM.700 [NOTICE] New control connection opened from > 127.0.0.1. > 11/18/2016 17:28:11 PM.700 [NOTICE] New control connection opened from > 127.0.0.1. > 11/18/2016 17:32:25 PM.200 [NOTICE] Closing no-longer-configured Socks > listener on 127.0.0.1:9150 > 11/18/2016 17:32:25 PM.200 [NOTICE] DisableNetwork is set. Tor will not make > or accept non-control network connections. Shutting down all existing > connections. > 11/18/2016 17:32:25 PM.200 [NOTICE] Closing old Socks listener on > 127.0.0.1:9150 > 11/18/2016 17:32:25 PM.200 [NOTICE] Delaying directory fetches: > DisableNetwork is set. > 11/18/2016 22:38:05 PM.400 [NOTICE] Bootstrapped 85%: Finishing handshake > with first hop > 11/18/2016 22:38:06 PM.400 [NOTICE] Bootstrapped 90%: Establishing a Tor > circuit > 11/18/2016 22:38:06 PM.600 [NOTICE] Closing no-longer-configured Socks > listener on 127.0.0.1:9150 > 11/18/2016 22:38:06 PM.600 [NOTICE] DisableNetwork is set. Tor will not make > or accept non-control network connections. Shutting down all existing > connections. > 11/18/2016 22:38:06 PM.600 [NOTICE] Closing old Socks listener on > 127.0.0.1:9150 > 11/18/2016 22:38:07 PM.200 [NOTICE] Delaying directory fetches: > DisableNetwork is set. Hi, Can you help us understand what the problem is? You might need to use "Log info file info.log" or "Log debug file debug.log" to get enough detail for us to help you. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Bug Log
> On 19 Nov. 2016, at 10:32, Kevin Zvilt wrote: > > Hello! Thank you for replying, I had little hope to be answered. > The proxy server is refusing connections. Tor quits every few seconds of > launching. I think it stays running but the connection gets lost. > What I'm getting now is 'The proxy server is refusing connections'. Can you > please help me? And also, can you take me through setting up an onion server? > I'm trying to reach a .onion website. I'm sorry, this list is not for Tor client technical support. Maybe try the Tor Browser user manual? https://blog.torproject.org/blog/announcing-tor-browser-user-manual To get started:: https://tb-manual.torproject.org/windows/en-US/first-time.html https://tb-manual.torproject.org/windows/en-US/troubleshooting.html And for onion services: https://tb-manual.torproject.org/windows/en-US/onion-services.html Tim > > On Sat, Nov 19, 2016 at 1:21 AM, teor wrote: > > > On 19 Nov. 2016, at 09:52, Kevin Zvilt wrote: > > > > 11/18/2016 17:28:08 PM.600 [NOTICE] Bootstrapped 85%: Finishing handshake > > with first hop > > 11/18/2016 17:28:08 PM.900 [NOTICE] Bootstrapped 90%: Establishing a Tor > > circuit > > 11/18/2016 17:28:10 PM.300 [NOTICE] Tor has successfully opened a circuit. > > Looks like client functionality is working. > > 11/18/2016 17:28:10 PM.300 [NOTICE] Bootstrapped 100%: Done > > 11/18/2016 17:28:11 PM.700 [NOTICE] New control connection opened from > > 127.0.0.1. > > 11/18/2016 17:28:11 PM.700 [NOTICE] New control connection opened from > > 127.0.0.1. > > 11/18/2016 17:32:25 PM.200 [NOTICE] Closing no-longer-configured Socks > > listener on 127.0.0.1:9150 > > 11/18/2016 17:32:25 PM.200 [NOTICE] DisableNetwork is set. Tor will not > > make or accept non-control network connections. Shutting down all existing > > connections. > > 11/18/2016 17:32:25 PM.200 [NOTICE] Closing old Socks listener on > > 127.0.0.1:9150 > > 11/18/2016 17:32:25 PM.200 [NOTICE] Delaying directory fetches: > > DisableNetwork is set. > > 11/18/2016 22:38:05 PM.400 [NOTICE] Bootstrapped 85%: Finishing handshake > > with first hop > > 11/18/2016 22:38:06 PM.400 [NOTICE] Bootstrapped 90%: Establishing a Tor > > circuit > > 11/18/2016 22:38:06 PM.600 [NOTICE] Closing no-longer-configured Socks > > listener on 127.0.0.1:9150 > > 11/18/2016 22:38:06 PM.600 [NOTICE] DisableNetwork is set. Tor will not > > make or accept non-control network connections. Shutting down all existing > > connections. > > 11/18/2016 22:38:06 PM.600 [NOTICE] Closing old Socks listener on > > 127.0.0.1:9150 > > 11/18/2016 22:38:07 PM.200 [NOTICE] Delaying directory fetches: > > DisableNetwork is set. > > Hi, > > Can you help us understand what the problem is? > > You might need to use "Log info file info.log" or > "Log debug file debug.log" to get enough detail for us to help you. > > T > > -- > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > > > > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
