Re: [tor-relays] Revised Opt-In Trial: Fallback Directory Mirrors
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:amd64 0.2.7.5-1~d80.jessie+1 0.2.7.6-1~d80.jessie+1 2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1
Timing is good compare to the 10:48:46 of the consensus !
But I donât remember a config change after that, perhaps only on /usr/share/tor/tor-service-defaults-torrc or on a default config param change ?
And perhaps the Tor reboot cause the DirPort to be temporarily disabled (seems not human, only 2s duration) ?
Regards, -- Aeris
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:amd64 0.2.7.5-1~d80.jessie+1 0.2.7.6-1~d80.jessie+1 2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1
Timing is good compare to the 10:48:46 of the consensus !
But I donât remember a config change after that, perhaps only on /usr/share/tor/tor-service-defaults-torrc or on a default config param change ?
And perhaps the Tor reboot cause the DirPort to be temporarily disabled (seems not human, only 2s duration) ?
I wonder if the DirPort self-test finished ~62 seconds after the ORPort self-test? (Or, strictly, after the first descriptor was submitted?) That would explain the behaviour we're seeing here. (And it shouldn't be grounds for exclusion as a fallback directory, let me see what I can do.) Logged in trac as #18050. https://trac.torproject.org/projects/tor/ticket/18050 <https://trac.torproject.org/projects/tor/ticket/18050> Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
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, 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:amd64 0.2.7.5-1~d80.jessie+1 0.2.7.6-1~d80.jessie+1 2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1
Timing is good compare to the 10:48:46 of the consensus !
But I donât remember a config change after that, perhaps only on /usr/share/tor/tor-service-defaults-torrc or on a default config param change ?
And perhaps the Tor reboot cause the DirPort to be temporarily disabled (seems not human, only 2s duration) ?
I wonder if the DirPort self-test finished ~62 seconds after the ORPort self-test? (Or, strictly, after the first descriptor was submitted?)
That would explain the behaviour we're seeing here. (And it shouldn't be grounds for exclusion as a fallback directory, let me see what I can do.) Logged in trac as #18050. <https://trac.torproject.org/projects/tor/ticket/18050>https://trac.torproject.org/projects/tor/ticket/18050
Tim
On 13 Jan 2016, at 10:33, Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:
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:amd64 0.2.7.5-1~d80.jessie+1 0.2.7.6-1~d80.jessie+1 2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1
Timing is good compare to the 10:48:46 of the consensus !
But I donât remember a config change after that, perhaps only on /usr/share/tor/tor-service-defaults-torrc or on a default config param change ?
And perhaps the Tor reboot cause the DirPort to be temporarily disabled (seems not human, only 2s duration) ?
I wonder if the DirPort self-test finished ~62 seconds after the ORPort self-test? (Or, strictly, after the first descriptor was submitted?)
That would explain the behaviour we're seeing here. (And it shouldn't be grounds for exclusion as a fallback directory, let me see what I can do.)
The fallback directory update script uses the OnionOO field last_changed_address_or_port, which is implemented correctly: the relays in question did stop announcing their DirPort within the last 120 days. In the fallback directories script, there doesn't seem to be any way to work around the special case where relays stop announcing their DirPort for a single descriptor/consensus because they have been restarted, and their DirPort self-test has not finished yet. So I don't know if there's any way to fix this, apart from fixing the underlying issue with the relay code, and waiting 120 days for the previous upgrades to be old enough that they don't matter any more. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On 13 Jan 2016, at 11:21, Tim Wilson-Brown - teor <teor2345@gmail.com> wrote:
On 13 Jan 2016, at 10:33, Tim Wilson-Brown - teor <teor2345@gmail.com <mailto:teor2345@gmail.com>> wrote:
At 19:20 1/12/2016 +0100, Aeris wrote:
... After grepping some logs, seems 13/12 was the day of a Tor upgrade :
2015-12-13 10:47:31 upgrade tor:amd64 0.2.7.5-1~d80.jessie+1 0.2.7.6-1~d80.jessie+1 2015-12-13 10:48:39 configure tor:amd64 0.2.7.6-1~d80.jessie+1
Timing is good compare to the 10:48:46 of the consensus ! ... And perhaps the Tor reboot cause the DirPort to be temporarily disabled (seems not human, only 2s duration) ?
I wonder if the DirPort self-test finished ~62 seconds after the ORPort self-test? (Or, strictly, after the first descriptor was submitted?)
That would explain the behaviour we're seeing here. (And it shouldn't be grounds for exclusion as a fallback directory, let me see what I can do.)
The fallback directory update script uses the OnionOO field last_changed_address_or_port, which is implemented correctly: the relays in question did stop announcing their DirPort within the last 120 days.
In the fallback directories script, there doesn't seem to be any way to work around the special case where relays stop announcing their DirPort for a single descriptor/consensus because they have been restarted, and their DirPort self-test has not finished yet.
So I don't know if there's any way to fix this, apart from fixing the underlying issue with the relay code, and waiting 120 days for the previous upgrades to be old enough that they don't matter any more.
I think we've resolved this issue at both ends: Relays should not experience the 0 DirPort issue when upgrading to the next 0.2.7 release. https://trac.torproject.org/projects/tor/ticket/18050 <https://trac.torproject.org/projects/tor/ticket/18050> In the 0.2.8-alpha series, we use a shorter address stability period to work around previous address changes due to the 0 DirPort bug. (This is ok, because fewer people use the alpha series, and they don't use it for very long before upgrading.) https://trac.torproject.org/projects/tor/ticket/18086 <https://trac.torproject.org/projects/tor/ticket/18086> Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
participants (2)
-
starlight.2016q1＠binnacle.cx -
Tim Wilson-Brown - teor