#20499: A running Tor won't update the microdesc consensus --------------------------+------------------------------------ Reporter: rubiate | Owner: Type: defect | Status: new Priority: High | Milestone: Tor: 0.2.9.x-final Component: Core Tor/Tor | Version: Tor: 0.2.9.4-alpha Severity: Normal | Resolution: Keywords: regression | Actual Points: Parent ID: | Points: Reviewer: | Sponsor: --------------------------+------------------------------------
Comment (by teor): Replying to [comment:19 arma]: > Replying to [comment:14 rubiate]: > > I set up two new relays: > > [...] > > Rough timeline: > > > > 10:36 Both start up > > [...] both request the consensus every minute > > 10:41 they reach a fail count of 10 > > What is wrong with your relay set-up such that they both failure to get a consensus at bootstrap? :) > > Are you firewalled in some weird way? Are they trying to fetch it from fallbackdirs and those are surprisingly faily? Are they trying from directory authorities and our authorities are no good? > > Anyway, it looks like 'revert' is the winner, but it would still be great to learn what is so helpful about your test environment that it triggers this bug so well. Well, they're in Australia, so latency is high, and measured bandwidth is low. But I'm not sure that would cause so many failures. Maybe something with OpenBSD? My relay at the same provider has AccountingMax set, and has disabled its DirPort, so it's much harder to interrogate. It's on FreeBSD, but on 0.2.8.7 (still waiting for a package update), and up to date with its consensuses. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20499#comment:20> Tor Bug Tracker & Wiki <https://trac.torproject.org/> The Tor Project: anonymity online _______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs