Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

Found a serious bug in the updateFallbackDirs.py script used to generate the fallback relay candidate list. The OnionOO retrieval used to pull flag history returns the entire history of each relay rather than the 120 days requested. This results in 145 relays left off the list as too-old

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

follow up: Looking at the URL it appears that the selection criteria indicates which records to select NOT the range of history to return. So the having the script filter by MAX_AGE (per the patch) is correct. A quick examination of https://onionoo.torproject.org/protocol.html reveals no

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

At 14:24 1/12/2016 +1100, you wrote: >I've reviewed this patch and it looks good. >I updated it for the latest version of the script in the tor git repository, >as it was based on an old version. great, thanks! >I've also logged the more general issue with OnionOO and date ranges as #18036.

Re: [tor-relays] Opt-In Trial: Fallback Directory Mirrors

Relay 'Binnacle' experienced outages due to a loose fiber-option junction in the overhead wires that has been repaired. I believe it would make the list if not for this and do not foresee further trouble. Has a static IP and another Verizon FiOS relay qualifies, a positive reflection on the

Re: [tor-relays] Custom bandwith for different time ranges

>Is it possible to schedule the time when bandwith . . . >How may I schedule this in tor relay? >Is it possible to limit traffic on >the client or I need to do it on my firewall ? As suggested in an earlier reply, configuring 'cron' jobs to adjust the rate usually makes sense. As an

[tor-relays] [tor-consensus-health] Possible Sybil Attack

FYI list https://lists.torproject.org/pipermail/tor-consensus-health/2015-October/006388.html Fri Oct 30 22:25:10 UTC 2015 Over the last hour 58 new relays have appeared. New additions are... https://lists.torproject.org/pipermail/tor-consensus-health/2015-October/006389.html Fri Oct 30

[tor-relays] Failure from drain-fd

On 27 Oct 2015, at 15:42, Brian Walker wrote: > >I've updated Tor to the newest beta: >Tor v0.2.7.4-rc (git-f55d23e1e66e9b0f) running > on Windows 8 [server] > with Libevent 2.1.5-beta, >OpenSSL 1.0.2d and Zlib 1.2.8. > >I'm still experiencing errors: >Oct 27

Re: [tor-relays] Failure from drain-fd

At 23:58 10/28/2015 -0500, starlight.201...@binnacle.cx wrote: > Log debug file logfile001 If the volume of messages is too high, you might have luck with "domain" logging, which narrows it to particular functional realms, for example: setconf Log="[edge] debug file logfile001" where the

Re: [tor-relays] too many circuit creation requests

At 19:34 10/24/2015 -, trshck_...@riseup.net wrote: > >On 2015-10-24 18:56, starlight.2015q3 at binnacle.cx wrote: >> >> 3000+ would be insanely large for relay >> rated around 100. > ># lsof -Pn | grep "^tor" | grep ESTABLISHED | wc -l >3169 >

Re: [tor-relays] Tor node break-in attempts

> > Attack counts are in the 100,000s. > This sort of thing posses no threat and is quite stupid as previously observed. Is mainly annoying for the mess it makes of /var/log/security. If you don't want to change the SSH port (best solution IMO), here's an 'iptables' rule that will fix it

Re: [tor-relays] Tools for managing multiple relays

>None of the above :) > >I run these three relays[1][2][3]. > >ccrelaycc [1] has acquired the guard flag in the >last few days (don't know when, last time I >checked it did not have it). This relay is rated near the boundary of minimum Guard rating and goes in and out of the state. >A thing that

Re: [tor-relays] Tools for managing multiple relays

On Thu, Oct 15, 2015 at 20:20:13 -, nusenu wrote: >>> LeaseWeb has 49 euro 100TB servers available >>> in the Netherlands--killer exit boxes that will >>> rate high and pull 15000 per Blutmagie. OVH has >>> good offerings as well >> >>Please consider diversity when

Re: [tor-relays] Tools for managing multiple relays

_gfs_ ccrelaycc NL 942 98 4.27 L 95.85.8.226 443 80 95.85.8.226 __fs_ jaine IT 216 13 4.27 L 5.249.145.164 443 80 ... .aruba.it __fs_ inara SG 38 98 4.27 L 128.199.148.243 443 80 128.199.148.243 One likely contributor to the relatively high rating of 'ccrelaycc' is residence in

Re: [tor-relays] Tools for managing multiple relays

>* given costant resource (i.e. euro/month) I can >afford to run relays is it in general better to >run one bigger relay or, say, two smaller ones. Based on a past thread, guessing you run __fs_ BV2 IT 344 71 6.10 L 5.249.159.209 9001 None ... .aruba.it __fs_ BV3 IT 344 73 6.10 L 5.249.159.198

Re: [tor-relays] why are some exit IPs missing from Exit IP DB?

At 13:29 10/8/2015 -0400, starlight.201...@binnacle.cx wrote: >Occasionally I run into a relay such as > >Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4 >OR ip 178.33.157.6 >exit ip 31.7.58.37 > >Where the egress/exit IP source address is >not found in the Exit DB, shows up negative >on

Re: [tor-relays] Exit Node with Onion Pi

At 12:21 10/9/2015 -0700, Green Dream wrote: >http://www.newegg.com/Product/Product.aspx?Item=N82E16856501007 . . . >If you want a box with AES-NI and a gigabit ethernet interface, cost starts >jumping up to several hundred US

[tor-relays] why are some exit IPs missing from Exit IP DB?

Occasionally I run into a relay such as Bywadu 5A0DE94C95E2276B4BAC974A7D8FC6463C4FE8A4 OR ip 178.33.157.6 exit ip 31.7.58.37 Where the egress/exit IP source address is not found in the Exit DB, shows up negative on ExoneraTor. TorCheck in glaring unhappy RED spits >Something Went Wrong!

[tor-relays] IP and SWIP for a Tor exit node

>> (2) SWIP/RWHOIS + ARIN/RIPE >> >> SWIP'ing is a bit exotic though some ISPs provide it. >> Be sure to use a PO box in the contact info rather than >> your real address if you obtain this. > >This would be for privacy reasons, right? i.e. to avoid >advertising my own address? yes >What if I

[tor-relays] Blutmagie is Good Looking and VERY SLOW -- this script is VERY FAST

one more enhancement: added a -W option to have underscore characters used for inactive flag positions. Produces a single column for flags, thus enabling trivial command-line 'awk' and 'perl -n' scripting. fast_simple_tor_rank.tar Description: Binary data

[tor-relays] IP and SWIP for a Tor exit node

(1) In the guide it is advised to "Get a separate IP for the node. . . You have the right idea. Tor-exit node IPs end up on all sorts of black-lists and it's best to segregate exit traffic from all other traffic. Try pulling up a few exits using http://multirbl.valli.org and you will see

[tor-relays] IP and SWIP for a Tor exit node

>What are additional IPs good for? My ISP sells additional >(public) IPs for 3,60 euro/month, would it be worth it or >necessary purchasing such an additional service? For the size node presently indicated, additional IP address are of no particular value. Extra IPs can be use for 1) running

[tor-relays] IP and SWIP for a Tor exit node

>I have bought some credit on Aruba. . . Looked at Aruba offerings, check this out https://serverdedicati.aruba.it/server-dedicati/basic-1-3.aspx For 15 euros/month you can have a dedicated dual-core 1.6GHz with 100MBPS unmetered traffic. This will make a rather nice exit node for the cost and

[tor-relays] Blutmagie is Good Looking and VERY SLOW -- this script is VERY FAST

improved: 1) flags on left side for easy left-anchor grep'ping 2) authority flag shares exit flag column 3) "a" alpha and "r" rc appended to version 4) OS flag in separate aligned column NOTES no "directory" flag since dir-port is "none" when not present no "valid" or "running" flags since

[tor-relays] Blutmagie is Good Looking and VERY SLOW -- this script is VERY FAST

For those who like Blutemagie's excellent Tor node report and ranking, but find the painfully slow page rendering --well painful. This script pulls the same data via the CSV download and generates concise readable text report. 100x faster literally. Also a script for the newer Rueckgr.at

[tor-relays] Middle Relay has no traffic

>My middle relay seems to have minimal traffic. >Is there something I need to do or is my damn >IPS (Comcast) blocking me. > >Node name is gmojo02 > >gm Possibly the Comcast gateway NAT is unable to deal with lots of connections andj/or it may be an older, slow model that can't handle much

[tor-relays] Middle Relay has no traffic

>My middle relay seems to have minimal traffic. >Is there something I need to do or is my damn >IPS (Comcast) blocking me. > >Node name is gmojo02 > >gm Possibly the Comcast gateway NAT is unable to deal with lots of connections andj/or it may be an older, slow model that can't handle much

[tor-relays] Middle Relay has no traffic

[know I'm breaking the thread--sorry about that] >Starlight - I see your advertised BW is >7.26MB = 58.08 Mb with globe showing 2 >to 4 Mb traffic. Maybe I will up the >advertised BW on the relay and see if >that helps. That's not "advertised" bandwidth in the sense of something that can be

[tor-relays] tor-relays] Experience hosting exit relay with Costa Rica Servers: crservers.com

You might check for existing relays in their system. This Robtex seems to have much of their network, which they appear to lease from other providers: https://www.robtex.com/en/advisory/dns/cr/crservers/ And while they advertise many network blocks, it appears it's all slices of just a few

Re: [tor-relays] Bots, love 'em or hate 'em?

This is curious: Appears a large number of Tor client-bots have set UseEntryGuards 0 >From current relays that have never had the guard flag: extra-info moep DA8C1123CDB3ACD3B36CD7E7CEFBEA685DED2276 entry-ips us=360,de=296,fr=232,it=192,es=160,jp=104,ru=104,br=96,ir=96. . . extra-info

Re: [tor-relays] bwauth graph for August 2015

In addition to reducing Unmeasured=1 relays from ~350 to ~150, the combination of the new Torflow release and addition of the Faravahar BWauth have dramatically improved the reliability and stability of bandwidth measurements of relays, for both the individual BWauth values and consensus values.

Re: [tor-relays] Bots, love 'em or hate 'em?

At 11:11 8/19/2015 -0400, you wrote: But all that bot traffic creates a lot of statistical background noise, and so may be providing a service in making it more difficult for advanced adversaries to perform traffic correlation analysis. Thoughts anyone? Here is one excellent reason to love Bot

[tor-relays] Bots, love 'em or hate 'em?

My relay says it receives about 50k v1/v2/v3 connections each day to the 60k v4 connections that come in. Entry-ips says it has about 35k guard- clients. Blutmagie says there are no pre-0.2.4 relays talking anything other than v4. So I'm left thinking that 95% or more of the bandwidth

[tor-relays] do not run Tor client and OR relay together!

Anyone who has configured a Tor SOCKS5 client to run in a 'tor' instance that also operates as an OR relay should isolate the client to a separate client-only process. The client function disturbs relay traffic forwarding in a manner that lends itself to confirmation analysis. See bug 16585,

Re: [tor-relays] do not run Tor client and OR relay together!

I think separate packages are good idea --is about making it easier for regular users to configure Tor with less pain. 'openssh' provides a good example, as it come with three component packages: openssh (core files) openssh-client openssh-server so one would have tor-core tor-client

Re: [tor-relays] do not run Tor client and OR relay together!

At 17:32 8/16/2015 -0400, you wrote: LogTimeGranularity 1 Thank you! I'm putting this in the debug activation script: TORCTRL=x.x.x.x nc ${TORCTRL:?} 9151 EOF AUTHENTICATE password SETCONF LogTimeGranularity=1 SETCONF Log=debug file logfile$(date '+%M%S') QUIT EOF

Re: [tor-relays] Guidelines for lifetime of a bridge?

Five, ten days? I ran a bridge at a provider where IP addresses are easy to release and replace with new ones. Seems to take the censors in China, Iran, Pakistan, etc less than a week to find and block new bridge IPs. I gave up in frustration. Meek is a better solution but is not something an

Re: [tor-relays] OT: starlight vs. email threading

Hi nusenu, Normally I respond to list messages and threading works, but lately I've turned off list delivery in an effort to pay less attention to the tor-relays list. Sorry about the resultant messy thread continuity. With luck I'll be posting less, and if I come back in a few weeks or months

[tor-relays] Guard flag flapping

. . .have physical access to the . . . ONT. Doubt this is the case, but on the off chance that the ONT is configured to flow IP traffic over a coaxial cable attached to a CPE router (customer premise equipment), the configuration should be changed to deliver data over a Gigabit Ethernet directly

[tor-relays] Guard flag flapping

The problem is likely that your ISP is routing some traffic via an overloaded peering point. Running traceroute -w 1 -q 5 -A bwauth-IP 1400 may provide more detail on this issue. The -A option causes 'traceroute' to show Autonomous System numbers with each route hop, where ASNs are Internet

[tor-relays] Guard flag flapping

[apologies to all for thread-breaking, am really going on hiatus but the horror-show performance GBE topic was too darn interesting--last post I promise!] I would call it a dedicated gigabit link. This is probably up for debate. The provider's overall capacity is very likely not [number of

[tor-relays] Guard flag flapping

Both relays are showing low BWauth-measured bandwidth and are below the 2000 threshold for the Guard flag. Recently BWauths were offline and the consensus algorithm reverted to self- measure. During that period the relays were above the 2000 threshold and were assigned Guard. But even the

[tor-relays] Guard flag flapping

You might start with running SpeedTest via the Python script to see how the network performance looks: https://pypi.python.org/pypi/speedtest-cli/ ___ tor-relays mailing list tor-relays@lists.torproject.org

[tor-relays] BoingBoing: What happened when we got subpoenaed over our Tor exit node

http://boingboing.net/2015/08/04/what-happened-when-the-fbi-sub.html check out comment #2 as well as the blog article ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Guard flag flapping

First, I am assuming you are running bare-metal on a system and not in a virtualized server--everything below is premised on that. Do not expect a virtual server or Linux container to perform well as a high- capacity Tor relay. It's possible to configure a high-performance VM, but this is an

[tor-relays] Guard flag flapping

Ah, forgot to calculate the default TCP windows for you link speed rather than mine. So that's 12500 bytes/sec ( 1 gigabit / sec ) * 25 milliseconds or 3125000 (for read) * 40 milliseconds or 500 (for write) net.core.rmem_max = 16777216 net.core.wmem_max = 16777216

[tor-relays] Guard flag flapping

comments backward, but the sysctls are correct * 25 milliseconds or 3125000 (for write) * 40 milliseconds or 500 (for read) ___ tor-relays mailing list tor-relays@lists.torproject.org

[tor-relays] Guard flag flapping

One more errata: The sense of this is negative, so the current setting you have is correct: net.ipv4.tcp_no_metrics_save = 0 The double-negative got me. ___ tor-relays mailing list tor-relays@lists.torproject.org

[tor-relays] Guard flag flapping

I had already run tests with both speedtest-cli and iperf3. This server consistently achieves 200 to 300 Mb/s in both directions, with both relays still running, and on some runs is hitting over 800 Mb/s. Final caveats: If the server is on a shared gigabit link, performance may not improve. The

[tor-relays] longclaw BWauth is back, not measuring 2000 relays, what's with that?

The explanation does help--thank you. Have been interested in how it would look after the script update since 7/28 (nine days ago) but did not realize it took so long to rebuild the data. ___ tor-relays mailing list tor-relays@lists.torproject.org

[tor-relays] longclaw BWauth is back, not measuring 2000 relays, what's with that?

longclaw4691 Measured values in w lines maatuska6815 Measured values in w lines gabelmoo6347 Measured values in w lines moria1 6715 Measured values in w lines ___ tor-relays mailing list tor-relays@lists.torproject.org

[tor-relays] BWauth no-consensus state in effect

Maybe geo-location would not be so great because two networks in the same physical area might have relatively poor connectivity to each other. Aggregated IP block might be the ticket. CIDR-Report has both actual and suggested netblock aggregations. http://www.cidr-report.org/as2.0/#Gains Shows

[tor-relays] BWauth no-consensus state in effect

At Tue Aug 4 22:17:54 UTC 2015 by Mike Perry mikeperry at torproject dot org In some instances where I have not selected my guards manually, Tor Browser is unbearably slow. Like really, really painfully slow. The whole time. Until I reinstall it. This makes me think that the performance of

[tor-relays] BWauth no-consensus state in effect

Poking around Blutmagie, I suspect the number of relays with chopped bandwidth weightings might be more like in the range of 25-45. Perhaps the PID-controller algorithm should be adjusted to bias somewhat less toward super-fast relays. ___ tor-relays

[tor-relays] Blutmagie does not see 0.2.7.2 bandwidth

At Tue Aug 4 11:22:22 UTC 2015 by Olaf Selke olaf DOT selke at blutmagie DOT de by the way... I will probably shut down blutmagie tor network status in September this year cause the data center has terminated the contract housing my servers 10/31/15. Could you make your modified Torstatus code

[tor-relays] BWauth no-consensus state in effect

At Tue Aug 4 20:16:17 UTC 2015 by Jannis Wiese mail at janniswiese.com Strange thing: My relay [0] is speeding up since then significantly (finally!!) That's because with no BWauth quorum the consensus algorithm reverts to using self-measured bandwidth with a ceiling of 1. This causes the

[tor-relays] BWauth no-consensus state in effect

Many under-utilized and never-utilized exits relays back online with BWauth outage. Unscientific sample out of 234 previously Unmeasured=1 exit relays, but almost all of the ones checked are like these https://atlas.torproject.org/#details/0D7739DEF5047035670435FED9E1F57EF6AE

[tor-relays] BWauth no-consensus state in effect

BWauths are continuously pairing relays for measurements, and perhaps metrics from that could be mapped to autonomous system numbers . . .scratch AS, geo-location is better and MaxMind specializes in that Pinging a FiOS relay in LA takes 75ms while a close-by relay takes 8ms. Both are in AS

Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth

Hi Olaf, The new ed25519 elliptic curve relay identity certificate now occupies the top of the extra-info document. The script should be able to handle the elements appearing in any order. Since the script is written in perl this should be an easy fix to search/match out the read-history and

Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth

At 16:10 8/3/2015 +0200, you wrote: debugging the old Blutmagie Perl scripts I found all routers like splitDNA running Tor 0.2.7.2 sending two hash values in the extra-info-digest. The second entry is a new 256-bit digest that will eventually replace the current 160-bit digest and can be ignored