Chutney issueshttps://gitlab.torproject.org/tpo/core/chutney/-/issues2020-07-23T20:09:29Zhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/15231Prototype implementation for the main ideas for chutney22020-07-23T20:09:29ZNick MathewsonPrototype implementation for the main ideas for chutney2We should have it running at least a small handful of network tests in a reasonable way.We should have it running at least a small handful of network tests in a reasonable way.https://gitlab.torproject.org/tpo/core/chutney/-/issues/15229Design document for chutney22020-07-23T20:09:24ZNick MathewsonDesign document for chutney2I should write up my ideas for exapanding and refactoring chutney to be more flexible and powerful.I should write up my ideas for exapanding and refactoring chutney to be more flexible and powerful.https://gitlab.torproject.org/tpo/core/chutney/-/issues/14332Use new string formatting interface2020-07-23T20:09:01ZcypherpunksUse new string formatting interfaceThe Python documentation mentions issues with printf-style string formatting and recommends the new `str.format()` interface [0]. The new interface is used in some parts but not everywhere. The attached patch fixes this by using the new ...The Python documentation mentions issues with printf-style string formatting and recommends the new `str.format()` interface [0]. The new interface is used in some parts but not everywhere. The attached patch fixes this by using the new interface where printf-style is currently used.
Additionally, it solves several bugs in `lib/chutney/TorNet.py` caused by the printf-style separator (%) being outside of the `print()`. The bugs result in Chutney crashing when `tor` or `tor-gencert` is not in `PATH` and not specified through the environment variables.
[0] https://docs.python.org/3/library/stdtypes.html#printf-style-string-formattinghttps://gitlab.torproject.org/tpo/core/chutney/-/issues/13887Pick a reporting format for Chutney2020-07-23T20:07:43ZNick MathewsonPick a reporting format for ChutneyWe need some way for Chutney to tell another process about the events it's seeing.
Options include CTF, json, protocolbufs, line-based text.
See https://lists.torproject.org/pipermail/tor-dev/2014-December/007898.html for a synopsis of...We need some way for Chutney to tell another process about the events it's seeing.
Options include CTF, json, protocolbufs, line-based text.
See https://lists.torproject.org/pipermail/tor-dev/2014-December/007898.html for a synopsis of goals.
I'm especially interested in dgoulet's opinion on CTF in particular.
I'm especially interested in atagar's opinion about what would be friendliest to a stem-based chutney.https://gitlab.torproject.org/tpo/core/chutney/-/issues/11374fix tor lockfile checking bug2020-07-23T20:06:47ZTracfix tor lockfile checking bugI previously had a misconception that lockfile got removed every time tor exits :(
This patch checks the state of lockfile properly.
branch:
https://github.com/houqp/chutney/tree/lock_fix
**Trac**:
**Username**: dave2008I previously had a misconception that lockfile got removed every time tor exits :(
This patch checks the state of lockfile properly.
branch:
https://github.com/houqp/chutney/tree/lock_fix
**Trac**:
**Username**: dave2008https://gitlab.torproject.org/tpo/core/chutney/-/issues/10156Replace DirServer with DirAuthority in torrc2020-07-23T20:05:23ZMatthew FinkelReplace DirServer with DirAuthority in torrcShould the generated torrc use DirAuthority instead of DirServer now that legacy/trac#6791 and legacy/trac#10124 are merged into Tor? It'll probably be smart to have an option to tell Chutney to use DirServer if one tests with an older v...Should the generated torrc use DirAuthority instead of DirServer now that legacy/trac#6791 and legacy/trac#10124 are merged into Tor? It'll probably be smart to have an option to tell Chutney to use DirServer if one tests with an older version.https://gitlab.torproject.org/tpo/core/chutney/-/issues/40008Add a relay-v6.tmpl template file2020-07-22T14:27:22ZDavid Gouletdgoulet@torproject.orgAdd a relay-v6.tmpl template fileFor some reasons, `relay.tmpl` includes `exit-v6.i` which now requires `ipv6_addr` to be set else `None` is put in place.
This makes `basic-min` fails because it ends up with `ORPort None:5001 IPv6Only`. Instead, make `relay.tmpl` to be...For some reasons, `relay.tmpl` includes `exit-v6.i` which now requires `ipv6_addr` to be set else `None` is put in place.
This makes `basic-min` fails because it ends up with `ORPort None:5001 IPv6Only`. Instead, make `relay.tmpl` to be IPv4 only and `relay-v6.tmpl` to be v4 _and_ v6.
This makes all network configuration using `relay.tmpl` to work normally with IPv4 only.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/chutney/-/issues/40007Our IPv6 networks must have at least 2 IPv6 relays2020-07-21T18:55:46ZDavid Gouletdgoulet@torproject.orgOur IPv6 networks must have at least 2 IPv6 relaysWithout this, the relays in our IPv6 network can NOT self-test properly because they are never able to find a second hop for the self test circuit that supports IPv6 `EXTEND`.Without this, the relays in our IPv6 network can NOT self-test properly because they are never able to find a second hop for the self test circuit that supports IPv6 `EXTEND`.David Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/chutney/-/issues/40005Chutney Bridges+hs-v23 network is failing in CI2020-07-21T13:39:10ZNick MathewsonChutney Bridges+hs-v23 network is failing in CIIn CI, and on my desktop, chutney bridges+hs-v23 is failing for clients and relays. Apparently, nothing finds that the bridge successfully bootstrapped.
See also related tickets chutney#33581, tor#33582, and tor#33407.
I have a works...In CI, and on my desktop, chutney bridges+hs-v23 is failing for clients and relays. Apparently, nothing finds that the bridge successfully bootstrapped.
See also related tickets chutney#33581, tor#33582, and tor#33407.
I have a works-for-me fix currently in github CI.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/33581Restore bridge networkstatus checks in chutney2020-07-21T13:37:22ZteorRestore bridge networkstatus checks in chutneyThis issue depends on the tor bridge descriptor upload fix in legacy/trac#33582, robust reachability self-tests in legacy/trac#33222, or bridge log checks in legacy/trac#34037.
In chutney networks, there's a race condition when bridges...This issue depends on the tor bridge descriptor upload fix in legacy/trac#33582, robust reachability self-tests in legacy/trac#33222, or bridge log checks in legacy/trac#34037.
In chutney networks, there's a race condition when bridges try to publish their descriptor to the bridge authority:
* bridges try to publish their descriptors before bootstrapping
* but bridges can't publish their descriptors, because they don't have enough directory info to build a circuit to the bridge authority
Also, bridges do not retry publishing their descriptor immediately after they bootstrap.
We can only do the networkstatus-bridges check on tor versions with the legacy/trac#33222 or legacy/trac#33582 fixes. So we'll need to check for:
* the next tor 0.4.4-alpha version, or
* an environmental variable that enables these tests.
We don't have to do these fixes, because it should be enough to test relay reachability. But we would risk breaking bridge reachability tests, and not knowing about it until after a release.
Also, the chutney workarounds seem to cause weird race conditions, which are time-consuming to diagnose and fix.https://gitlab.torproject.org/tpo/core/chutney/-/issues/14954Chutney: add control socket to torrc templates2020-07-17T11:03:24ZDavid Gouletdgoulet@torproject.orgChutney: add control socket to torrc templatesHaving a control socket is *very* useful in a test network especially when you want to test control events! :)
It should be added to the common.i file in torrc_templates/ so every node has one by default.Having a control socket is *very* useful in a test network especially when you want to test control events! :)
It should be added to the common.i file in torrc_templates/ so every node has one by default.https://gitlab.torproject.org/tpo/core/chutney/-/issues/10155Allow delayed node start2020-07-17T11:02:21ZMatthew FinkelAllow delayed node startIt will be useful to allow nodes to be started after a certain amount of time, especially when interested in its effect on the consensus.It will be useful to allow nodes to be started after a certain amount of time, especially when interested in its effect on the consensus.https://gitlab.torproject.org/tpo/core/chutney/-/issues/9086Rewrite network testing using asyncore/asynchat2020-07-17T11:01:53ZLinus Nordberglinus@torproject.orgRewrite network testing using asyncore/asynchatAs Nick points out in legacy/trac#8531, we should use asyncore or maybe even
asynchat for the network testing in Traffic.py.
This will give us more readable code and higher code quality.As Nick points out in legacy/trac#8531, we should use asyncore or maybe even
asynchat for the network testing in Traffic.py.
This will give us more readable code and higher code quality.https://gitlab.torproject.org/tpo/core/chutney/-/issues/32721Allow chutney users to disable tor's sandbox at runtime2020-07-14T22:24:30ZteorAllow chutney users to disable tor's sandbox at runtimeIn legacy/trac#32240, we discovered that tor's sandbox doesn't work on recent Ubuntu versions. So we need to disable the sandbox on those CI jobs.
One good way to implement this change, is by making it a first-class chutney feature.In legacy/trac#32240, we discovered that tor's sandbox doesn't work on recent Ubuntu versions. So we need to disable the sandbox on those CI jobs.
One good way to implement this change, is by making it a first-class chutney feature.teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/33609Check that onion services have successfully posted descriptors before verifying2020-07-07T15:12:56ZteorCheck that onion services have successfully posted descriptors before verifyingBefore verifying, chutney checks that:
* each relay descriptor is cached at each node
* each relay is in a consensus, cached at each node
* each relay is in a microdesc consensus, cached at each node
* each bridge descriptor is cached at...Before verifying, chutney checks that:
* each relay descriptor is cached at each node
* each relay is in a consensus, cached at each node
* each relay is in a microdesc consensus, cached at each node
* each bridge descriptor is cached at each bridge client
We have other tickets for checking:
* microdescriptors
* cached bridge descriptors at the bridge authority
* the bridge networkstatus
That just leaves onion services.
Onion services are tricky, because they post to some HSDirs in the network, but not all. And those HSDirs don't cache the onion service descriptors in a file.
So here is one possible design for this feature:
* check each onion service log for a successful descriptor post to at least one HSDir
* check v2 and v3 onion services
* call it an extra 200% "bootstrap" stage (because it's a sender log check, not a receiver cached file check)
* require 200% bootstrap for onion servicesNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/6413Add support for bridges and clients on IPv6 to chutney2020-06-27T13:19:08ZLinus Nordberglinus@torproject.orgAdd support for bridges and clients on IPv6 to chutneyBranch ipv6-bridges in user/linus/chutney.git contains support for
bridges on IPv6 and clients using them.Branch ipv6-bridges in user/linus/chutney.git contains support for
bridges on IPv6 and clients using them.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/6753chutney needs to set AlternateBridgeAuthority too2020-06-27T13:19:08ZRoger Dingledinechutney needs to set AlternateBridgeAuthority tooSince git commit 21c6c8485 (to Tor), Tor won't start if TestingTorNetwork is on, AlternateDirAuthority is set, but AlternateBridgeAuthority is not.Since git commit 21c6c8485 (to Tor), Tor won't start if TestingTorNetwork is on, AlternateDirAuthority is set, but AlternateBridgeAuthority is not.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/6754chutney traceback when it can't kill its tors fast enough2020-06-27T13:19:07ZRoger Dingledinechutney traceback when it can't kill its tors fast enough```
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globa...```
Traceback (most recent call last):
File "/usr/lib/python2.7/runpy.py", line 162, in _run_module_as_main
"__main__", fname, loader, pkg_name)
File "/usr/lib/python2.7/runpy.py", line 72, in _run_code
exec code in run_globals
File "/home/arma/old/torgit/chutney/lib/chutney/TorNet.py", line 663, in <module>
main()
File "/home/arma/old/torgit/chutney/lib/chutney/TorNet.py", line 660, in main
runConfigFile(sys.argv[1], f)
File "/home/arma/old/torgit/chutney/lib/chutney/TorNet.py", line 646, in runConfigFile
getattr(network,verb)()
File "/home/arma/old/torgit/chutney/lib/chutney/TorNet.py", line 619, in stop
n.check(listNonRunning=False)
AttributeError: 'int' object has no attribute 'check'
```Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/8531Extend Chutney to be able to verify that we can send and retrieve traffic2020-06-27T13:19:07ZLinus Nordberglinus@torproject.orgExtend Chutney to be able to verify that we can send and retrieve trafficThis is related to legacy/trac#8530.This is related to legacy/trac#8530.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/9087Move network tests out of TorNet.py2020-06-27T13:19:07ZLinus Nordberglinus@torproject.orgMove network tests out of TorNet.pyAs Nick points out in legacy/trac#8531, it's far from perfect that new network
tests need to go into TorNet.py.
Maybe read a config file or pick up .py files from a tests/ directory?As Nick points out in legacy/trac#8531, it's far from perfect that new network
tests need to go into TorNet.py.
Maybe read a config file or pick up .py files from a tests/ directory?