[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #2355 [Tor Client]: change the meaning of UseBridges
#2355: change the meaning of UseBridges
-------------------------------------+--------------------------------------
Reporter: anonym | Type: enhancement
Status: needs_review | Priority: minor
Milestone: Tor: unspecified | Component: Tor Client
Version: | Keywords:
Parent: | Points:
Actualpointsdone: | Pointsdone:
Actualpoints: |
-------------------------------------+--------------------------------------
Comment(by anonym):
I had a bit of time to look at this once more and I found a minor issue
that I fixed, so new patch.
The bug was: if Tor starts with a few bridges configured in torrc, these
are ignored until the options are updated (i.e. they we're only added if
there was an old_config).
Replying to [comment:5 anonym]:
> 2) When bridge switching (i.e. repeatedly changing bridges by removing
the old ones and adding new ones) Vidalia starts to list one "<Path Empty>
New" entry in the connection list for every abandoned bridge, or something
like that.
I've done some debugging and it's quite clear that these spurious entries
are due to connections started with
launch_direct_bridge_descriptor_fetch() -- when the decriptor has been
fetched, I believe the connection _is_ closed by Tor, but Vidalia never
learns about that happening, so these entries remain. This also happens
when adding a bridge in vanilla Tor, so it's not introduced by my patch.
The issue does, however, become more apparent with my patch since more
direct bridge fetches are done.
> 3) And here's the big one: when doing frequent bridge switching it can
occasionally happen that bootstrapping to a known working bridge fails.
Just to be clear, if this problem occurs we can just remove the bridge
through Vidalia and then re-add it and then its descriptor will be fetched
(I guess the probability that it will fail is about the same as in any
other situation, but I've never got two of these bridge fetch stalls in a
row). Similarly, if we remove the failed bridge and add another known
working bridge, the descriptor will be fetched (again, presumably with the
same fail probability).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2355#comment:7>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs