Hi, > On 14 Feb 2019, at 23:50, Katharina Kohls <katharina.ko...@rub.de> 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.ko...@rub.de > vote-digest 0E3E3697D3CC785928FE2B27B43E272BB7D52650 > dir-source auth01 92E466CD419200DE68A4893EA5A758DAE70EFD9E 100.113.5.29 > 100.113.5.29 7000 5000 > contact katharina.ko...@rub.de > 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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
