Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:29:34Zhttps://gitlab.torproject.org/legacy/trac/-/issues/17276Make at least one authority script integrated with Chutney2020-06-13T13:29:34ZNick MathewsonMake at least one authority script integrated with Chutneyhttps://gitlab.torproject.org/legacy/trac/-/issues/17080Improve coverage on src/or/main.c (run_scheduled_events)2020-06-13T14:49:11ZTracImprove coverage on src/or/main.c (run_scheduled_events)The changes are in the branch "run-scheduled-events"
https://github.com/twstrike/tor_for_patching/tree/run-scheduled-events
**Trac**:
**Username**: rjuniorThe changes are in the branch "run-scheduled-events"
https://github.com/twstrike/tor_for_patching/tree/run-scheduled-events
**Trac**:
**Username**: rjuniorhttps://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/16950Add a chutney command that checks if network bootstrap has finished2020-06-13T14:48:41ZteorAdd a chutney command that checks if network bootstrap has finishedThis command ideally needs to check (or wait before returning until) all clients are ready to send to all endpoints:
* Authorities: consensus is working
* Other Nodes have a copy of the consensus
* Hidden Services have uploaded descripto...This command ideally needs to check (or wait before returning until) all clients are ready to send to all endpoints:
* Authorities: consensus is working
* Other Nodes have a copy of the consensus
* Hidden Services have uploaded descriptors
* Anything else?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/16806Chutney/integration tests for DNS server/client functionality2020-06-13T13:29:24ZNick MathewsonChutney/integration tests for DNS server/client functionalityhttps://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/15784Clarify Chutney exit policies for IPv4 and IPv6, including private addresses2020-06-13T13:29:19ZteorClarify Chutney exit policies for IPv4 and IPv6, including private addressesAllow chutney exits to exit to all private addresses.
Tidy up exit policies, so each part of the policy is clearly identified.
Document alternatives to work around #11264, the microdescriptor 2x /8 requirement for exits.
Prepare for r...Allow chutney exits to exit to all private addresses.
Tidy up exit policies, so each part of the policy is clearly identified.
Document alternatives to work around #11264, the microdescriptor 2x /8 requirement for exits.
Prepare for resolving #15353 by making sure the exit policies *should* work when localhost is the only available IP. This still requires further investigation.
Patch:
**Branch:** clarify-exit-policies
**Repository:** https://github.com/teor2345/chutney.gitteorteorhttps://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