Hi, > On 14 Feb 2019, at 23:50, Katharina Kohls <katharina.kohls@xxxxxx> wrote: > >> >> We recently changed the bootstrap percentages and messages in Tor. >> Please paste the log lines that containing these bootstrap messages. >> And any error messages near those lines. > Feb 14 10:37:46.000 [notice] Bootstrapped 10%: Finishing handshake with directory server > Feb 14 10:38:32.000 [notice] I learned some more directory information, but not enough to build a circuit: We have no usable consensus. > ... > Feb 14 10:38:32.000 [notice] Bootstrapped 45%: Asking for relay descriptors for internal paths > Feb 14 10:38:32.000 [notice] I learned some more directory information, but not enough to build a circuit: We need more microdescriptors: we have 0/9, and can only build 0% of likely paths. (We have 0% of guards bw, 0% of midpoint bw, and 0% of end bw (no exits in consensus, using mid) = 0% of path bw.) > ... In this consensus, you have 9 relays. (In previous emails, your logs said "0/2".) If a future consensus only has 2 relays, you'll get similar errors to the ones you have right now. > Feb 14 10:38:32.000 [notice] The current consensus contains exit nodes. Tor can build exit and internal paths. > Feb 14 10:38:32.000 [notice] Bootstrapped 50%: Loading relay descriptors > Feb 14 10:38:32.000 [notice] Bootstrapped 80%: Connecting to the Tor network Tor logs this message when it has enough relay descriptors. So you have at least 60% of the relays in the network, which in this case is ceil(60% * 9) = 6. So in this network, you do not have a problem with the number of relays in the consensus. > Feb 14 10:38:33.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit. > Feb 14 10:38:33.000 [notice] Our circuit 0 (id: 1) died due to an invalid selected path, purpose General-purpose client. This may be a torrc configuration issue, or a bug. > Feb 14 10:38:34.000 [warn] Failed to find node for hop #1 of our path. Discarding this circuit. ... Your client can't find a valid guard. That's probably because all your relays are in the same /16. Tor builds paths from the exit to the guard. It rejects paths where any of the relays are in the same /16. (I don't know why it failed on the guard, rather than the middle.) Try setting: TestingTorNetwork 1 (But this sets a lot of other options that you may not want.) Or: EnforceDistinctSubnets 0 You might also find it useful to set: LogTimeGranularity 1 So your logs are in milliseconds, not seconds. >> >> To get good bandwidth numbers, you'll need to pass some traffic >> through your network. To get measured bandwidth in the votes, >> you'll need to run a bandwidth authority, like sbws: >> https://git.torproject.org/sbws.git > Is this optional, are there alternative ways of measuring bandwidth? It is optional: try "EnforceDistinctSubnets 0" and see if your network works without bandwidth measurements. >> It would help to know what's actually in the consensus. (See below.) >> > I pasted one of the microdescriptors at the end of the message (it's fetched from one of the authorities). >> >> Maybe there's a bug in ShutdownWaitLength. >> We changed that code recently. >> Is Tor actually shut down when you remove the files? > It is definitely shut down when I start deleting the files. >> >> When you start Tor, what is actually in the data directory? > I followed your idea of defining and deleting directories so now there are data/ cache/ and keys/ defined in the torrc and this is what I remove in the cleanup procedure. I keep the keys dir, the stats file, and the fingerprint file. The issue with old Guard entries in the new state file remains. I think I worked out why the dates are wrong: Tor randomises the dates in the state file, to reduce the accuracy of time-based forensic analysis. So I would expect to see guards spread across a few different dates. >> tor/server/all is a list of all relay descriptors that the authority knows about. >> >> But the consensus is different: it contains the relays from the authorities' >> votes, but only if those relays are reachable from the authorities >> (the Running flag), and the authorities agree on enough info about the >> relays. >> >> Please check the votes and consensuses on each authority: >> http://<hostname>/tor/status-vote/current/authority >> http://<hostname>/tor/status-vote/current/consensus >> http://<hostname>/tor/status-vote/current/consensus-microdesc > One of the microdesc files is pasted below. I see the Running flag set for several relays, along with Fast, Guard, and sometimes also Exit (for example, relay08 is defined as exit in the torrc and also shows up as Exit Fast Guard HSDir Running Stable V2Dir Valid). >> >> That's not how Tor works: >> >> Clients randomly select relays from the consensus. > Yes, and this is exactly what I need to measure in the private network. My project is about testing the consequences of the DoS features in relays and how the client reacts to being blocked (if it recognizes this at all, that's one of the things I want to find out). Sounds like a great project! Thank you for working on it. ... >> The dates are the time when Tor chose the guard. >> Maybe you're not actually deleting the state file? >> Maybe there's an undocumented state.new file? > I'm pretty much sure I delete the file and that there are no .new versions of the state file. Still, after a while the old Guards show up in the state file. What information is used to generate the state file? Maybe there is still some kind of cache left somewhere else? (Tor deliberately randomises the dates. See above.) ... >> >> Let me know if you're still having trouble. > Yes, the setup is still not in the state where the client is able to create "natural" circuits. > > network-status-version 3 microdesc ... > dir-source auth01 14EA360AE456079B386651CDEA2996A6D48F1798 100.113.5.34 100.113.5.34 7000 5000 > contact katharina.kohls@xxxxxx > vote-digest 0E3E3697D3CC785928FE2B27B43E272BB7D52650 > dir-source auth01 92E466CD419200DE68A4893EA5A758DAE70EFD9E 100.113.5.29 100.113.5.29 7000 5000 > contact katharina.kohls@xxxxxx > vote-digest 3ADC1A8BF96D74C661DF5797D2EE59FAB899DC00 Your authorities have the same nickname: tor won't get confused, but the nicknames in the logs might confuse people. > r client01 BhCZoOQt0RnwUth3dUbyVVP9wxM 2019-02-14 09:37:31 100.113.5.28 5000 0 Your clients should not be in the consensus: clients and relays behave differently when building connections and circuits. Try removing the ORPort, or setting ClientOnly 1. T
Attachment:
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev