Nice timing, we just expanded our tutorials around this! For this you should use new_circuit() and attach_stream() rather than NEWNYM. For an example of doing this see...
I put this example together using this STEM Tutorial. It shows the use of
to make your own circuits, attach a stream, and make a request using the requesocks module (which is just the requests module with SOCKS5 support). Hope this helps.
If your configured Tor socks port is 9150, then you can try this command:
curl --socks5-hostname localhost:9150 http://ipecho.net/plain
You also can configure it by editing your config file (usually named torrc) or pass an option named socksport as command-line argument when executing Tor.
What should I be reading?
It depends on your platform but since your on a deb based distro it should be easy...
If I use the synaptic package manager to install Tor in, say, Linux Mint, will I get the most recent stable version of Tor?
Not by default, but it will be if you get it from deb.torproject.org. See ...
I think you're confused a little. The Tor cloud instance is not about surfing at all, and there's not too much to interact with for a Tor relay.
Exposing a Tor control port over the network is a bad idea, because the protocol is not secured and used only for local connections directly to it. To make use of it on your ec2 instance, install the controller ...
If you want to use event-based code (namely Twisted), there's https://github.com/habnabit/txsocksx for client-side stuff (i.e. socks proxy) and http://txtorcon.readthedocs.org/en/latest/ for speaking Tor's control protocol to Tor (and other things, like launching new Tor instances for hidden services, etc).
To force an application to use a particular circuit your best option is to handle attaching streams to circuits yourself. For an example of this see its tutorial. Usually you'll leave __LeaveStreamsUnattached set, and have all new stream events bind it to the circuit you're after.
Tor automatically builds the fastest circuits possible for you by attempting to see how much bandwidth is available for each node. It doesn't rely on the client supplied Bandwidth value but actually tries to test the node by building various circuits and timing the requests. Sometimes those tests are inconclusive, never get run, or just come up with bad ...
The tl;dr is that FTP and .onion do not go well together and never will, due to how the FTP protocol works. For more details, see below.
FTP goes a little like this:
Client connects to the "command" channel.
Client logs in to the "command" channel.
Client asks for some data over the "command" channel.
If you're using Active Mode:
Client opens up a ...
Not really. You can know it's observed bandwidth, and what it's throughput has been seen to be but not "available" bandwidth. That would require knowledge of, for example, the upperbounds of throughput in any given situation which would be infeasible to calculate and wouldn't be consistent as it would necessarily depend on factors outside of the control or ...
There is a project named: torflow and one of the plugins named OP-addon is a good solution for tor path generation and circuit handling with lots of measurements and analyzing goodies.
from the documentation of OP-addon:
By making use of the Tor control protocol, it replaces Tor's
default path selection and circuit management by highly configurable
There is a tutorial on retrieving the number of bytes a relay has written and read here (run the code after installing stem):
from stem.control import Controller
with Controller.from_port(port = 9051) as controller:
controller.authenticate() # provide the password here if you set one
bytes_read = controller.get_info("traffic/read")
bytes_written = ...
A Tor relay's descriptor is available at that relay as the resource '/tor/server/authority[.z]'. This is useful when you don't know the relay's fingerprint.
Using IPredator as an example:
Or, using stem:
dir_port = ('220.127.116.11', 9030)
No ControlPort is specified in the torrc that your copy of Tor is trying to read.
ControlPort PORT|unix:path|auto [flags]
With the default of 0 meaning not to create one.
Instead either specify one in the place that tor.exe looks for it's torrc by default or use launch_tor_with_config instead.
from stem.process ...
You need to query the client bootstrap status. It's done - as it's said in control protocol spec like this:
telnet 127.0.0.1 9051
Connected to 127.0.0.1.
Escape character is '^]'.
250-status/bootstrap-phase=NOTICE BOOTSTRAP PROGRESS=100 TAG=done SUMMARY="Done"
There's no log for this kind of information - and for a good reason: it can hurt the privacy and anonymity of Tor. You can - technically - poll Tor regulary through Stem and keep the log for yourself, but anyway - it's a bad idea IMHO.
Can you please put some more details about what do you need it for? Maybe this task can be solved in another way?
Try removing this. Because once the Socket is set the controller cannot change it.
from stem import Signal
from stem.control import Controller
with Controller.from_port(port = 9151) as controller:
Or if you want to use it for changing identity every time you run the python file use it at ...
10 -- TIMEOUT (Circuit construction took too long)
11 -- DESTROYED (The circuit was destroyed w/o client TRUNCATE)
My guess is that there's something wrong with how you're trying to build the circuits in the first place. Have a look at how ExitMap currently builds custom ...
Please file a ticket with code and the descriptor that reproduces this. You're right that the RouterStatusEntryV3 class has a measured attribute. First guess is that you might have a RouterStatusEntryV2 instance instead.
The Tor metrics portal has historic information about consensuses. You could download the archive and search through them. You don't need Stem for that unless you want to verify the consensuses. I'd suggest just using grep instead of Python to check if a relay was in the consensus at a specific time.
Answer to question 1 -- part 2 (but NOT question 2):
OK, I finally found the ultimate tool for analyzing the tor circuit--arm. I'm really surprised and disappointed that no one here pointed to this useful tool. It would have saved a lot of time on my part and mirimir's. This tool shows exactly what I wanted to know. Tor actually creates multiple circuits ...
Answer to question 1, part 1 (NOT the final answer):
I think I have the answer to the first half of my first question: is the address gotten by 'wget' or 'curl' the entry node?
My script gives:
Jul 29 06:37:47.000 [info] const node_t *...
I have re-written the code, as it seems my code was just awful. I'm not sure what the problem was, however, here's the update for anyone trying to do the same:
assert str is not bytes
from lib_socks_proxy_2013_10_03 import monkey_patch as socks_proxy_monkey_patch
I replied on irc but maybe you had left...
If you're not getting an exception then what makes you think it isn't working? Tor limits the rate at which it accepts NEWNYMs to once every ten seconds, so if you're not finding that circuits are changing then that could be it.
Please don't cycle circuits too rapidly though. That puts strain on the network.