start sending "COUNT=%d RECOMMENDATION=%s" key/values on bootstrap

problem status events, so the controller can hear about problems even
before tor decides they're worth reporting for sure.


svn:r15357

doc/TODO

@@ -340,15 +340,17 @@ R - investigate: it looks like if the bridge authority is unreachable,
   o directory authorities shouldn't complain about bootstrapping problems
     just because they do a lot of reachability testing and some of
     it fails.
-R - if your bridge is unreachable, it won't generate enough connection
+R * if your bridge is unreachable, it won't generate enough connection
     failures to generate a bootstrap problem event.
 R - if "no running bridges known", an application request should make
     us retry all our bridges.
-R - get matt to fix vidalia so it moves to a "starting tor" bootstrap
+  o get matt to fix vidalia so it moves to a "starting tor" bootstrap
     state if it hasn't gotten any status events. Maybe it can even be
     more certain by checking the version (<0211) and/or looking at the
     results of the getinfo.
-R - in circuituse.c,
+R - get matt to make vidalia do a getinfo status/bootstrap-phase to
+    get caught up after it connects.
+R * in circuituse.c,
     /* XXX021 consider setting n_conn->socket_error to TIMEOUT */
 
 For 0.2.1.x:

doc/spec/proposals/137-bootstrap-phases.txt

@@ -30,7 +30,8 @@ Status: Open
 
   So in this case we send
   650 STATUS_CLIENT NOTICE/WARN BOOTSTRAP \
-  PROGRESS=num TAG=Keyword SUMMARY=String WARNING=String REASON=Keyword
+  PROGRESS=num TAG=Keyword SUMMARY=String \
+  [WARNING=String REASON=Keyword COUNT=num RECOMMENDATION=Keyword]
 
   The arguments MAY appear in any order. Controllers MUST accept unrecognized
   arguments.
@@ -47,8 +48,10 @@ Status: Open
   (severity notice) or an indication of a bootstrapping problem
   (severity warn). If severity warn, it should also include a "warning"
   argument string with any hints Tor has to offer about why it's having
-  troubles bootstrapping, and a "reason" string that lists of the reasons
+  troubles bootstrapping, a "reason" string that lists one of the reasons
-  allowed in the ORConn event.
+  allowed in the ORConn event, a "count" number that tells how many
+  bootstrap problems there have been so far at this phase, and a
+  "recommendation" keyword to indicate how the controller ought to react.
 
 3. The bootstrap phases.
 
@@ -182,21 +185,23 @@ Status: Open
   When an OR Conn fails, we send a "bootstrap problem" status event, which
   is like the standard bootstrap status event except with severity warn.
   We include the same progress, tag, and summary values as we would for
-  a normal bootstrap event, but we also include 'warning' and 'reason'
+  a normal bootstrap event, but we also include "warning", "reason",
-  strings.
+  "count", and "recommendation" key/value combos.
 
-  The reason strings are long-term-stable controller-facing tags to
+  The "reason" values are long-term-stable controller-facing tags to
   identify particular issues in a bootstrapping step.  The warning
-  strings, on the other hand, are human-readable.  Controllers SHOULD
+  strings, on the other hand, are human-readable. Controllers SHOULD
-  NOT rely on the format of any warning string.
+  NOT rely on the format of any warning string. Currently the possible
-
+  values for "recommendation" are either "ignore" or "warn" -- if ignore,
-  Currently Tor ignores the first nine bootstrap problem reports for
+  the controller can accumulate the string in a pile of problems to show
-  a given phase, reports the tenth to the controller, and then ignores
+  the user if the user asks; if warn, the controller should alert the
-  further problems at that phase. Hopefully this is a good balance between
+  user that Tor is pretty sure there's a bootstrapping problem.
-  tolerating occasional errors and reporting serious problems quickly. (We
+
-  will want to revisit this approach if there are many different 'reason'
+  Currently Tor uses recommendation=ignore for the first nine bootstrap
-  values being reported among the first ten problem reports, since in
+  problem reports for a given phase, and then uses recommendation=warn
-  this case the controller will only hear one of them.)
+  for subsequent problems at that phase. Hopefully this is a good
+  balance between tolerating occasional errors and reporting serious
+  problems quickly.
 
 5. Suggested controller behavior.
 
@@ -217,7 +222,7 @@ Status: Open
   Controllers should also have some mechanism to alert their user when
   bootstrapping problems are reported. Perhaps we should gather a set of
   help texts and the controller can send the user to the right anchor in a
-  "bootstrapping problems" help page?
+  "bootstrapping problems" page in the controller's help subsystem?
 
 6. Getting up to speed when the controller connects.
 

src/or/control.c

@@ -3858,12 +3858,15 @@ control_event_bootstrap_problem(const char *warn, int reason)
   int status = bootstrap_percent;
   const char *tag, *summary;
   char buf[BOOTSTRAP_MSG_LEN];
+  const char *recommendation = "ignore";
 
   if (bootstrap_percent == 100)
     return; /* already bootstrapped; nothing to be done here. */
 
-  if (++bootstrap_problems != BOOTSTRAP_PROBLEM_THRESHOLD)
+  bootstrap_problems++;
-    return; /* no worries yet */
+
+  if (bootstrap_problems >= BOOTSTRAP_PROBLEM_THRESHOLD)
+    recommendation = "warn";
 
   while (status>=0 && bootstrap_status_to_string(status, &tag, &summary) < 0)
     status--; /* find a recognized status string based on current progress */
@@ -3872,9 +3875,11 @@ control_event_bootstrap_problem(const char *warn, int reason)
            status, summary, warn,
            orconn_end_reason_to_control_string(reason));
   tor_snprintf(buf, sizeof(buf),
-      "BOOTSTRAP PROGRESS=%d TAG=%s SUMMARY=\"%s\" WARNING=\"%s\" REASON=%s",
+      "BOOTSTRAP PROGRESS=%d TAG=%s SUMMARY=\"%s\" WARNING=\"%s\" REASON=%s "
+      "COUNT=%d RECOMMENDATION=%s",
       bootstrap_percent, tag, summary, warn,
-      orconn_end_reason_to_control_string(reason));
+      orconn_end_reason_to_control_string(reason), bootstrap_problems,
+      recommendation);
   tor_snprintf(last_sent_bootstrap_message,
                sizeof(last_sent_bootstrap_message),
                "WARN %s", buf);