Hmm, don't see the script in this Git repository,
most recently updated files are from a month ago.
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 bu
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-
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 vG0ZWLi31UXoqz4H2H/hweSvxqo 04:44:19
62.210.124.124 9001 9030
12-13-10-cons:r kitten1 vG0ZWLi31UXoqz4H2H/hweSvxqo 04:4
I'd guess a bug in the version update script.
At 19:20 1/12/2016 +0100, Aeris wrote:
>> Are you *absoultely* certain that the config
>> was not fiddled with at the time of this event?
>
>After grepping some logs, seems 13/12 was the day of a Tor
>upgrade :
>
>2015-12-13 10:47:31 upgrade tor:amd6
Dug into the situation Aeris reported where his
kitten1 relay was nixed off the fallback
directory list due to a single consensus
where the dir-port was published as zero.
Quickly found three additional very fast
very stable relays where the same thing
happened:
BF0FB582E37F738CD33C3651125F277270
Improved list:
BF0FB582E37F738CD33C3651125F2772705BB8E8 12-28:17 quadhead
86E78DD3720C78DA8673182EF96C54B162CD660C 12-13:11 kitten1
6DE61A6F72C1E5418A66BFED80DFB63E4C77668F 12-19:11 eriador
39F096961ED2576975C866D450373A9913AFDC92 12-28:06 metaether
92CFD9565B24646CAC2D172D3DB503D69E777B8A 12-16:1
Just sent a request to the contact of
three affected relays asking they post
daemon log entries if they have them.
Hopefully someone can retrieve the
information and it will shed some
light on what's happening.
At 10:33 1/13/2016 +1100, Tim Wilson-Brown - teor wrote:
>>At 19:20 1/12/2016 +0100,
See comment 6 in
Bug #18050: Relay submitted a descriptor with 0 DirPort due to a self-test race
condition
https://trac.torproject.org/projects/tor/ticket/18050
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/
Lately 'gabelmoo' had been bouncing down and up like a ping-pong ball.
Because gabelmoo is a BWauth (of which only five exist) as well as a normal
authority, the impact is greater than if it did not participate in bandwidth
measurement. Disrupts the consensus median.
Does anyone know anything
At 18:55 1/21/2016 +0100, you wrote:
>Gabelmoo is running 0.2.7.6. . .
Thank you for replying.
I saw earlier that moria1 ran into this
and decided to wait on 0.2.7 for my
relay, though I suppose the issue is
specific to authorities and does not
apply to normal relays.
___
Could someone with a solid understanding of how the Tor daemon interacts with
DNS comment on whether and how CVE-2015-7547 (glibc DNS response buffer
overflow, remotely exploitable) the bug impacts relay running under Linux?
___
tor-relays mailing list
>If your relay has been given guard status does this mean that
>one's middle status is put on hold or can a relay be in guard
>and middle status at the same time?
Guard-flagged relays are both middle and guard nodes.
Take a look at the relay in
https://atlas.torproject.org/
and
https://globe
These relays all appear at least somewhat overrated by BWauths and are not
rate-limiting with BandwidthRate.
DirPort performance is bad due to a saturated physical link or 'tc' bandwidth
limit, so TCP congestion back-off kicks in.
If BandwidthRate were the limiting factor DirPort would return a
You may find the information in this ticket
of interest, particularly the cited comment:
https://trac.torproject.org/projects/tor/ticket/16824#comment:23
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/ma
14 matches
Mail list logo
