Skip to content

guardmgr should log bridge/pt connection status

If the user is in a situation where they need bridges (and PTs), they may well need to try multiple different approaches.

Currently, we seem to require the user to do the following:

  1. Configure some bridge line(s)
  2. Ask arti to reload config
  3. Wait and see if it seems to be working, for which there are I think these strategies:
    • Try to make sense of our laundered logs and figure out what it all means (almost impossible if the user has configured multiple bridges, since relating events to particular bridges won't be possible)
    • Turn off log laundering (undesirable) and try to figure out what the log messages mean (not easy for a lay user)
    • Keep trying to reload a client connection (eg a via-Tor web page) to see if it works, and give up after some unknown and unknowable period

This is IMO not a reasonable user interface. The user needs to be able to tell the status of each bridge line in a useful way. The reported status should be resolvable into "this seems to be working" vs "we're still trying" vs "we timed out" vs "this is definitely broken" by a user without deep familiarity with Tor.

Right now we don't have any API output from Arti that is really nice for giving this inforamtion. In the absence of that (which I think the design of which is an open problem) IMO we should report this in log messages.

In !831 (comment 2851762) we discussed a logging point in the bridge desc manager. Based on my analysis above, I agree that the bridge desc manager should launder the bridge identity when logging, because the bridge desc manager is not able to do the job I describe above because it doesn't have the right information.

The guardmgr does have this information, I think, and IMO it should log, for each bridge we try to use,

  • When we start to try to use it
  • The first time we successfully make a multihop circuit through it
  • If we decide it's broken, printing in the log message the actual underlying error

These messages should be accompanied by enough inforamtion to decide which bridge line is involved. But it probably ought not to include the whole bridge line. We already have a rule that bridge id sets must be nonoverlapping, so maybe the ids will do. Or maybe the index in the config array is better.