Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #12450

Closed (moved)
Open
Opened Jun 23, 2014 by George Kadianakis@asn

Network down race condition might lead to primary guards getting skipped

The behavior at: https://gitweb.torproject.org/tor.git/blob/d064773595f1d0bf1b76dd6f7439bff653a3c8ce:/src/or/entrynodes.c#l776

tries to ensure that if our network is down, and connections to already existing guards fail, when the network is back up we will still try to connect to the guards on the top of our list.

It does so, by checking whether the guard we connected to is a newly added one. If it is so, it assumes that this guard was added because all our previous guards were found to be down, which might be a sign of the network being down. So if that's the case, the code walks our guard list and marks all the previous guards as to be retried.

This usually works fine, but consider the case where we have 60 guards in our guard list, and the network goes back up when we walk through the 50th guard. If that's the case, the code at https://gitweb.torproject.org/tor.git/blob/d064773595f1d0bf1b76dd6f7439bff653a3c8ce:/src/or/entrynodes.c#l776 doesn't get triggered because first_contact is not true, and we still stay connected to the 50th guard.

This sounds like a bug, since we should try to connect to our primary guards (the ones at the top of the list) even then.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#12450