If a timeout happens while reading the proxy response, this effectively
means we timed out while connecting to the remote node. This is very
common for Tor, so do not print an error message.
There are only a few uses of `insecure_random` outside the tests.
This PR replaces uses of insecure_random (and its accompanying global
state) in the core code with an FastRandomContext that is automatically
seeded on creation.
This is meant to be used for inner loops. The FastRandomContext
can be in the outer scope, or the class itself, then rand32() is used
inside the loop. Useful e.g. for pushing addresses in CNode or the fee
rounding, or randomization for coin selection.
As a context is created per purpose, thus it gets rid of
cross-thread unprotected shared usage of a single set of globals, this
should also get rid of the potential race conditions.
- I'd say TxMempool::check is not called enough to warrant using a special
fast random context, this is switched to GetRand() (open for
discussion...)
- The use of `insecure_rand` in ConnectThroughProxy has been replaced by
an atomic integer counter. The only goal here is to have a different
credentials pair for each connection to go on a different Tor circuit,
it does not need to be random nor unpredictable.
- To avoid having a FastRandomContext on every CNode, the context is
passed into PushAddress as appropriate.
There remains an insecure_random for test usage in `test_random.h`.
* The "ERROR" was printed far too often during normal operation for what was not an error.
* Makes the Socks5() connect failure similar to the IP connect failure in debug.log.
Before:
`2016-05-09 00:15:00 ERROR: Proxy error: host unreachable`
After:
`2016-05-09 00:15:00 Socks5() connect to t6xj6wilh4ytvcs7.onion:18333 failed: host unreachable"`
Rather than allowing CNetAddr/CService/CSubNet to launch DNS queries, require
that addresses are already resolved.
This greatly simplifies async resolve logic, and makes it harder to
accidentally leak DNS queries.
Starting with Tor version 0.2.7.1 it is possible, through Tor's control socket
API, to create and destroy 'ephemeral' hidden services programmatically.
https://stem.torproject.org/api/control.html#stem.control.Controller.create_ephemeral_hidden_service
This means that if Tor is running (and proper authorization is available),
bitcoin automatically creates a hidden service to listen on, without user
manual configuration. This will positively affect the number of available
.onion nodes.
- When the node is started, connect to Tor through control socket
- Send `ADD_ONION` command
- First time:
- Make it create a hidden service key
- Save the key in the data directory for later usage
- Make it redirect port 8333 to the local port 8333 (or whatever port we're listening on).
- Keep control socket connection open for as long node is running. The hidden service will
(by default) automatically go away when the connection is closed.
Nagle appears to be a significant contributor to latency now that the static
sleeps are gone. Most of our messages are relatively large compared to
IP + TCP so I do not expect this to create enormous overhead.
This may also reduce traffic burstyness somewhat.
Fix two CSubNet constructor problems:
- The use of `/x` where 8 does not divide x was broken, due to a
bit-order issue
- The use of e.g. `1.2.3.4/24` where the netmasked bits in the network
are not 0 was broken. Fix this by explicitly normalizing the netwok
according to the bitmask.
Also add tests for these cases.
Fixes#6179. Thanks to @jonasschnelli for reporting and initial fix.
According to Tor's extensions to the SOCKS protocol
(https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt)
it is possible to perform stream isolation by providing authentication
to the proxy. Each set of credentials will create a new circuit,
which makes it harder to correlate connections.
This patch adds an option, `-proxyrandomize` (on by default) that randomizes
credentials for every outgoing connection, thus creating a new circuit.
2015-03-16 15:29:59 SOCKS5 Sending proxy authentication 3842137544:3256031132
This avoids connecting to them again too soon in ThreadOpenConnections.
Make an exception for connection failures to the proxy as these
shouldn't affect the status of specific nodes.
Avoids that SOCKS5 negotiation will hold up the shutdown process.
- Sockets can stay in non-blocking mode, no need to switch it on/off
anymore
- Adds a timeout (20 seconds) on SOCK5 negotiation. This should be
enough for even Tor to get a connection to a hidden service, and
avoids blocking the opencon thread indefinitely on a hanging proxy.
Fixes#2954.
