<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <br>
    <blockquote type="cite"
      cite="mid:41C8C2AD-7053-47BD-9A72-F84E9B6D26F3@riseup.net">
      <div dir="ltr">
        <blockquote type="cite">
          <div dir="ltr"><span>All nodes bootstrap properly and reach
              100%, the authorities both manage to vote and exchange
              information. Also the relays and the client bootstrap to
              100%.</span></div>
        </blockquote>
        <div dir="ltr"><br>
        </div>
        <div dir="ltr">When are these messages logged?</div>
      </div>
    </blockquote>
    Sorry, I must update this: The authorities bootstrap to 100%, relays
    and client are stuck with 80% (sometimes reach 85%).<br>
    <blockquote type="cite"
      cite="mid:41C8C2AD-7053-47BD-9A72-F84E9B6D26F3@riseup.net">
      <div dir="ltr"><br>
        <blockquote type="cite">
          <div dir="ltr"><span>Nevertheless, the consensus seems to lack
              relays with guard flags:</span><br>
            <span></span><br>
            <span>Feb 12 10:35:56.000 [notice] I learned some more
              directory information, but not enough to build a circuit:
              We need more microdescriptors: we have 2/2,</span></div>
        </blockquote>
        <div><br>
        </div>
        <div dir="ltr">This log message says that there are only 2 nodes
          in the consensus at that time.<br>
          <blockquote type="cite">
            <div dir="ltr"><span>and can only build 0% of likely paths.
                (We have 0% of guards bw, 100% of midpoint bw, and 100%
                of end bw (no exits in consensus,</span></div>
          </blockquote>
          <div><br>
          </div>
          <div>This log message say that there are no exits in the
            consensus at that time.</div>
        </div>
      </div>
    </blockquote>
    Right now there are even less available nodes and bandwidth showing
    up in the logs. This changes between runs but never to more
    promising numbers.
    <blockquote type="cite"
      cite="mid:41C8C2AD-7053-47BD-9A72-F84E9B6D26F3@riseup.net">
      <div dir="ltr">
        <div dir="ltr">
          <div><br>
          </div>
          <blockquote type="cite">
            <div dir="ltr"><span>using mid) = 0% of path bw.)</span></div>
          </blockquote>
          <div dir="ltr">
            <blockquote type="cite"><br>
            </blockquote>
          </div>
          <span style="background-color: rgba(255, 255, 255, 0);"></span>
          <blockquote type="cite"><span style="background-color:
              rgba(255, 255, 255, 0);">Because of this, no default
              circuits can be built in the client or the relays</span></blockquote>
          <div dir="ltr"><br>
          </div>
          <div dir="ltr">When there are only 2 nodes in the network, you
            can't build a 3-hop path.</div>
        </div>
      </div>
    </blockquote>
    There should be 8 nodes in total so it's kind of strange that only 2
    seem to be available in this relay.<br>
    <blockquote type="cite"
      cite="mid:41C8C2AD-7053-47BD-9A72-F84E9B6D26F3@riseup.net">
      <div dir="ltr">
        <div dir="ltr"><br>
          <blockquote type="cite"><span style="background-color:
              rgba(255, 255, 255, 0);">in all logs the following message
              appears every second:<br>
              <br>
              [warn] Failed to find node for hop #1 of our path.
              Discarding this circuit.<br>
              <br>
              …<br>
              <br>
              In the data_dir/state file I see several guard entries:<br>
              Guard in=default rsa_id=[...] nickname=auth01
              sampled_on=2019-01-17T18:33:12 sampled_by=0.3.5.7 listed=1<br>
              Guard in=default rsa_id=[...] nickname=relay03
              sampled_on=2019-01-22T17:<a
                href="x-apple-data-detectors://4" dir="ltr"
                x-apple-data-detectors="true"
                x-apple-data-detectors-type="calendar-event"
                x-apple-data-detectors-result="4"
                style="-webkit-text-decoration-color: rgba(0, 0, 0,
                0.258824);" moz-do-not-send="true">17:10</a>sampled_by=0.3.5.7
              unlisted_since=2019-01-27T11:<a
                href="x-apple-data-detectors://6" dir="ltr"
                x-apple-data-detectors="true"
                x-apple-data-detectors-type="calendar-event"
                x-apple-data-detectors-result="6"
                style="-webkit-text-decoration-color: rgba(0, 0, 0,
                0.258824);" moz-do-not-send="true">00:36</a> listed=0<br>
              Guard in=default rsa_id=[...] nickname=relay02
              sampled_on=2019-01-24T22:<a
                href="x-apple-data-detectors://7" dir="ltr"
                x-apple-data-detectors="true"
                x-apple-data-detectors-type="calendar-event"
                x-apple-data-detectors-result="7"
                style="-webkit-text-decoration-color: rgba(0, 0, 0,
                0.258824);" moz-do-not-send="true">19:10</a>sampled_by=0.3.5.7
              unlisted_since=2019-01-29T09:<a
                href="x-apple-data-detectors://9" dir="ltr"
                x-apple-data-detectors="true"
                x-apple-data-detectors-type="calendar-event"
                x-apple-data-detectors-result="9"
                style="-webkit-text-decoration-color: rgba(0, 0, 0,
                0.258824);" moz-do-not-send="true">08:59</a> listed=0<br>
              Guard in=default rsa_id=[...] nickname=relay03
              sampled_on=2019-02-06T21:<a
                href="x-apple-data-detectors://10" dir="ltr"
                x-apple-data-detectors="true"
                x-apple-data-detectors-type="calendar-event"
                x-apple-data-detectors-result="10"
                style="-webkit-text-decoration-color: rgba(0, 0, 0,
                0.258824);" moz-do-not-send="true">07:36</a>sampled_by=0.3.5.7
              listed=1<br>
              Guard in=default rsa_id=[...] nickname=relay05
              sampled_on=2019-01-27T16:37:38 sampled_by=0.3.5.7 listed=1<br>
            </span></blockquote>
          <div dir="ltr"><br>
          </div>
          <div dir="ltr">The state file says that there were some nodes
            in some previous consensuses. None of these nodes come from
            the current consensus at the time of your log messages.</div>
        </div>
      </div>
    </blockquote>
    I use a bash script that manages all the VMs. It kills Tor on all
    machines, then waits for 5 seconds just to be sure
    (ShutdownWaitLength 0), then removes all cached, old logs, the state
    file, ... and some more stuff on the authorities (see below).<br>
    <br>
    <div style="color: #f6f6f4;background-color: #282a36;font-family: 'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback';font-weight: normal;font-size: 14px;line-height: 19px;white-space: pre;"><div><span style="color: #f6f6f4;">    ssh auth01 rm /var/lib/tor/cached</span><span style="color: #f286c4;">*</span></div><div><span style="color: #f6f6f4;">    ssh auth01 rm /var/lib/tor/</span><span style="color: #f286c4;">*</span><span style="color: #f6f6f4;">.log</span></div><div><span style="color: #f6f6f4;">    ssh auth01 rm /var/lib/tor/state</span></div>
<div><span style="color: #f6f6f4;">    ssh auth01 rm -r /var/lib/tor/router-stability</span></div><div><span style="color: #f6f6f4;">    ssh auth01 rm -r /var/lib/tor/sr-state</span></div><div><span style="color: #f6f6f4;">    ssh auth01 rm -r /var/lib/tor/v3-status-votes</span></div><div><span style="color: #f6f6f4;">    ssh auth01 rm -r /var/lib/tor/diff-cache</span></div></div>
    <blockquote type="cite"
      cite="mid:41C8C2AD-7053-47BD-9A72-F84E9B6D26F3@riseup.net">
      <div dir="ltr">
        <div dir="ltr"><br>
          <blockquote type="cite"><span style="background-color:
              rgba(255, 255, 255, 0);">The client also seems to receive
              a complete consensus, at least all fingerprints of my
              setup show up if I fetch the file manually.</span></blockquote>
          <div dir="ltr"><br>
          </div>
          How do you fetch the file manually, and from where?<br>
        </div>
      </div>
    </blockquote>
    wget <a class="moz-txt-link-freetext" href="http://authip:7000/tor/server/all">http://authip:7000/tor/server/all</a><br>
    <br>
    which should be the cached-descriptors.new file on the authority
    (which also means it gets deleted on each new startup and must be
    fresh).<br>
    <br>
    In this file I see all the fingerprints that are supposed to be
    there. It's also possible to connect to the client's control port
    and manually build circuits to all relays that should be there. This
    is an indicator that the client knows the relays (using a
    fingerprint that is not in the consensus would not work).<br>
    <br>
    Again, guards also show up in the state files of the relays <br>
    <br>
    Guard in=default rsa_id=C122CBB79DC660621E352D401AD7F781F8F6D62D
    nickname=relay03 sampled_on=2019-02-07T16:24:21 sampled_by=0.3.5.7
    listed=1<br>
    Guard in=default rsa_id=2B74825BE33752B21D17713F88D101F3BADC79BC
    nickname=relay06 sampled_on=2019-02-03T22:16:29 sampled_by=0.3.5.7
    listed=1<br>
    Guard in=default rsa_id=E4B1152CDF0E5FE697A3E916716FC363A2A0ACF3
    nickname=relay07 sampled_on=2019-02-12T18:51:00 sampled_by=0.3.5.7
    listed=1<br>
    Guard in=default rsa_id=911EDA6CB639AAE955517F02AA4D651E0F7F6EFD
    nickname=relay02 sampled_on=2019-02-11T22:58:28 sampled_by=0.3.5.7
    listed=1<br>
    Guard in=default rsa_id=8E574F0C428D235782061F44B2D20A66E4336993
    nickname=relay05 sampled_on=2019-02-01T17:46:05 sampled_by=0.3.5.7
    listed=1<br>
    <br>
    The dates are still old, but I delete all states in the big cleanup
    procedure. Are there some more old caches I need to remove, where
    does the date information come from?<br>
    <br>
    <blockquote type="cite"
      cite="mid:41C8C2AD-7053-47BD-9A72-F84E9B6D26F3@riseup.net">
      <div dir="ltr">I'm not sure what is happening here. It looks like
        some consensuses only have 2 nodes. But other consensuses have
        most of the nodes.</div>
      <div dir="ltr"><br>
      </div>
      <div dir="ltr">You might have a bug in your network setup, or you
        may have found a bug in Tor.</div>
    </blockquote>
    I think it's a bug somewhere in the setup but I just can't find it
    :( <br>
    <blockquote type="cite"
      cite="mid:41C8C2AD-7053-47BD-9A72-F84E9B6D26F3@riseup.net">
      <div dir="ltr"><br>
      </div>
      <div dir="ltr">The most likely explanation is that you had a
        working network at some time, which gave you the state file. And
        you had a failed network at some time, which gave you the log
        messages.</div>
      <div dir="ltr"><br>
      </div>
      <div dir="ltr">I suggest that you start again with the same
        config, but remove all previous state.</div>
      <div dir="ltr">(Move the cached state, consensuses, descriptors,
        and log files somewhere else. Do not remove the keys.)</div>
      <div dir="ltr"><br>
      </div>
      <div dir="ltr">Then you'll know if your current network actually
        works.</div>
    </blockquote>
    Questions are: Why does the client know all the relays' fingerprints
    but the network still has problems finishing the bootstrapping and
    building a complete circuit? Are there any other things I should
    look into and check to understand the problem?<br>
    <blockquote type="cite"
      cite="mid:41C8C2AD-7053-47BD-9A72-F84E9B6D26F3@riseup.net">
      <div dir="ltr"><br>
      </div>
      <div dir="ltr">T</div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
tor-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>