| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
Encapsulate the logic of finding and validating each option into their
own objects (e.g. so that specification of corresponding command-line
option goes together with other related logic).
|
| |
|
|
|
|
| |
This wasn't a pre-existing environment variable, and now it can be set
via command-line if it needs to be overridden. I don't see much reason
to use an environment variable here.
|
| | |
|
| | |
|
| |
|
|
|
| |
We avoid much refactoring at this step to minimize functional changes
from the shell script.
|
| | |
|
| |
|
|
|
|
| |
This makes the `setup` script a bit more clearly single-purpose of
resolving and storing the configuration, without actually acting on it
yet.
|
| |
|
|
|
|
|
|
|
| |
It made sense to have this as part of the setup when the chutney network
itself didn't include arti; i.e. this used to be just validating the
non-chutney tor network before adding chutney nodes.
Now that the chutney network natively includes arti nodes, `chutney
verify` is testing those nodes; i.e., testing arti.
|
| | |
|
| |
|
|
|
|
|
|
| |
This partially reverts b223d504f6a033600c61e81a0b0a0eea3e43fd44 from
arti!3047. Increasing the transfer size exacerbates the failure rate of
the onion services too much.
We should increase it again once arti#2109 is resolved.
|
| |
|
|
|
| |
With the increased transfer sizes and simulation run-time,
the previous log levels resulted in excessively large log files.
|
| |
|
|
|
|
|
|
| |
This is the transfer size used in the tor CI chutney tests, to
more-fully exercise SENDMEs / congestion control.
We also increase the simulation run time to allow time for the larger
transfers.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
In particular, this is to avoid floods of:
> compute_drain_rate(): Bug: Computing stream drain rate with zero time delta
in tor logs.
|
| |
|
|
|
|
| |
arti isn't trying to use conflux yet, but the tor nodes are. Things
were stumbling along without this, but adding it reduces some log noise,
and might help with consistency.
|
| |
|
|
|
|
| |
This reduces some noise and warnings, and may help with consistency.
e.g. this avoids everything trying to repeatedly contact the directory
authorities before they're up.
|
| |
|
|
|
|
|
|
|
| |
In this commit there should be little effective difference, other than
combining the "setup", "configure", and "wait_for_bootstrap" steps.
"chutney bootstrap" also support multi-phase networks, though, in which
chutney waits for some nodes to fully bootstrap before bringing up other
nodes.
|
| |
|
|
|
|
|
|
|
|
|
| |
This is the time we wait for the network to bootstrap before giving up.
With the larger network we seem to need this extra time.
We've already increased the default in chutney to 300; no reason to use
a smaller value here.
Keep the explicit-setting for now as a convenience in case we want to
modify it again.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation to switch arti's console logging to use stderr
instead of stdout. The test script currently fails the test if there are
non-empty stderr files, since that's where rust panics end up getting
recorded.
It will also make it easier to see if there is any other non-logging
output.
Also disable trace-level logging for the tor_proto module. It's unclear
exactly when/why this was added, but it's probably overkill other than
when debugging.
|
| | |
|
| |
|
|
| |
Authorities also function as exit relays; we don't need to add so many.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
An arti proxy is already started as part of the chutney network.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is needed to support chutney networks containing arti nodes.
|
| |
|
|
|
| |
Use the new exported json metadata to get a tor client port instead of
hard-coding it.
|
| |
|
|
|
| |
Also update the hard-coded tor client port here to match updates
to the chutney network.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
shadow CI tweaks
See merge request tpo/core/arti!2989
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Not expected to solve any immediate issue, but helpful for consistency
with the chutney-shadow CI, and I think in the past we've hit busy-loop
deadlock without it if/when we try increasing the simulation end time.
Similarly, we apply the same tuning of "max_unapplied_cpu_latency" as we
use in the chutney-shadow simulation, which gets back some of the
simulation stability that enabling model-unblocked-syscall-latency
otherwise sometimes sacrifices.
|
| | |
| |
| |
| |
| | |
While useful, it significantly slows down the test. We should probably
just enable it when needed.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As per previous discussion there is some known flakiness around hidden
services with TestingTorNetwork enabled:
<https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1399#note_2921505>
Previously, only requiring 5 of 10 transfers to succeed has been enough
to keep this stable, but recently we've gotten unlucky and dipped under
this threshold: <https://gitlab.torproject.org/tpo/core/arti/-/issues/1986>
More investigation is warranted, especially wrt why the problem seems
to mostly be affecting articlient-onion-auth, but for now it's better to
have a low success threshold than to have folks overriding the CI
failure.
|
| |
|
|
|
|
| |
Since this significantly affects the behavior of the simulation, it's
probably worth having it in the yaml. (It can of course still be
overridden from the command-line).
|
| |
|
|
|
|
| |
Since this significantly affects the behavior of the simulation, it's
useful to have it in the yaml for reference or if the simulation is
manually rerun from the yaml.
|
| |
|
|
|
|
|
|
| |
This should make the simulation results generally more stable with
respect to small perturbations, such as adding logging.
It also causes a previous "heisenbug" failure in this test to reliably
reproduce in every run.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
The pcaps are only used to check for leaks by reading the packet
source/destination, so we don't need the entire packet. This should make
CI artifacts a bit smaller.
The fixed-size portion of an IP header is 20 bytes for IPv4 and 40 bytes
for IPv6. Shadow doesn't support IPv6, but used the IPv6 header size
anyways.
|
| |
|
|
| |
ntor v3 is now always enabled.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Previously shadow would report a platform of "shadowsys" in the uname
syscall, which would cause chutney to disable sandboxing by default.
As of https://github.com/shadow/shadow/pull/3442, shadow now returns
"Linux", which causes the chutney default to enable sandboxing.
When sandboxing is enabled, the tor processes abort with error, since
shadow doesn't support the seccomp syscall.
|
| | |
|