[or-cvs] r9309: some cleanups. more probably remain, but hey, it's an alpha. (in tor/trunk: . doc src/or)
arma at seul.org
arma at seul.org
Tue Jan 9 05:14:42 UTC 2007
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);
More information about the tor-commits
mailing list