- tor-relays - lists.torproject.org

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 05 Aug '15

05 Aug '15

>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 701.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

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 >people who pick guards from the tail is much >much worse than the performance of the top >guards, and this property likely is acting as >a deterrent to adoption. > Perhaps the guard-selection algorithm could be enhanced to consider some sort of distance/reachability metric generated by BWauths? BWauths are continuously pairing relays for measurements, and perhaps metrics from that could be mapped to autonomous system numbers (from MaxMind) in a useful way without requiring tremendous effort? Matrix analysis comes to mind. If one's guard is on the other side of the world, network latency and random congestion will hurt. I've read some path selection research is under way with an eye toward reducing passive traffic correlation exposure--this seems like it would help performance in a similar way.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

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/0D7739DEF50470356744440435FED9E1F57EF… https://atlas.torproject.org/#details/1E014CF541F32F377A116E78B76A603B8346A… https://atlas.torproject.org/#details/2316E6F012ACA52FDB09C745B0F5B41E78C23… https://atlas.torproject.org/#details/2A63402166192D66018D3FCB1ED8DE740CE71… https://atlas.torproject.org/#details/37C49200E04C8FE70799430718B10CEA5DBFB… https://atlas.torproject.org/#details/47BDCB56A9CCDAAAA71D74549E388C8EA1265…

2 1

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

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.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

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 10000. This causes the weight super-fast relays to drop substantially and provides a corresponding boost to middle and slower relays. Also puts most of the 450 Unmeasured=1 relays back in the game. In addition, this state eliminates all the crazy-stupid-buggy behavior of the BWauths that has been vexing operators so much. Only losers are the folks with huge bandwidth + CPU + tweaking in their relays, but the drop is not all that terrible. I've been watching this for two-plus days now and the Tor network rather runs better this way. Looks like no more than 50-100 relays are in the category where the weight is cut substantially, and plenty of unused capacity exists in the other 3000 or useable relays to make up the difference. Unfortunately the BWauths will likely be back due to the problem of adversarial gaming of the self-measure values. Even with a cap of 10000 someone will figure out ways to abuse the old pre-2009 approach of balancing the network. One can only hope that enough of the bugs have been worked out that BWauths will be behaving better going forward.

1 0

Blutmagie does not see 0.2.7.2 bandwidth
by starlight.2015q2＠binnacle.cx 04 Aug '15

04 Aug '15

FYI list https: // torstatus DOT blutmagie DOT de is registering relays running 0.2.7.2 as having zero bandwidth. I believe this is because the write-history read-history lines in extra-info have moved from the top down to the middle of the document. Many super-fast relays running 0.2.7.2 are showing zero bandwidth and have dropped to the bottom of the ranking as a result. Might be a bug in 'metrics-db' or it might be a bug in a Blutmagie customization. Seems that the code at https://gitweb.torproject.org/torstatus.git/ retrieves advertised (self-measure) bandwidth rather than consumed bandwidth, so it's hard to say without a deep-dive into the code. I'm going by the fact that the new https://torstatus.rueckgr.at/index.php?SR=Bandwidth&SO=Desc shows advertised bandwidth and presumably runs code from the GIT repository. Sent an e-mail to Olaf Selke advising him of this issue. Not sure if he still maintains it, but the message did not bounce.

3 5

Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
by torrry＠Safe-mail.net 03 Aug '15

03 Aug '15

> 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. I suppose this isn't expected by the script parsing > the data. > > GETINFO desc/name/splitDNA > 250+desc/name/splitDNA= > router splitDNA 62.210.82.44 21 0 143 > [...] > extra-info-digest D6F7A98078BDA327D388D918EBA92D0FC9EDC487 > nMA7WhPSpQmquUdYpwIdQtdcKvTAcvNDnXleiPBia0U It shouldn't be expected by the script: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt ------------------------------------------------------------------ "extra-info-digest" digest NL [At most once] "Digest" is a hex-encoded digest (using upper-case characters) of the router's extra-info document, as signed in the router's extra-info (that is, not including the signature). (If this field is absent, the router is not uploading a corresponding extra-info document.) ------------------------------------------------------------------- Fetching descriptors via: http://<DIR_SERVER>/tor/server/all has 2 values for extra-info-digest as well.

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

At 08:26 8/2/2015 -0700, you wrote: >I wonder if you could just run sslyze (or another >TLS scanning tool) on the OR ports of all the >relays, and see what ciphersuites they accept. The info would be indicative, but it would not reflect client-only Tor, which represents the majority of installations. Is why I think collecting connection statistics a good idea.

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

Of course! This is implicit in my posting. What I am saying is that, like old v1/v2 handshakes, Tor should be moving in the direction of eliminating DHE. The way to approach that is to *count* the number of DHE handshakes and other TLS session attributes. This is currently begin done for TOR/NTOR handshakes but is not for TLS negotiations. 0.2.7 will not build/run with openssl 0.9.8, so once 0.2.7 is widely deployed DHE can be forcibly disabled. BUT, as with v1/v2 handshakes, one would not want to do that prematurely so counting them is a good idea. That suggesting is the principle idea of the thread. At 20:01 8/2/2015 +0300, you wrote: >I think that is to maintain a backward >compatibility. Tor tries as hard as possible to >maintain backward compatibility with older >versions, unless something critical which requires >deprecation regardless some relays will disappear >from the consensus. > >I guess this is the reason we currently prefer >ECDHE but do not reject DHE. In the future, when >we are certain everyone upgraded to new enough >OpenSSL, we can safely reject DHE all the time. >

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

At 08:26 8/2/2015 -0700, you wrote: >It also may not tell you their ordering >preference (but it might! again, >you'd have to look at the code.) That "openssl s_client" test I ran was against my 0.2.6.10 with openssl 1.0.2 relay. It's certain that ECDHE is preferred over DHE, but my thought is that, especially with 0.2.7 dropping openssl 0.9.8 (no ECDHE), that relays should refuse to accept DHE connections entirely. We've seen many downgrade attacks and who knows for certain if none remain buried in the openssl? Seems prudent to kill-off DHE.

2 1

relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

In the next-above thread I had mistakenly conflated relay handshakes and 'openssl' TLS negotiations, which are it seems entirely independent. Thanks to Yawning for correcting that misconception. TLS encryption protects the relay-to-relay conversation protocol if I understand correctly, while cells are further encrypted with EC curve 25519 for the actual layered/onion encryption. Per ticket https://trac.torproject.org/projects/tor/ticket/15212 relay handshake types are counted and logged in the heartbeat message with the idea that the old v1/v2 handshake support should soon be eliminated soon. Now I wonder why the TLS handshake types are not also counted with the idea that DHE-RSA-AES256-SHA should be eliminated entirely due the near certainty that the NSA can decrypt any such sessions negotiated using the default DH 1024 bit primes, per the LogJam research https://weakdh.org/ I know that 0.2.7 is eliminating 'openssl' 0.9.8 from the picture, but this does not prevent $ openssl s_client -connect addr:port -tls1 -cipher EDH from successfully establishing a connection to relay OR ports with the aforementioned suspect DHE encryption level. Seems to me forcible prevention of this level of TLS session should be nearly as important as moving to the new ed25519 identity keys. In addition to ECDHE vs DHE, it might make sense to count how many SSL 3, TLS 1.0, 1.1 and 1.2 connections are established to be certain SSL 3 is really dead and to see how quickly TLS 1.2 is fully supported everywhere. Perhaps which ECDHE curve is selected should also be tracked.

2 1

Tor 2.6.10 fails to generate fresh DH Keys
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

>Bug: Assertion r == 0 failed in crypto_generate_dynamic_dh_modulus at ../src/common/crypto.c:1788. > Looks like you have DynamicDHGroups enabled in your torrc file. This is interesting because the recent LogJam research indicates the NSA has probably broken commonly used 1024 bit DH groups, which suggests turning on this parameter. However it was disabled by default some time ago for anti-fingerprinting reasons: https://trac.torproject.org/projects/tor/ticket/5598 AND, it's probably a moot issue now that Ntor handshakes (elliptic curve) have overtaken older RSA connections. So you should delete DynamicDHGroups 1 from torrc and let it be disabled by default.

3 3

Tor 2.6.10 fails to generate fresh DH Keys
by cyb3rwr3ck 01 Aug '15

01 Aug '15

Hi there, after a unsuspected reboot of wr3ck3d0ni0n01 I decided to refresh all the keys. I took the chance to upgrade to 2.6.10 (Debian) and recognized that the relay wont start afterwards. It looks like it is unable to generate the new krypto: Aug 01 11:56:01.000 [notice] Tor 0.2.6.10 (git-71459b2fe953a1c0) opening log file. Aug 01 11:56:01.000 [notice] Generating fresh dynamic DH modulus. This might take a while... Aug 01 11:56:01.000 [err] tor_assertion_failed_(): Bug: ../src/common/crypto.c:1788: crypto_generate_dynamic_dh_modulus: Assertion r == 0 failed; aborting. Aug 01 11:56:01.000 [err] Bug: Assertion r == 0 failed in crypto_generate_dynamic_dh_modulus at ../src/common/crypto.c:1788. Stack trace: Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(log_backtrace+0x41) [0x7f892b3b3601] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x9f) [0x7f892b3c0def] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(crypto_set_tls_dh_prime+0x7db) [0x7f892b3cfb1b] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(set_options+0x1ce5) [0x7f892b35ee25] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(options_init_from_string+0x2d3) [0x7f892b35f503] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(options_init_from_torrc+0x1ca) [0x7f892b35f81a] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_init+0x2e2) [0x7f892b2d1202] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_main+0x55) [0x7f892b2d23a5] Aug 01 11:56:01.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f8929bc2ead] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(+0x362ad) [0x7f892b2cd2ad] I wasn’t able to find any known bugs regarding this behaviour. Anyone out there who has seen this before? Best regards! Felix

1 0

Re: [tor-relays] what is guard flag recovery time for outage?
by starlight.2015q2＠binnacle.cx 31 Jul '15

31 Jul '15

Ended up reading rephist.c for awhile. Seems the up/down time is accumulated with downtime discounted %5 every 12 hours. So absolute worst-case age-out for 100% downtime would be something like .95 ^ 76 (35.5 days) to get down it to 2%. Since the outage is not as bad as that, the guard flag should show up sooner. Not interested enough to calculated the exact answer. Will just watch it.

1 0

what is guard flag recovery time for outage?
by starlight.2015q2＠binnacle.cx 31 Jul '15

31 Jul '15

Does anyone know how long it takes for the guard flag to come back after a multi-day relay downtime? Know that WTU (weighted time up) is 98%, and new-relay TK (time known) minimum is eight days. Reading rephist.c the the WTU is calculated from uptime history but rather then spend awhile to fully understand it seemed worth asking. Presently watching a relay that has been around six weeks, has been down four days recently and five total, has 14-day 100% uptime, Globe- calculated 1-month uptime of 85% and 3-month uptime of 90%. Had guard a couple of times but has not seen it return after the last outage.

1 0

my provider null routed my exit. advice?
by Christopher Yeager 31 Jul '15

31 Jul '15

Hello, I run a 100mb exit hosted at server.lu since sometime in late 2013. There have been a couple dozen abuse reports but normally they forward them to me to deal with and nothing much happens. However a week or so ago, while I was travelling, there was an abuse report that made them decide to file a ticket which then led to them suspending my IP as I 'ignored' it while I was gone. So now I'm trying to convince them to turn the system back on and they are pushing back, and after some back and forth they say they want me to run an exit policy consisting of ports 53, 80, and 443. I've been running the suggested reduced exit policy since day one and am very reluctant to pare it down further, and certainly not to just 3 ports. I wrote a short note explaining my point of view and I wonder if any of you would do me the courtesy of telling me if I am likely to convince them to let me leave the exit policy alone. I'm very willing to edit my response as required. I think it bears mentioning that I am several messages in and I did not get a good sense that whoever I am talking to understands Tor very well at all - I was repeatedly asked to find and block my customer, and told I must have logs if I provide a service, etc. I can show you the longer exchange if you think it might be helpful. Thanks in advance and here goes: --- Hello, We have nothing against Tor but IP is listed at 11 blacklists including Spamhaus ZEN. So we have to ask you block all ports except 80, 53 and 443 to prevent scan, spam and other infringing activity from your IP. Hope such proposal will be suitable for you. Regards, ROOT S.A. --- Hello again, I would rather not block any more ports that are already blocked. The system is already set up to use the reduced exit policy detailed at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy which allows as many Internet services as possible while still blocking the majority of TCP ports. Currently, the policy allows approximately 65 ports. I am reluctant to further reduce the ports because there is vastly more to the internet than just the world wide web. Email, chat, remote desktop, cache, and vpn services are all valid uses of the network that would not be allowed by such a restrictive exit policy. I'm also afraid that it will not help much in getting this IP off the various blocklists that it is on, as 2/3rds of the abuse reports I've been sent were due to traffic on ports 80 or 443. Several of the lists such as SECTOOR and Dans TOREXIT and related are simply reporting to the world that this system is a Tor node. The system is only in the Spamhaus Zen list due to its listing in the CBL for being "infected with, or is NATting for a machine infected with s_vawtrak" which is a Microsoft Windows virus that connected to their sinkhole IP on port 80. Being on blocklists is something that happens when you are running a Tor exit node and supporting Tor means putting up with them and explaining why Tor is worth supporting even though abuse is guaranteed to happen. Naturally if you require this change I will be forced to make it. I hope, however, that you can be persuaded that it is not helpful to Tor and will not solve the problem of abuse and blacklists even if it were. Thanks again. -- Thanks for getting this far. I await your replies with interest. :)

3 2

Re: [tor-relays] BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 30 Jul '15

30 Jul '15

Welcome. This event led to my discovering the Unmeasured=1 flag in the cached-*consensus files (was wondering where it was). That new BWauth is badly needed. See about 460 unmeasured relays and from an unscientific sample it seems like many of them are stuck-at-20 exit nodes--valuable resources that should be utilized. At 15:17 7/30/2015 -0500, you wrote: >On 30 July 2015 at 12:14, Tom Ritter <tom(a)ritter.vg> wrote: >> Thanks for the heads up! >> >> A fifth bwauth is expected to start >> voting "real soon now", and I'm >> not sure why maatuska didn't vote >> on bwauth data last vote, but I've >> pinged some folks so hopefully we >> can get this resolved quickly. > >Aaaand we're back! =) Sorry for the outage. > >Bandwidth scanner status > >maatuska 6890 Measured values in w lines >gabelmoo 6444 Measured values in w lines >moria1 6754 Measured values in w lines > >-tom

1 0

Re: [tor-relays] BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 30 Jul '15

30 Jul '15

Much of Tor traffic is from long-term circuits moving bulk data, so apparently it will take many hours or even days for rebalancing to fully take effect. Is not clear whether it will cause serious trouble or not. My thought is that one BWauth in a consensus is better than self-measure, as BWauths are trusted entities and a single rouge BWauth in some kind of attack taking out the rest would be dealt with via manual intervention or the closing down of Tor. Perhaps the self-measure cap of 10k should be raised as well. Was an anti-gaming mitigation from the pre- BWauth days and may have even preceded the arrival of super-fast relays. At 12:14 7/30/2015 -0500, you wrote: >Thanks for the heads up! > >A fifth bwauth is expected to start voting "real >soon now", and I'm not sure why maatuska didn't >vote on bwauth data last vote, but I've pinged >some folks so hopefully we can get this resolved >quickly. > >-tom > >On 30 July 2015 at 12:04, <starlight.2015q2(a)binnacle.cx> wrote: >> FYI list >> >> https://trac.torproject.org/projects/tor/ticket/16696 >> >> Description >> >> At present both 'longclaw' and 'maatuska' have >> dropped out of the BW consensus ('longclaw' >> is restarting with new version, not sure >> about 'maatuska'). >> >> This has caused the BW consensus logic to revert >> to using relay self-measurement for BW weightings >> due to fewer than three BW authorities participating. >> >> The 10000 cap placed on self-measure values >> is causing super-fast relays serious demotion >> and slower relays corresponding promotion >> in the consensus weighting. >> >> Possibly this may result in network >> unbalance issues. Some adjustment >> of the logic seems in order. >>

1 0

Giving away some "pre-warmed" relay keys for adoption
by Roman Mamedov 29 Jul '15

29 Jul '15

Hello, If anyone is planning to spin up a new VM or dedi to run a Tor relay and want it to be put instantly into good use (without wasting couple of weeks to a month for the whole "unmeasured relay/measured/guard/stable" cycle to complete) or if you are having trouble with your current relay being measured properly, in a few days I'm considering to give away several fingerprints+keys from my relays that I will be shutting down. If you install Tor on a new machine and unpack one of these into your /var/lib/tor, it starts up something like this (see below); i.e. in a couple of hours to a full 100% utilization. eth0 16:59 ^ t | t t rt rt rt rt | rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt -+---------------------------------------------------------------------------> | 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) 17 0 0 01 0 0 09 34135840 34964598 18 0 0 02 0 0 10 37991652 38890814 19 0 0 03 0 0 11 38710878 39749495 20 0 0 04 0 0 12 39168357 40164982 21 0 0 05 50433 1472 13 42351426 43626118 22 0 0 06 10904079 10927593 14 42826283 43928095 23 0 0 07 15691530 15839439 15 41240931 42507372 00 0 0 08 27079433 27403035 16 41941981 43139517 Drop me an E-Mail if you want one of these (probably about 2-3 available for now). -- With respect, Roman

8 14

Re: [tor-relays] pinning relay keys to IPs (or not)
by starlight.2015q2＠binnacle.cx 29 Jul '15

29 Jul '15

>(where a lot of IPs changed their AS from >IANA to Digital Ocean) A couple of minor notes regarding ASNs: 1) many IPs fall under a hierarchy of ASs where a large core-network provider (e.g. Level3) advertises a block and a second client leaf-AS advertises a sub- block. Sometimes the core AS advertises the smaller blocks though that has diminished with the CIDR route consolidation initiative. Also some ASs advertise bocks and sub-blocks. This shows up often with the CYMRU lookup data dig +short D.C.B.A.origin.asn.cymru.com txt and DNS will rotate the multiple advertisements, so one should sort the list by CIDR size and select the smallest block (i.e. largest CIDR "/" value). Possibly MaxMind takes care of all this in their data. 2) one can likely ignore AS changes when the IP has not changed, thus avoiding problems caused by network restructuring 3) perhaps many dynamic allocations where the IP changes to different AS can be detected by examining the AS owner identifiers and looking for a match I agree guards are special and perhaps should not be allowed to change ASs at all without loosing the flag, maybe even should stay glued to one IP to avoid any failed client connections and the negative impact that may have on anonymity. It seems reasonable to allow dynamic-IP middle and exit relays.

2 2

pinning relay keys to IPs (or not)
by nusenu 29 Jul '15

29 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [split from 'Giving away some "pre-warmed" relay keys for adoption'] > I'm of the opinion that it may be worth adding code to pin relay > identities to IP addresses on the DirAuth side so that consensus > weight and flag assignment gets totally reset if the ORPort IP > changes, but if there's too much churn already it may cause more > trouble than it's worth. I hope such code will not be added, because it renders relays on dynamic IPs basically useless. In the past ~week only there were >1000 fingerprints (<3% cw fraction) using more than one IP address (in that timeframe) > I'm somewhat torn on the whole key pinning thing, because I think > an individual operator moving their relay around is sort of ok > (though in an ideal world the consensus weight should get reset and > rapidly re-measured), but giving away the private component of a > relay's identity key is putting users at risk, and is behavior that > should be discouraged if not outright prohibited if possible (and > key pinning would be a heavy handed way to rule out this sort of > stupidity). -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVtOqsAAoJEFv7XvVCELh0N2oQAJYXVGM0hHJzBl3i7tkfZx8E hEd9PgyX0v+nXnlAU06lsFltK12VaCkXp9Gft8TlmshP6NqsdHk+KPrtumUE7IA4 MmYmmVi5Tb8AyN241nr/RbYOUS+9nz2VvtkhaikkvbFxwzua678I13P1PC/QPki3 S4KwQ0YYYlUrG529GhLaGkm5byX3N+MAdGQn04xzCDzBW/j3GxbZYBj4+tqgHONR 9iAs5/p00MFVGp3Ex8xJKBVRW0NRT//fKRrZtRDBaNxduUg7F0EccO4zlPjTUBAM e+g8tergT4ICixddhRih0iGA3ysw3/mI1KyvOMegZXkUQ0Yo+puR4O7S2w4WoWRh 1tkkbcFWAh4sCKDPLlD/sqWKFDkHLtP3AOG+KGgybkhULNU1GgAftV39QVrsABx/ oP/dhC9d+MablSZg6qS8dxTV3L+E5EdE2RX226+BPjRkUSqphojEYjDpiaR3/COU 2BmACmPIuiS60DfaiqygKQaCwvgDl6q96o5oZEmPHem2SIxh5o3DD1wLJgKKEsiL WgmoRHTLfqc2Uq0442oi7KMhgGcIffS8xKbb1xw/9yIF2WiKrluFFWau5k6cQYA2 0buDAz7WWi7kxUCnn39NcyrtWoOWMziRH+rjv5esoRN7W5k2GNtBcylZ6kyzcudr hy7j6rYMLpUHsVc2NHKd =8W7p -----END PGP SIGNATURE-----

5 9

Very unbalanced in/out connection ratio
by mattia 29 Jul '15

29 Jul '15

Hello, I've been running a middle relay [1] for months and I have always noticed an unbalance between incoming and outgoing connections (monitored through arm). The incoming connections were always in between 0-10% more than the outgoing ones. This morning though the unbalance has reached so far unseen levels: arm reports more than 2500 incoming connections while outgoing are little more than 200. Is this normal and, if so, why? Thank you, Mattia [1] https://globe.torproject.org/#/relay/0D14A4498E7D1854696CC07548653EA4CD3CB2…

2 2

Re: [tor-relays] longclaw BWauth is broken -- no measurements since 7/22
by starlight.2015q2＠binnacle.cx 28 Jul '15

28 Jul '15

Longclaw is broken again. Has not updated 55% of the the relay BS measurments for forty hours. Updated the ticket below with details and raise it to "major" issue. At 16:42 7/25/2015 -0400, you wrote: >Realized not everyone monitors this >list so I opened a Trac ticket: > >https://trac.torproject.org/projects/tor/ticket/16667 > > > >At 11:19 7/25/2015 -0700, you wrote: >>Interesting. Thanks starlight for the head's up! I'm not >>aware of any known issues with longclaw right now >>so looping in its operator. >> >> >>On Sat, Jul 25, 2015 at 10:09 AM, >><starlight.2015q2(a)binnacle.cx> wrote: >>> Subject says it. >>> >>> Thought it was strange that its measurement >>> of my relay has not been moving. Pulled the >>> vote history and grep'ed a dozen relay >>> measurements and none of them have changed. >>>

1 0

pinning relay keys to IPs (or not)
by starlight.2015q2＠binnacle.cx 26 Jul '15

26 Jul '15

Perhaps a way to do it is reset the consensus for a relay if its IP address moves to a different Autonomous System. Is rare that dynamic IP causes relays to hop ASs (e.g. possibly SBC/ATT), and list of exceptions could be created for the few cases where it causes trouble. CYMRU has a dynamic service for looking up AS from IP.

3 2

Re: [tor-relays] longclaw BWauth is broken -- no measurements since 7/22
by starlight.2015q2＠binnacle.cx 25 Jul '15

25 Jul '15

Realized not everyone monitors this list so I opened a Trac ticket: https://trac.torproject.org/projects/tor/ticket/16667 At 11:19 7/25/2015 -0700, you wrote: >Interesting. Thanks starlight for the head's up! I'm not >aware of any known issues with longclaw right now >so looping in its operator. > > >On Sat, Jul 25, 2015 at 10:09 AM, ><starlight.2015q2(a)binnacle.cx> wrote: >> Subject says it. >> >> Thought it was strange that its measurement >> of my relay has not been moving. Pulled the >> vote history and grep'ed a dozen relay >> measurements and none of them have changed. >>

1 0