I don't know if this was mentioned at the Tor Relay Meeting yesterday, if so,
I missed it.
A few months ago there was a recommendation to not exposing OrPort for
bridges.
This had the unpleasant effect that all bridges were 'red' on Tor Metrics,
even though they were running perfectly fine.
I noticed yesterday after the meeting that everything is 'green' again. https://metrics.torproject.org/rs.html#search/ForPrivacyNET
Right -- I think we are still in the process of fixing that issue. The
current situation as I understand it is that bridgestrap measures whether
your obfs4 port is reachable, and it uploads these results to the metrics
sites, and the metrics sites use them if available instead of looking
at Running.
But currently the "uploads to metrics" step happens once a day, while
bridgestrap produces results way more frequently than that.
And in the past there were surprises where the metrics side would say
something like "I'll call you running if bridgestrap said you were
reachable within the past three hours" -- which is a great design if
you are getting the bridgestrap results rapidly, but not great if you
get them once a day.
So, I'm glad to see that your relay was green again for a bit, but I
fear a bit more work remains until we get there *consistently*.
--Roger
···
On Sun, Jun 23, 2024 at 09:28:23PM +0200, lists@for-privacy.net wrote:
A few months ago there was a recommendation to not exposing OrPort for
bridges.
This had the unpleasant effect that all bridges were 'red' on Tor Metrics,
even though they were running perfectly fine.
I noticed yesterday after the meeting that everything is 'green' again. Relay Search
A few months ago there was a recommendation to not exposing OrPort for
bridges.
This had the unpleasant effect that all bridges were 'red' on Tor Metrics,
even though they were running perfectly fine.
I noticed yesterday after the meeting that everything is 'green' again. Relay Search
Right -- I think we are still in the process of fixing that issue. The
current situation as I understand it is that bridgestrap measures whether
your obfs4 port is reachable, and it uploads these results to the metrics
sites, and the metrics sites use them if available instead of looking
at Running.
But currently the "uploads to metrics" step happens once a day, while
bridgestrap produces results way more frequently than that.
And in the past there were surprises where the metrics side would say
something like "I'll call you running if bridgestrap said you were
reachable within the past three hours" -- which is a great design if
you are getting the bridgestrap results rapidly, but not great if you
get them once a day.
So, I'm glad to see that your relay was green again for a bit, but I
fear a bit more work remains until we get there *consistently*.
Yes I think the issue is somewhat hidden into collector and how/how often the tests from bridgestrap are processed.
I am counting to work on this when we are back the 2nd week of july.
Cheers,
-hiro
···
On 6/23/24 21:59, Roger Dingledine wrote:
On Sun, Jun 23, 2024 at 09:28:23PM +0200, lists@for-privacy.net wrote:
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org tor-relays Info Page
A few months ago there was a recommendation to not exposing OrPort for
bridges.
This had the unpleasant effect that all bridges were 'red' on Tor Metrics,
even though they were running perfectly fine.
I noticed yesterday after the meeting that everything is 'green' again. Relay Search
Right -- I think we are still in the process of fixing that issue. The
current situation as I understand it is that bridgestrap measures whether
your obfs4 port is reachable, and it uploads these results to the metrics
sites, and the metrics sites use them if available instead of looking
at Running.
But currently the "uploads to metrics" step happens once a day, while
bridgestrap produces results way more frequently than that.
And in the past there were surprises where the metrics side would say
something like "I'll call you running if bridgestrap said you were
reachable within the past three hours" -- which is a great design if
you are getting the bridgestrap results rapidly, but not great if you
get them once a day.
So, I'm glad to see that your relay was green again for a bit, but I
fear a bit more work remains until we get there *consistently*.
Yes I think the issue is somewhat hidden into collector and how/how often the tests from bridgestrap are processed.
I am counting to work on this when we are back the 2nd week of july.
I do not want to declare victory too soon, but I think this issue should be resolved. There was a configuration option hidden in collector that was making it process bridgestrap tests every 8 hours. I have now changed it to every hour.
Let's see.
Cheers,
-hiro
···
On 6/26/24 16:46, Hiro wrote:
On 6/23/24 21:59, Roger Dingledine wrote:
On Sun, Jun 23, 2024 at 09:28:23PM +0200, lists@for-privacy.net wrote:
Cheers,
-hiro
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org tor-relays Info Page
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org tor-relays Info Page
By the way:
I saw that everything is being prepared to shut down bridgedb and migrate
everything to rdsys.
···
On Montag, 8. Juli 2024 16:49:04 CEST Hiro wrote:
I do not want to declare victory too soon, but I think this issue should
be resolved. There was a configuration option hidden in collector that
was making it process bridgestrap tests every 8 hours. I have now
changed it to every hour.
This has been looking damn good for 4 days Relay Search
Flags, Uptime and green dot is OK
But the behaviour is not fixed. It just happened less often.
Collector should process the information it receives from rdsys every hour, but there might be a gap between when onionoo process the data and receives the information from collector.
I'll see if there is an easy fix to this and let everybody know.
-hiro
···
On 7/29/24 19:50, Toralf Förster via tor-relays wrote:
On 7/12/24 00:52, boldsuck wrote:
--
Toralf
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org tor-relays Info Page
