dns failures prevent legitimate options being set
Outright hostname lookup failures for previously configured hidden services prevent other options being set while DNS is down.
For example, I configure a hidden service redirecting to google.com while DNS is working. DNS subsequently stops working, e.g. nameserver becomes completely unreachable. If I then attempt to set a config option using the controller, it will not get set as long as tor cannot resolve the hidden service name.
Rejection of hidden service configurations (and hence any subsequent or unrelated config change) made while tor is running needs to be more tolerant of lookup failures.
The following attempts to validate the hidden service config currently in use (and previously validated when DNS was working). If the validation fails, it must be because DNS is down, so the existing config is retained. If the user was attempting to add a new hidden service config, then it doesn't get added.
Index: src/or/config.c
===================================================================
--- src/or/config.c (revision 10545)
+++ src/or/config.c (working copy)
@@ -963,10 +963,15 @@
}
}
- if (running_tor && rend_config_services(options, 0)<0) {
- log_warn(LD_BUG,
- "Previously validated hidden services line could not be added!");
- return -1;
+ if (running_tor && rend_config_services(options, 1)<0) {
+ log_warn(LD_CONFIG,
+ "Previously validated hidden services line no longer valid! Retaining existing hidden services config if there is one.");
+ }else{
+ if (rend_config_services(options, 0)<0){
+ log_warn(LD_BUG,
+ "Previously validated hidden services line could not be added!");
+ return -1;
+ }
}
if (running_tor) {
@@ -2920,9 +2925,10 @@
}
}
+/*
if (rend_config_services(options, 1) < 0)
REJECT("Failed to configure rendezvous options. See logs for details.");
-
+*/
if (parse_virtual_addr_network(options->VirtualAddrNetwork, 1, NULL)<0)
return -1;
[Automatically added by flyspray2trac: Operating System: All]