On Fri, 19 Jan 2018 23:22:00 +0000 iry iry@riseup.net wrote:
According to the Tor manual: https://www.torproject.org/docs/tor-manual-dev.html.en
DisableNetwork 0|1 When this option is set, we don’t listen for or accept any connections other than controller connections, and we close (and don’t reattempt) any outbound connections. Controllers sometimes use this option to avoid using the network until Tor is fully configured. (Default: 0)
However, it seems when DisableNetwork is set to 1, /var/run/tor/control does not exist anymore making us cannot get a controller from socket file. (stem.control.Controller.from_socket_file() is affected in this case: https://stem.torproject.org/api/control.html#stem.control.Controller.fro m_socket_file)
I'm fairly certain you are doing something wrong, because I'm using a tor process that was launched with DisableNetwork set to 1 in the torrc, and toggled to 0 via the ControlPort right now to browse the web (Tested with the copy of 0.3.1.9 that is distributed with Tor Browser).
https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tree/dat... https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/tree/src...
To reproduce this working, if anyone out there still uses the sandbox I wrote, and can get a working browser without using an external tor instance, ta dah, it's working.
Normal Tor Browser has a similar launch process, and can even be coaxed into using AF_UNIX sockets (though it's utterly pointless to do so).
nb: It can take a while for the control port to actually be available after the tor daemon is spawned. The best way I found to deal with this is via using `ControlPortWriteToFile` since the file gets created after the control port listener is created. You could also use something like inotify on Linux, but that's non-portable.
Regards,