The wrong list was used when looking up expired intro points in a rend
service object causing what we think could be reachability issues and
triggering a BUG log.
Fixes#16702
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
exit-policy/reject-private lists the reject rules added by
ExitPolicyRejectPrivate. This makes it easier for stem to
display exit policies.
Add unit tests for getinfo exit-policy/*.
Completes ticket #17183. Patch by "teor".
Modify policies_parse_exit_policy_reject_private so it also blocks
the addresses configured for OutboundBindAddressIPv4_ and
OutboundBindAddressIPv6_, and any publicly routable port addresses
on exit relays.
Add and update unit tests for these functions.
Move the code that rejects publicly routable exit relay addresses
to policies_parse_exit_policy_reject_private. Add
addr_policy_append_reject_addr_list and use it to reject interface
addresses.
This removes the duplicate reject checks on local_address and
ipv6_local_address, but duplicates will be removed by
exit_policy_remove_redundancies at the end of the function.
This also removes the info-level logging on rejected interface
addresses. Instead, log a debug-level message in
addr_policy_append_reject_addr.
This simplifies policies_parse_exit_policy_internal and prepares for
reporting these addresses over the control port in #17183.
In my testing, an IPv6-only FreeBSD jail without ::1 returned EINVAL
from tor_ersatz_socketpair. Let's not fail the unit test because of
this - it would only ever use tor_socketpair() anyway.
(But it won't work on some systems without IPv4/IPv6 localhost
(some BSD jails) by design, to avoid creating sockets on routable
IP addresses. However, those systems likely have the AF_UNIX socketpair,
which tor prefers.)
Fixes bug #17638; bugfix on a very early tor version,
earlier than 22dba27d8d (23 Nov 2004) / svn:r2943.
Patch by "teor".
Make unit tests pass on IPv6-only systems, and systems without
localhost addresses (like some FreeBSD jails).
Fixes:
* get_if_addrs_ifaddrs: systems without localhost
* get_if_addrs_ioctl: only works on IPv4 systems
* socket: check IPv4 and IPv6, skip on EPROTONOSUPPORT
* socketpair_ersatz: uses IPv4, skip on EPROTONOSUPPORT
Fixes bug #17632; bugfix on unit tests in 0.2.7.3-rc.
c464a36772 was a partial fix for this issue in #17255;
it was released in unit tests in 0.2.7.4-rc.
Patch by "teor".
Make unit tests pass on IPv6-only systems, and systems without
localhost addresses (like some FreeBSD jails).
Fixes:
* get_if_addrs_ifaddrs: systems without localhost
* get_if_addrs_ioctl: only works on IPv4 systems
* socket: check IPv4 and IPv6, skip on EPROTONOSUPPORT
* socketpair_ersatz: uses IPv4, skip on EPROTONOSUPPORT
Fixes bug #17632; bugfix on unit tests in 0.2.7.3-rc.
c464a36772 was a partial fix for this issue in #17255;
it was released in unit tests in 0.2.7.4-rc.
Patch by "teor".
Loading a on disk bridge descriptor causes a directory download to be
scheduled, which asserts due to the periodic events not being
initialized yet.
Fixes bug #17635, not in any released version of tor.
Now we only re-scan the list in the cases we did before: when we
have a new circuit that we should try attaching to, or when we have
added a new stream that we haven't tried to attach yet.
This is part of 17590.
Long ago we used to call connection_ap_handshake_attach_circuit()
only in a few places, since connection_ap_attach_pending() attaches
all the pending connections, and does so regularly. But this turned
out to have a performance problem: it would introduce a delay to
launching or connecting a stream.
We couldn't just call connection_ap_attach_pending() every time we
make a new connection, since it walks the whole connection list. So
we started calling connection_ap_attach_pending all over, instead!
But that's kind of ugly and messes up our callgraph.
So instead, we now have connection_ap_attach_pending() use a list
only of the pending connections, so we can call it much more
frequently. We have a separate function to scan the whole
connection array to see if we missed adding anything, and log a
warning if so.
Closes ticket #17590
