This reverts commit caf6150e97.
getaddrinfo_a has a nasty tendency to segfault internally in its
background thread, on every version of glibc I tested, especially
under helgrind.
See https://sourceware.org/bugzilla/show_bug.cgi?id=20874
Github-Pull: #9229
Rebased-From: 10ae7a7b2316f8052ec58ef237ce6dd987300900
* 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.
This reverts commit caf6150e97.
getaddrinfo_a has a nasty tendency to segfault internally in its
background thread, on every version of glibc I tested, especially
under helgrind.
See https://sourceware.org/bugzilla/show_bug.cgi?id=20874
Github-Pull: #9229
Rebased-From: 10ae7a7b2316f8052ec58ef237ce6dd987300900
* 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.
