Re: [tor-dev] Why is my bridge not publishing statistics?

2017-05-06 Thread David Fifield
On Sat, May 06, 2017 at 09:25:11AM -0700, David Fifield wrote:
> > You're right that this is a fragile situation. Maybe we should recommend
> > that if you firewall your ORPort, you also set "AssumeReachable 1"
> > in your torrc?
> 
> I've just set "AssumeReachable 1"; let's see if that helps anything.

Setting "AssumeReachable 1" seems to have worked.

https://atlas.torproject.org/#details/5481936581E23D2D178105D44DB6915AB06BFB7F
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


[tor-dev] Chutney Default: DNS or Offline?

2017-05-06 Thread teor
Dear chutney users,

Do you use DNS with chutney?
(Chutney uses IP addresses by default.)

Chutney has never worked offline, because Tor Exits check DNS before
publishing their exit policy. And if DNS fails while a test is being
run, chutney fails. (See Tor bug #21900.)

We can make chutney work offline by disabling DNS.
See the chutney bug at:
https://trac.torproject.org/projects/tor/ticket/21903

But we need to decide what the default is:

Do you want chutney to work offline by default?
Or do you want chutney to have working DNS by default?

T

--
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org






signature.asc
Description: Message signed with OpenPGP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


Re: [tor-dev] Why is my bridge not publishing statistics?

2017-05-06 Thread David Fifield
On Sat, May 06, 2017 at 03:41:28AM -0400, Roger Dingledine wrote:
> On Fri, May 05, 2017 at 04:30:52PM -0700, David Fifield wrote:
> > But if it's the case that an unreachable ORPort causes descriptors not
> > to be uploaded, then why do the default obfs4 bridges appear in Atlas?
> 
> Tor relays (and bridges) test their reachability by making circuits
> that loop back to themselves, and they consider themselves reachable
> when an incoming connection sends a create cell (see the end of
> onionskin_answer()).
> 
> You might think that these two actions are more connected, i.e. that
> it needs to be one of the loop circuits that sends the create cell,
> but no, they're completely disconnected. So the relay (or bridge)
> can launch all the loop circuits it wants, and they can all fail, but
> if something causes an incoming connection that sends a create cell,
> it will happily conclude that it's reachable.
> 
> So it's likely that the reason the default bridges are publishing to
> the bridge authority is because somebody used them via obfs4, at which
> point they decided they were reachable, at which point they decided it
> was cool to publish.

Okay, thanks. It still doesn't fully make sense to me, because while
some of the default bridges are in Atlas, not all of them are (for
example the two from https://bugs.torproject.org/18050). I don't think
it's possible that they haven't gotten *any* client traffic.

I wonder if it has something to do with the tor version number?

> You're right that this is a fragile situation. Maybe we should recommend
> that if you firewall your ORPort, you also set "AssumeReachable 1"
> in your torrc?

I've just set "AssumeReachable 1"; let's see if that helps anything.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


Re: [tor-dev] Why is my bridge not publishing statistics?

2017-05-06 Thread Roger Dingledine
On Fri, May 05, 2017 at 04:30:52PM -0700, David Fifield wrote:
> But if it's the case that an unreachable ORPort causes descriptors not
> to be uploaded, then why do the default obfs4 bridges appear in Atlas?

Tor relays (and bridges) test their reachability by making circuits
that loop back to themselves, and they consider themselves reachable
when an incoming connection sends a create cell (see the end of
onionskin_answer()).

You might think that these two actions are more connected, i.e. that
it needs to be one of the loop circuits that sends the create cell,
but no, they're completely disconnected. So the relay (or bridge)
can launch all the loop circuits it wants, and they can all fail, but
if something causes an incoming connection that sends a create cell,
it will happily conclude that it's reachable.

So it's likely that the reason the default bridges are publishing to
the bridge authority is because somebody used them via obfs4, at which
point they decided they were reachable, at which point they decided it
was cool to publish.

You're right that this is a fragile situation. Maybe we should recommend
that if you firewall your ORPort, you also set "AssumeReachable 1"
in your torrc?

--Roger

___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev