This is done to avoid spurious warns. Additional log lines are also
added to try to track down the codepaths where we are somehow overcounting
success counts.
Thanks to the changes we started making with SocksPort and friends
in 0.2.3.3-alpha, any of our code that did "if (options->Sockport)"
became wrong, since "SocksPort 0" would make that test true whereas
using the default SocksPort value would make it false. (We didn't
actually do "if (options->SockPort)" but we did have tests for
TransPort. When we moved DirPort, ORPort, and ControlPort over to
the same system in 0.2.3.9-alpha, the problem got worse, since our
code is littered with checks for DirPort and ORPort as booleans.
This code renames the current linelist-based FooPort options to
FooPort_lines, and adds new FooPort_set options which get set at
parse-and-validate time on the or_options_t. FooPort_set is true
iff we will actually try to open a listener of the given type. (I
renamed the FooPort options rather than leave them alone so that
every previous user of a FooPort would need to get inspected, and so
that any new code that forgetfully uses FooPort will need fail to
compile.)
Fix for bug 6507.
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
The SMARTLIST_FOREACH macro is more convenient than BEGIN/END when
you have a nice short loop body, but using it for long bodies makes
your preprocessor tell the compiler that all the code is on the same
line. That causes grief, since compiler warnings and debugger lines
will all refer to that one line.
So, here's a new style rule: SMARTLIST_FOREACH blocks need to be
short.
This could result in bizarre window values. Report and patch
contributed pseudymously. Fixes part of bug 6271. This bug was
introduced before the first Tor release, in svn commit r152.
(bug 6271, part a.)
This reverts commit c32ec9c425.
It turns out the two sides of the circuit don't actually stay in sync,
so it is perfectly normal for the circuit window on the exit relay to
grow to 2000+. We should fix that bug and then reconsider this patch.
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
The functions parse_{s,c}method_line() were using
tor_addr_port_lookup() which is capable of doing DNS lookups. DNS
lookups should not be necessary when parsing {C,S}METHOD lines.
We now catch bare {s that should be on the previous line with a do,
while, if, or for, and elses that should share a line with their
preceding }.
That is,
if (foo)
{
and
if (foo) {
...
}
else
are now detected.
We should think about maybe making Tor uncrustify-clean some day,
but configuring uncrustify is an exercise in bizarreness, and
reformatting huge gobs of Tor is always painful.
The code that detected the source of a remapped address checked that
an address mapping's source was a given rewrite rule if addr_orig had
no .exit, and addr did have a .exit after processing that rule. But
addr_orig was formatted for logging: it was not the original address
at all, but rather was the address escaped for logging and possibly
replaced with "[scrubbed]".
This new logic will correctly set ADDRMAPSRC_NONE in the case when the
address starts life as a .exit address, so that AllowDotExit can work
again.
Fixes bug 6211; bugfix on 0.2.3.17-beta
It turns out this can happen. Even though there is no reason for
connections to be marked but reading, we leave them reading anyway,
so warning here is unwarranted. Let's turn that back on once we do
something sensible and disable reading when we mark. Bugfix for
6203 on Tor 0.2.3.17-beta.
Thanks to cypherpunks for pointing out the general stupidity of the
original code here.
