[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: new | Priority: minor
Milestone: Tor: unspecified | Component: Tor Client
Version: | Keywords:
Parent: | Points:
Actualpointsdone: | Pointsdone:
Actualpoints: |
-------------------------------------+--------------------------------------
Comment(by anonym):
New patch.
Now bridge descriptors are (re)fetched as soon as the list of bridges are
changed. Additionally, since there are constraints on how you can combine
UseBridges with some other options, the following seemed like reasonable
to me:
1) TunnelDirConns set to 0 only works with UseBridges set to 0
2) If we run a server, we can't have UseBridges set to 1, as before. With
UseBridges set to auto (which is the default value), bridges will not be
used, just like if we had UseBridges set to 0.
There are a couple of issues with my patch:
1) There are two (related) "FIXME" items detailing one issue -- see the
patch.
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. This seems to be more of an issue in Vidalia, though. I've
check with netstat, though, and it seems like one connections per old
bridge stays for some time before they die (perhaps the one used for
directory fetches?), but I don't know how to kill those connections.
3) And here's the big one: when doing frequent bridge switching it can
occasionally happen that bootstrapping to a known working bridge fails. It
will eventually be fetched by the scheduled fetches, but then we won't
fetch its descriptor before download_status_is_ready() thinks it's ok,
which seems to be 10+ minutes.
I've managed to reproduce it a couple of times, but I can see no pattern.
So, given this seemingly random nature of the problem, my only guess is
that there's some sort of race condition or other type of collision
affecting the call I added to fetch_bridge_descriptors() in options_act(),
config.c:1457. I have observed two things which somewhat convince me of
this:
3.1) This seems to happen more often when I have loglevel notice than
info. Hence the (admittedly very small) times required to output stuff
seems to affect this.
3.2) If I put that call earlier in options_act() (I've tried several
places) it fails every time.
Instead of calling fetch_bridge_descriptors(), another approach would be
to do a download_status_reset() on each bridge and then let
run_scheduled_events() (main.c:856) call fetch_bridge_descriptors() for
us, but that isn't as instantaneous (up to 10 seconds delay).
Any ideas?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2355#comment:5>
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