On 12 Jan 2016, at 16:09, starlight.2016q1@binnacle.cx wrote:

Hmm, don't see the script in this Git repository, most recently updated files are from a month ago.

Yes, my branch has some bug fixes that are awaiting review before they get merged into tor master.

At 15:35 1/12/2016 +1100, you wrote:

...

This list was generated a few minutes ago from scripts/maint/updateFallbackDirs.py in my branch fallback-17887-17888-18035 on [2]. (This branch has some bug fixes compared to what's in master.)

[2]: https://github.com/teor2345/tor.githttps://github.com/teor2345/tor.git

---

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 968F094B

teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

On 12.1.16 9:47, Toralf Förster wrote:

On 01/12/2016 05:35 AM, Tim Wilson-Brown - teor wrote:

...

If you run an under-utilised exit, we encourage you to opt-in as a fallback directory. We've also fixed a major bug that excluded some relays from the list.

Well, I to amintain an exit with 8 MB advised bandwith, utilized currently by 50%:

https://globe.torproject.org/#/relay/F1BE15429B3CE696D6807F4D4A58B1BFEC45C82...

Anything I should add to my torrc ?

Not unless your server is bottlenecking your node, such as insufficient RAM, or one thread being maxed out. Right now, most exit nodes are being utilized ~50% of their advertised bandwidth capacity because that is the overall usage of the Tor exit network. So, if your exit node is using <50% of all it's performance power (such as CPU, bandwidth, RAM, etc.), then I'd say it's currently being under-utilized and would qualify for the fallback directory opt-in (and if the other criteria are met), should you so choose.

On the flip side, if your node is using ~50% of it's advertised bandwidth and is using 80% of it's CPU power or actual bandwidth to do so, that's a misconfiguration and not a good candidate for a fallback directory.

At 16:56 1/12/2016 +0100, you wrote:

Is this list removes already included fallback nodes ? Previously, my node kitten1 was on the list, but not on this one. (I already opt-in for it inclusion on december, with my others nodes (kitten[1-4])).

Reason is listed in the the attachment to the bug-fix post:

https://lists.torproject.org/pipermail/tor-relays/2016-January/008504.html

4. debug output showing causes of relay exclusions

http://pastebin.com/raw/3SBpgECm

DEBUG:root:86E78DD3720C78DA8673182EF96C54B162CD660C not a candidate: changed address/port recently (2015-12-13 11:00:00)

Perhaps this is a bug in the consensus system. Pulling the consensus archive and grepping, exactly the one single consensus is showing DirPort as zero:

12-13-09-cons:r kitten1 <fp> vG0ZWLi31UXoqz4H2H/hweSvxqo 04:44:19 62.210.124.124 9001 9030 12-13-10-cons:r kitten1 <fp> vG0ZWLi31UXoqz4H2H/hweSvxqo 04:44:19 62.210.124.124 9001 9030 12-13-11-cons:r kitten1 <fp> yUnPgGOwhq5QfUEe1Eg0zKCU+w0 10:48:46 62.210.124.124 9001 0 12-13-12-cons:r kitten1 <fp> JrZF6+VnnYZuQHRllufg53dbjH8 10:49:48 62.210.124.124 9001 9030 12-13-13-cons:r kitten1 <fp> JrZF6+VnnYZuQHRllufg53dbjH8 10:49:48 62.210.124.124 9001 9030

Are you *absoultely* certain that the config was not fiddled with at the time of this event? As can be seen, the descriptor hash changed twice which could indicate two config changes in rapid succession--could also indicate a BW or similar change.

At 17:54 1/12/2016 +0100, Aeris wrote:

...

DEBUG:root:86E78DD3720C78DA8673182EF96C54B162CD660C not a

candidate: changed

...

address/port recently (2015-12-13 11:00:00)

Hum… Don’t know how is it possible, this relay has the samee IP/port since it creation 1 year ago.

From CollecTor, seems there is only a single network glitch, and only on the DirPort (OR port stable).

$ wget https://collector.torproject.org/archive/relay-descriptors/micro descs/ microdescs-2015-12.tar.xz $ tar xf microdescs-2015-12.tar.xz $ cd microdescs-2015-12/consensus-microdesc $ rgrep kitten1 | awk '{print $2,$3,$6,$7,$8}' | sort | uniq -c 1 kitten1 hueN03IMeNqGcxgu+WxUsWLNZgw 62.210.124.124 9001 0 735 kitten1 hueN03IMeNqGcxgu+WxUsWLNZgw 62.210.124.124 9001 9030 $ rgrep kitten1 | grep "9001 0" 13/2015-12-13-11-00-00-consensus-microdesc:r kitten1 hueN03IMeNqGcxgu +WxUsWLNZgw 2015-12-13 10:48:46 62.210.124.124 9001 0

:'(

-- Aeris

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 01/12/2016 05:54 PM, Aeris wrote:

Hum… Don’t know how is it possible, this relay has the same IP/port since it creation 1 year ago.

Ah - and much more important, I probably will change its IP address in the near future, b/c 1 of 2 hard disks is dying here and I plan to replace it with a new server hardware compeltely. So maybe I shall come back after I moved the tor to the new hardware.

- -- Toralf, pgp: C4EACDDE 0076E94E

kitten3 doesn't have a DirPort configured. Relays need a DirPort to be a fallback directory mirror. Let me know if you are able to configure a DirPort for it.

Also let me know if you want to opt-in or opt-out other relays in that family.

Thanks for the report, corrected !

For others nodes of my family, avoid kitten5 and 6 at this moment, potential migration with IP change in few months.

Regards,