Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:29:44Zhttps://gitlab.torproject.org/legacy/trac/-/issues/19116Add scripts to chutney so it works on a tor binary2020-06-13T13:29:44ZteorAdd scripts to chutney so it works on a tor binaryIf chutney was self-contained and could run tests on a plain tor binary, it would be easier to do jenkins tests using chutney.
To make chutney work, we use parts of the tor git tree, including some Makefile targets to select the tests w...If chutney was self-contained and could run tests on a plain tor binary, it would be easier to do jenkins tests using chutney.
To make chutney work, we use parts of the tor git tree, including some Makefile targets to select the tests we run, and src/test/test-network.sh.
If we move these scripts to the chutney tree, we can run a set of chutney targets anywhere, without requiring a tor build tree.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/18827Allow specifying the Chutney data directory2020-06-13T13:29:42ZanonymAllow specifying the Chutney data directoryWith "Chutney data directory" I am referring to the `net` sub-directory. I find it preferable to be able to store such cruft outside of the source tree. See the attached patch.With "Chutney data directory" I am referring to the `net` sub-directory. I find it preferable to be able to store such cruft outside of the source tree. See the attached patch.anonymanonymhttps://gitlab.torproject.org/legacy/trac/-/issues/18826Allow setting the listen address for all Chutney hosts2020-06-13T13:29:42ZanonymAllow setting the listen address for all Chutney hostsIn Tails' automated test suite we have plans to use Chutney to run a simulated Tor network (for increased performance and, in particular, robustness). Of course, we do not want to run that Chutney instance in the system under testing (i....In Tails' automated test suite we have plans to use Chutney to run a simulated Tor network (for increased performance and, in particular, robustness). Of course, we do not want to run that Chutney instance in the system under testing (i.e. the Tails instance) but on the host orchestrating the tests. In order to avoid having to forward traffic via firewall rules, we'd like it to be possible to make the Chutney hosts listen on some other IP address than localhost.
The attached patch allows setting the address all Chutney hosts will listen on via the `CHUTNEY_LISTEN_ADDRESS` environment variable.anonymanonymhttps://gitlab.torproject.org/legacy/trac/-/issues/17282Chutney could use a HOWTO for writing new test cases, network tests, etc2020-06-13T13:29:35ZNick MathewsonChutney could use a HOWTO for writing new test cases, network tests, etcDue April 2016Due April 2016https://gitlab.torproject.org/legacy/trac/-/issues/17002chutney start could tell users how to kill old chutney tors2020-06-13T13:29:30Zteorchutney start could tell users how to kill old chutney torsThe most common reason chutney start fails to start all tor processes is port conflicts caused by old chutney tor processes still running.
We could tell users how to kill processes (should we?) using a summary of the following informati...The most common reason chutney start fails to start all tor processes is port conflicts caused by old chutney tor processes still running.
We could tell users how to kill processes (should we?) using a summary of the following information from https://trac.torproject.org/projects/tor/wiki/doc/TorChutneyGuide
"However, sometimes chutney fails to launch due to a persistent error. The most common issue is having a previous chutney network active. Old chutney networks are typically killed by chutney/tools/bootstrap-network.sh using chutney stop, but sometimes this doesn't happen. The tor processes launched by chutney can be found using a command like `ps auxwww | grep chutney | grep tor`. Ensure each pid doesn't belong to a process you want, like a system tor or an unrelated process, then kill each chutney tor pid using `kill`. Alternately, each tor instance's pid files can be found in the chutney/net/nodes directory. (Old nodes directories are renamed using an increasing numeric timestamp as a suffix.)"
Use:
* chutney stop
* `ps auxwww | grep chutney | grep tor` and carefull check each pid before using `kill` on it
* the tor pid files in the chutney/net/nodes* directories (maybe, these can be very old)https://gitlab.torproject.org/legacy/trac/-/issues/16949Make Chutney Easier to Use & More Functional, Write Guide2020-06-13T13:29:27ZteorMake Chutney Easier to Use & More Functional, Write GuideI (teor) am writing a guide to using chuntney.
As part of that, I'm making chuntey easier to use, mainly through a series of tweaks that simplify usage and improve test coverage.
See https://trac.torproject.org/projects/tor/wiki/doc/Tor...I (teor) am writing a guide to using chuntney.
As part of that, I'm making chuntey easier to use, mainly through a series of tweaks that simplify usage and improve test coverage.
See https://trac.torproject.org/projects/tor/wiki/doc/TorChutneyGuide and the child tickets for more details.https://gitlab.torproject.org/legacy/trac/-/issues/16454chutney's "tor does not support this option" is unclear2020-06-13T13:29:23Zteorchutney's "tor does not support this option" is unclearA user emailed me concerned that chutney was giving a lot of "tor does not support this option" errors.
These messages could be much clearer:
* The message is a warning, not an error
* The message doesn't describe the likely consequence...A user emailed me concerned that chutney was giving a lot of "tor does not support this option" errors.
These messages could be much clearer:
* The message is a warning, not an error
* The message doesn't describe the likely consequences. We could document these, at least for the 3 `TestingDirAuthVote*` options
I also wrote back to them:
```
This is a warning that happens when you have an older version of tor. It is telling you that your version of tor doesn't support one of the options used in the standard chutney torrc templates. Chutney warns you, but disables the option so that tor will still run.
This particular option is used to speed up the authorities' votes for hidden service directories. If you are running a chutney network with a hidden service, you can speed up bootstrap by using tor 0.2.6.9 or tor 0.2.7-alpha.
If you're not using hidden services, you can disregard this warning.
Thank you for letting me know, I will log a task to update the documentation to make it clearer that this is a warning, and explain the likely consequence.
```https://gitlab.torproject.org/legacy/trac/-/issues/15783On chutney verify failure, inform user about debug mode2020-06-13T13:29:18ZteorOn chutney verify failure, inform user about debug modeWhen chutney verify fails, tell the user how to activate debug mode by editing the source code.
Eventually, we'll make debug mode an argument, see #15418.When chutney verify fails, tell the user how to activate debug mode by editing the source code.
Eventually, we'll make debug mode an argument, see #15418.teorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/15419chutney: on failure, explain which connection failed2020-06-13T13:29:17Zteorchutney: on failure, explain which connection failedWhen there's a failure in the chutney data transmission tests, it would be really, really helpful to know which connection failed. The debug flag doesn't quite do this yet, but it's pretty close.
This is particularly important now that ...When there's a failure in the chutney data transmission tests, it would be really, really helpful to know which connection failed. The debug flag doesn't quite do this yet, but it's pretty close.
This is particularly important now that chutney supports three different types of connectivity tests (in the same network):
* client -> exit
* bridge client -> exit
* [bridge] client -> hidden service
Over two different protocols:
* IPv4
* IPv6 (currently bridges only)https://gitlab.torproject.org/legacy/trac/-/issues/15418chutney: add debug command-line flag2020-06-13T13:29:17Zteorchutney: add debug command-line flagchutney has a debug variable `debug_flag` in `Traffic.py`.
This would be much easier to use if it was set from the command-line, or even automatically activated (at some level) on transmission failure.chutney has a debug variable `debug_flag` in `Traffic.py`.
This would be much easier to use if it was set from the command-line, or even automatically activated (at some level) on transmission failure.Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/15353Some chutney tests fail when localhost is the only available IP2020-06-13T13:29:16ZteorSome chutney tests fail when localhost is the only available IPWhen I turn off the Wifi / Internet connection on my Mac (OS X 10.10.2), the chutney Exit tests fail with 'no exit to that port', but the hidden service tests are fine.
This is probably a misconfiguration around the localhost exit ports...When I turn off the Wifi / Internet connection on my Mac (OS X 10.10.2), the chutney Exit tests fail with 'no exit to that port', but the hidden service tests are fine.
This is probably a misconfiguration around the localhost exit ports (all ports should be allowed, or, at the very least, the ports chutney uses should be allowed).
I'll see if I can find time to track this down and fix it, but it's low priority, as most people run chutney on a computer with an IP address apart from localhost.Nick MathewsonNick Mathewson