some cleanups. more probably remain, but hey, it's an alpha.

time to put out the bugfix release.


svn:r9309

ChangeLog

@@ -1,5 +1,21 @@
-Changes in version 0.1.2.6-alpha - 2007-??-??
-  o Minor features (controller):
+Changes in version 0.1.2.6-alpha - 2007-01-09
+  o Major bugfixes:
+    - Fix an assert error introduced in 0.1.2.5-alpha: if a single TLS
+      connection handles more than 4 gigs in either direction, we assert.
+    - Fix an assert error introduced in 0.1.2.5-alpha: if you're an
+      advertised exit node, somebody might try to exit from you when
+      you're bootstrapping and before you've built your descriptor yet.
+
+  o Minor bugfixes:
+    - Warn if we (as a server) find that we've resolved an address that we
+      weren't planning to resolve.
+    - Warn that using select() on any libevent version before 1.1 will be
+      unnecessarily slow (even for select()).
+    - Flush ERR-level controller status events just like we currently
+      flush ERR-level log events, so that a Tor shutdown doesn't prevent
+      the controller from learning about current events.
+
+  o Minor features (more controller status events):
     - Implement EXTERNAL_ADDRESS server status event so controllers can
       learn when our address changes.
     - Implement BAD_SERVER_DESCRIPTOR server status event so controllers
@@ -27,27 +43,8 @@ Changes in version 0.1.2.6-alpha - 2007-??-??
       about changes to DNS server status.
 
   o Minor features (directory):
-    - Authorities do not recommend exits as guards if this would shift
-      excess load to the exit nodes.
-
-  o Major bugfixes:
-    - Fix an assert error introduced in 0.1.2.5-alpha: if a single TLS
-      connection handles more than 4 gigs in either direction, we assert.
-    - Fix an assert error introduced in 0.1.2.5-alpha: if you're an
-      advertised exit node, somebody might try to exit from you when
-      you're bootstrapping and before you've built your descriptor yet.
-
-  o Minor bugfixes:
-    - Restore a warning message if we accidentally resolve an address that
-      we weren't planning to resolve.
-    - Prevent an (unlikely) bug on 32-bit architectures that could make
-      directories send 503s incorrectly when BandwidthBurst plus 2 times
-      BandwidthRate was over to 2 GB.
-    - Warn that using select() on any libevent version before 1.1 will be
-      unnecessarily slow (even for select()).
-    - Flush ERR-level status events just like we currently flush ERR-level
-      log events, so that a Tor shutdown doesn't prevent the controller from
-      learning about current events.
+    - Authorities no longer recommend exits as guards if this would shift
+      too much load to the exit nodes.
 
 
 Changes in version 0.1.2.5-alpha - 2007-01-06

doc/control-spec.txt

@@ -1089,11 +1089,12 @@ do for each. -RD]
   Actions for STATUS_CLIENT severity WARN events can be as follows:
 
      DANGEROUS_SOCKS
-     "PROTOCOL=SOCKS4/SOCKS4a/SOCKS5"
+     "PROTOCOL=SOCKS4/SOCKS5"
      "ADDRESS=IP:port"
-       A connection was made to Tor's SOCKS port that used a raw IP
-       address.  If the client application got this address from
-       gethostbyname(), it's leaking target addresses via DNS.
+       A connection was made to Tor's SOCKS port using one of the SOCKS
+       approaches that doesn't support hostnames -- only raw IP addresses.
+       If the client application got this address from gethostbyname(),
+       it may be leaking target addresses via DNS.
 
      SOCKS_UNKNOWN_PROTOCOL
        "DATA=string"
@@ -1102,7 +1103,13 @@ do for each. -RD]
        using Tor as an HTTP proxy?   The DATA is the first few characters
        sent to Tor on the SOCKS port.
 
-     BAD_HOSTNAME
+     SOCKS_BAD_HOSTNAME
+     [unimplemented]
+     // Some application gave us a funny-looking hostname. Perhaps
+     // it is broken? In any case it won't work with Tor and the user
+     // should know.
+
+     UNRECOGNIZED_ROUTER
      [unimplemented]
      // a nickname we asked for is unavailable. no need for this
      // quite yet, since no end-user controllers let you configure that.
@@ -1118,7 +1125,7 @@ do for each. -RD]
      "HOSTNAME=NAME"
      "METHOD=CONFIGURED/DIRSERV/RESOLVED/INTERFACE/GETHOSTNAME"
        Our best idea for our externally visible IP has changed to 'IP'.
-       If 'NAME' is present, we got the new IP by resolving 'NAME'.  If the
+       If 'HOSTNAME' is present, we got the new IP by resolving 'NAME'.  If the
        method is 'CONFIGURED', the IP was given verbatim as a configuration
        option.  If the method is 'RESOLVED', we resolved the Address
        configuration option to get the IP.  If the method is 'GETHOSTNAME',
@@ -1163,6 +1170,7 @@ do for each. -RD]
      "STATUS=" "UP" / "DOWN"
      "ERR=" message
         One of our nameservers has changed status.
+        // actually notice
 
      NAMESERVER_ALL_DOWN
         All of our nameservers have gone down.
@@ -1185,6 +1193,7 @@ do for each. -RD]
      ACCEPTED_SERVER_DESCRIPTOR
      "DIRAUTH=addr:port"
         A single directory authority accepted our descriptor.
+        // actually notice
 
   Actions for STATUS_SERVER severity ERR events can be as follows:
 

src/or/dns.c

@@ -186,7 +186,7 @@ evdns_log_cb(int warn, const char *msg)
      * nameservers have failed' if we're completely out of nameservers;
      * otherwise, the situation is tolerable. */
     warn = 0;
-    control_event_server_status(LOG_WARN,
+    control_event_server_status(LOG_NOTICE,
                                 "NAMESERVER_STATUS NS=%s STATUS=DOWN ERR=%s",
                                 ns, escaped(err));
     tor_free(ns);