Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #9229
Closed (moved) (moved)
Open
Issue created Jul 08, 2013 by Philipp Winter@phw

While bootstrapping, Tor clients stall for 60s when obfsproxy bridges are used.

When Tor bootstraps using obfsproxy, it stalls for 60 seconds. The last three log messages before that happening are:

[notice] Bootstrapped 50%: Loading relay descriptors.
[notice] new bridge descriptor 'bzoum' (fresh): $2ADFE7AA8D272C520D1FBFBF4E413F3A1B26313D~bzoum at [redacted]
[notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus.

After 60 seconds, it continues to bootstrap to 100%. This was observed for all pluggable transports: flash proxies, obfs{2,3} and ScrambleSuit. Vanilla bridges do not seem to be affected by this. Also, the very first bootstrap (i.e., with an empty data directory) also seems to be unaffected by this.

I attached two files containing debug logs (after the second bootstrap) of obfs3 and vanilla bridges. I removed the timestamps to make it easy to compare both of them.

I tested this with Tor v0.2.4.15-rc and obfsproxy da31ffc638a2727df1679bc888c2a8c1c49809a9.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking