track "first" OR_CONN
Right now the first stages of the "first" OR_CONN get reported as BOOTSTRAP_STATUS_CONN_DIR and BOOTSTRAP_STATUS_HANDSHAKE (the latter is a special bootstrap phase that gets translated into BOOTSTRAP_STATUS_HANDSHAKE_DIR or BOOTSTRAP_STATUS_HANDSHAKE_OR depending on how much progress was previously reported. The logic in functions that report these events should be moved up to a new abstraction so lower level code has to track less high-level state.
This also eliminates some logic in control_event_bootstrap() that tries to figure out whether a given handshake attempt corresponds to a directory connection or an application circuit connection.
Activity
changed milestone to %Tor: 0.4.0.x-final
added 035-deferred-20180930 035-roadmap-subtask 035-triaged-in-20180711 bootstrap component::core tor/tor milestone::Tor: 0.4.0.x-final owner::catalyst parent::27103 priority::medium resolution::implemented reviewer::nickm s8-bootstrap s8-errors severity::normal sponsor::8 status::closed type::enhancement usability ux ux-team labels
This probably depends on #28226 (moved) to help disentangle some of the existing deeply buried complicated logic.
WIP branch at https://github.com/tlyu/tor/tree/orconn-tracker which also contains a patch for #27402 (moved).
The fix for this will probably fix #28884 (moved) as a side effect.
Pull request at https://github.com/torproject/tor/pull/613
Known issues:
- the way I tried to detect PT vs firewall-bypass proxy didn't actually work, so PT connections get reported as proxy connections.
- test coverage isn't great on some things because it would take longer to figure out how to mock all the right things
Trac:
Status: assigned to needs_review
This is looking solid; I don't have any must-change items. I have left a couple of questions on the PR, to make sure I understand what's going on.
One more general question: Do you think that eventually all calls to control_event_bootstrap() should come from the btrack subsystem, or do you think that the ones that remain outside it are unproblematic?
Two requests:
-
Could you please open a ticket to deal with the PT issue?
-
When I merge this later today, could you please close the tickets that are fixed by it?
Trac:
Status: needs_review to merge_ready-
Replying to nickm:
This is looking solid; I don't have any must-change items. I have left a couple of questions on the PR, to make sure I understand what's going on. Thanks! I've pushed a fixup commit to add the requested comment, and I'll start working on the control-spec.txt changes.
One more general question: Do you think that eventually all calls to control_event_bootstrap() should come from the btrack subsystem, or do you think that the ones that remain outside it are unproblematic? I think eventually all calls to
control_event_bootstrap()should come from the btrack subsystem. The directory progress reporting in particular could benefit a lot from that. Also that way we can add GETINFO handlers to the btrack subsystem to allow applications to query detailed bootstrap state information.Two requests:
-
Could you please open a ticket to deal with the PT issue? Done: #28925 (moved)
-
When I merge this later today, could you please close the tickets that are fixed by it? Will do.
-
mentioned in issue #27308 (moved)
mentioned in issue #27402 (moved)
mentioned in issue #28884 (moved)
mentioned in issue #28924 (moved)
mentioned in issue #28925 (moved)
mentioned in issue #28928 (moved)
mentioned in issue #28929 (moved)
mentioned in issue #29328 (moved)
moved to tpo/core/tor#27167 (closed)
mentioned in issue tpo/core/tor#28884 (closed)
mentioned in issue tpo/core/tor#28924 (closed)
mentioned in issue tpo/core/tor#28925 (closed)
mentioned in issue tpo/core/tor#28928 (closed)
mentioned in issue tpo/core/tor#28929 (closed)
mentioned in issue tpo/applications/tor-launcher#29328 (closed)