On 8/21/07, coderman <[EMAIL PROTECTED]> wrote: > ... > this appears to be a linux'ism and applies only when going from an > unspecified bind (0.0.0.0) to a specified bind to an address on the > host. changing specified bind addresses works as expected.
two issues here, one that i completely overlooked (thanks tup!) the linux'ism described above may or may not be a problem. there is a bigger issue affecting all platforms first: when reloading the config (ala SIGHUP or control port), the Tor process tries to apply the various settings in an "undoable" fashion, such that if the configuration fails, it reverts to its previous state. that is, set_options tries options_act_reversible which calls retry_all_listeners which calls retry_listeners for each type with a replaced_conns passed. this results in behavior where a listening socket bound to 0.0.0.0 is open at the same time tor tries to bind to a specified address, like 127.0.0.1, which obviously fails. this doesn't cause a problem when you start with a specified address because multiple specified addresses can be bound to the same port since Tor is using SO_REUSEADDR. question for the Tor devs: two possible ways to resolve this: 1. check for a change from unspecified to specified address in any of the settings and disallow it. (this should generate a warning in the options_transition_allowed() checks) 2. modify retry_listeners so that when a listen port is previously bound to 0.0.0.0 it does the following: a. close the existing port immediately, instead of adding it to the replace queue. b. add this 0.0.0.0:port to an "undo" list in case subsequent changes fail. c. bind to the new address:port and return success, or d. close the attempted socket which caused a failed bind, and re-open the previous 0.0.0.0:port socket so undo behavior is preserved. i'd really like to be able to modify a running instance to change from unspecified to specified binds without a restart. this bit me once already, and i think it is worth pursuing unless too complicated to implement. last caveat: the linux'ism still may be a problem. the apparent workaround for this is a small delay before rebinding. the fix above would at least correct the behavior on most platforms, leaving loonix to be dealt with if needed. best regards,
