[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[or-cvs] r9309: some cleanups. more probably remain, but hey, it's an alpha. (in tor/trunk: . doc src/or)



Author: arma
Date: 2007-01-09 00:14:34 -0500 (Tue, 09 Jan 2007)
New Revision: 9309

Modified:
   tor/trunk/ChangeLog
   tor/trunk/doc/control-spec.txt
   tor/trunk/src/or/dns.c
Log:
some cleanups. more probably remain, but hey, it's an alpha.
time to put out the bugfix release.


Modified: tor/trunk/ChangeLog
===================================================================
--- tor/trunk/ChangeLog	2007-01-09 00:59:11 UTC (rev 9308)
+++ tor/trunk/ChangeLog	2007-01-09 05:14:34 UTC (rev 9309)
@@ -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,29 +43,10 @@
       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.
+    - Authorities no longer recommend exits as guards if this would shift
+      too much 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.
-
-
 Changes in version 0.1.2.5-alpha - 2007-01-06
   o Major features:
     - Enable write limiting as well as read limiting. Now we sacrifice

Modified: tor/trunk/doc/control-spec.txt
===================================================================
--- tor/trunk/doc/control-spec.txt	2007-01-09 00:59:11 UTC (rev 9308)
+++ tor/trunk/doc/control-spec.txt	2007-01-09 05:14:34 UTC (rev 9309)
@@ -1089,11 +1089,12 @@
   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,8 +1103,14 @@
        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 @@
      "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 @@
      "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 @@
      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:
 

Modified: tor/trunk/src/or/dns.c
===================================================================
--- tor/trunk/src/or/dns.c	2007-01-09 00:59:11 UTC (rev 9308)
+++ tor/trunk/src/or/dns.c	2007-01-09 05:14:34 UTC (rev 9309)
@@ -186,7 +186,7 @@
      * 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);