Previously the FooPort was ignored and the default used instead,
causing Tor to bind to the wrong port if FooPort and the default
port don't match or the CONN_TYPE_FOO_LISTENER has no default port.
Fixes#3936.
Right now we only force a new descriptor upload every 18 hours.
This can make servers become unlisted if they upload a descriptor at
time T which the authorities reject as being "too similar" to one
they uploaded before. Nothing will actually make the server upload a
new descriptor later on, until another 18 hours have passed.
This patch changes the upload behavior so that the 18 hour interval
applies only when we're listed in a live consensus with a descriptor
published within the last 18 hours. Otherwise--if we're not listed
in the live consensus, or if we're listed with a publication time
over 18 hours in the past--we upload a new descriptor every 90
minutes.
This is an attempted bugfix for #3327. If we merge it, it should
obsolete #535.
Conflicts:
src/or/connection.c
src/or/connection_edge.c
src/or/connection_edge.h
src/or/dnsserv.c
Some of these were a little tricky, since they touched code that
changed because of the prop171 fixes.
For some reason, autoconf doesn't by default have an "AC_PROG_AR" for
this -- possibly it's assumed that any "ar" you have will work
everyplace.
Fixes bug 3909; found by sid77.
This fixes a build issue first present in fdbdb4dc15, but the bug
(of not using a correct ar) has been in every Tor version ever: it
just didn't matter until then.
On some platforms, with non-blocking IO, on EOF you first
get EAGAIN, and then on the second read you get zero bytes
and EOF is set. However on others, the EOF flag is set as
soon as the last byte is read. This patch fixes the test
case in the latter scenario.
After a stream reached eof, we fclose it, but then
test_util_spawn_background_partial_read() reads from it again, which causes
an error and thus another fclose(). Some platforms are fine with this, others
(e.g. debian-sid-i386) trigger a double-free() error. The actual code used by
Tor (log_from_pipe() and tor_check_port_forwarding()) handle this case
correctly.
