Chutney issueshttps://gitlab.torproject.org/tpo/core/chutney/-/issues2020-06-27T13:18:32Zhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/33595Stop waiting for unchecked directory info2020-06-27T13:18:32ZteorStop waiting for unchecked directory infoOnce we've fixed legacy/trac#33428 (microdescs), legacy/trac#33582 (bridges), and legacy/trac#33609 (onion services), we might be able to remove WAIT_FOR_UNCHECKED_DIR_INFO in chutney's TorNet.py.
But we might still need to wait for:
* ...Once we've fixed legacy/trac#33428 (microdescs), legacy/trac#33582 (bridges), and legacy/trac#33609 (onion services), we might be able to remove WAIT_FOR_UNCHECKED_DIR_INFO in chutney's TorNet.py.
But we might still need to wait for:
* internal tor state changes, in response to downloading descriptors.
So we will need to make this change, then test it on Tor 0.3.5 and master.https://gitlab.torproject.org/tpo/core/chutney/-/issues/33676Stop waiting a set time for microdescriptors2020-06-27T13:18:31ZteorStop waiting a set time for microdescriptorsYour code in legacy/trac#33675 needs to pass your local "make test-network-all", on master and maint-0.3.5, before you start this ticket.
When we make chutney check for microdescriptors, we can stop waiting a set time for microdescripto...Your code in legacy/trac#33675 needs to pass your local "make test-network-all", on master and maint-0.3.5, before you start this ticket.
When we make chutney check for microdescriptors, we can stop waiting a set time for microdescriptors to download.
Please read these instructions carefully. Don't leave out any steps!
First, set MIN_START_TIME_LEGACY and NODE_WAIT_FOR_UNCHECKED_DIR_INFO to 0:
https://github.com/torproject/chutney/blob/master/lib/chutney/TorNet.py#L926
https://github.com/torproject/chutney/blob/master/lib/chutney/TorNet.py#L952
Then check that `make test-network-all` still passes on:
* Tor master, and
* Tor maint-0.3.5
You can build a different tor branch using the following commands:
```
git checkout <branch>
make
```
Check the new code on your own machine, and then submit a pull request to run Chutney's CI.
If all those tests pass, you can remove all the code that uses MIN_START_TIME_LEGACY and NODE_WAIT_FOR_UNCHECKED_DIR_INFO:
* remove NODE_WAIT_FOR_UNCHECKED_DIR_INFO
* replace NODE_WAIT_FOR_UNCHECKED_DIR_INFO with 0 in getUncheckedDirInfoWaitTime()
* remove getMinStartTime()
* remove all the constants getMinStartTime() uses
* remove all calls to getMinStartTime()
* remove all the variables, code, and comments that depend on getMinStartTime()
* https://github.com/torproject/chutney/blob/master/lib/chutney/TorNet.py#L2224
* https://github.com/torproject/chutney/blob/master/lib/chutney/TorNet.py#L2273
Then add a commit to your pull request with these changes, and check that they pass CI.
You can ignore macOS hangs ("red ! symbol") on Travis CI. It is a bit unstable right now.https://gitlab.torproject.org/tpo/core/chutney/-/issues/27230Stop setting PathsNeededToBuildCircuits to a low value2020-06-27T13:18:45ZteorStop setting PathsNeededToBuildCircuits to a low valueIt caused legacy/trac#27080, and it's not a good idea to depart from the Tor defaults.
When we make this change, we need to run "make test-network-all" on all supported tor versions.It caused legacy/trac#27080, and it's not a good idea to depart from the Tor defaults.
When we make this change, we need to run "make test-network-all" on all supported tor versions.teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/23976Stop setting CircuitIdleTimeout in chutney, it's obsolete2020-06-27T13:18:47ZteorStop setting CircuitIdleTimeout in chutney, it's obsoletehttps://gitlab.torproject.org/tpo/core/chutney/-/issues/33583Stop setting AssumeReachable on chutney relays and bridges2020-07-23T20:36:05ZteorStop setting AssumeReachable on chutney relays and bridgesWe need to stop setting AssumeReachable on relays and bridges in chutney networks, so they do reachability self-tests.
We should continue to set AssumeReachable on authorities (including the bridge authority), because it disables author...We need to stop setting AssumeReachable on relays and bridges in chutney networks, so they do reachability self-tests.
We should continue to set AssumeReachable on authorities (including the bridge authority), because it disables authority to relay reachability tests. (These tests are still performed on a half-hourly schedule, even in chutney networks. And they are out of scope for Sponsor 55.)
After we implement this change, we should also be able to implement legacy/trac#33581.Sponsor 55: Improving the Tor network’s IPv6 supportteorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/29760Stop repeating chutney's defaults in comments2020-06-27T13:18:41ZteorStop repeating chutney's defaults in commentsWhen we repeat the defaults in comments and code, the comments get out of date,
Example:
```
# chutney starts verifying after START seconds, keeps on trying for BOOTSTRAP seconds,
# and then stops after STOP seconds (see the defaults be...When we repeat the defaults in comments and code, the comments get out of date,
Example:
```
# chutney starts verifying after START seconds, keeps on trying for BOOTSTRAP seconds,
# and then stops after STOP seconds (see the defaults below)
```
https://github.com/teor2345/chutney/pull/2/files#r264898496teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/23497Stop assuming that test module attribute errors are about run_test2020-06-27T13:18:48ZteorStop assuming that test module attribute errors are about run_testhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/33353Split chutney's diagnostics into a new script2020-06-27T13:18:33ZteorSplit chutney's diagnostics into a new scriptChutney's failure diagnostics are currently in the Travis CI config file.
But we want to use them in tor's CI. And maybe chutney users want to use them as well.Chutney's failure diagnostics are currently in the Travis CI config file.
But we want to use them in tor's CI. And maybe chutney users want to use them as well.Sponsor 55: Improving the Tor network’s IPv6 supportteorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/15353Some chutney tests fail when localhost is the only available IP2020-06-27T13:19:03ZteorSome 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 Mathewsonhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/27303Silence duplicate vote warning in chutney2020-06-27T13:18:45ZteorSilence duplicate vote warning in chutneyIf the duplicate vote warning becomes annoying, we should silence it in chutney.If the duplicate vote warning becomes annoying, we should silence it in chutney.https://gitlab.torproject.org/tpo/core/chutney/-/issues/30820Show the correct macOS tor versions in chutney's CI2020-06-27T13:18:37ZteorShow the correct macOS tor versions in chutney's CII left out some environmental variables in legacy/trac#29729.I left out some environmental variables in legacy/trac#29729.teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/22134Several bugs encountered running "make test-network" on a fast desktop2020-06-27T13:18:50ZNick MathewsonSeveral bugs encountered running "make test-network" on a fast desktopPlease see branch `misc_bugs` for fixes. Sorry for brevity of this ticket.
These fixes take my "make test-network" success rate from 0% to about 60%.Please see branch `misc_bugs` for fixes. Sorry for brevity of this ticket.
These fixes take my "make test-network" success rate from 0% to about 60%.teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/25265Set consensus parameter CircuitPriorityHalflife to enable the EWMA circuit po...2020-06-27T13:18:46ZDavid Gouletdgoulet@torproject.orgSet consensus parameter CircuitPriorityHalflife to enable the EWMA circuit policySo turns out that Chutney is not using EWMA policy at all for circuit priority which means that its been using the default policy which is round robin.
I found this by working on a patch that for testing was assert()ing on the `cmux->po...So turns out that Chutney is not using EWMA policy at all for circuit priority which means that its been using the default policy which is round robin.
I found this by working on a patch that for testing was assert()ing on the `cmux->policy` and it exploded.
See `cell_ewma_set_scale_factor()` on how the EWMA policy is enabled/disabled.
The real network sets: `CircuitPriorityHalflifeMsec 30000`https://gitlab.torproject.org/tpo/core/chutney/-/issues/33675Search microdescriptor files for relay ed25519 keys2020-06-27T13:18:31ZteorSearch microdescriptor files for relay ed25519 keysYour code in legacy/trac#33428 needs to pass your local "make test-network-all", before you start this ticket.
We need to enable searching for ed25519 keys in relay microdescriptor files.
There are instructions and a draft search patte...Your code in legacy/trac#33428 needs to pass your local "make test-network-all", before you start this ticket.
We need to enable searching for ed25519 keys in relay microdescriptor files.
There are instructions and a draft search pattern here:
https://github.com/torproject/chutney/blob/master/lib/chutney/TorNet.py#L1325
Please open a new pull request for this ticket. Your branch should be based on the final version of legacy/trac#33428.
Before you push new changes to your pull request, your chutney code should pass:
* "make test-network-all" on tor master
* "make test-network-all" on tor maint-0.3.5
You can build a tor branch using these commands:
```
cd tor
git checkout -b <branch>
make
```
Where <branch> is master or maint-0.3.5https://gitlab.torproject.org/tpo/core/chutney/-/issues/33302Run bridges+hs-v23 as Chutney's default network2020-06-27T13:18:33ZteorRun bridges+hs-v23 as Chutney's default networkNow that 0.2.9 is obsolete, we can upgrade chutney's defaults.
Users who want to run unsupported tor versions < 0.3.2 can choose a legacy flavour, like `basic-min` or `bridges+hs-v2`.Now that 0.2.9 is obsolete, we can upgrade chutney's defaults.
Users who want to run unsupported tor versions < 0.3.2 can choose a legacy flavour, like `basic-min` or `bridges+hs-v2`.Sponsor 55: Improving the Tor network’s IPv6 supportteorteorhttps://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/20607Revise chutney download schedules for exponential backoff2020-06-27T13:18:54ZteorRevise chutney download schedules for exponential backoffCurrently, chutney hard-codes most download schedules to "0, 5".
This should be revised, probably after legacy/trac#20606 is implemented.
Split off legacy/trac#20597.Currently, chutney hard-codes most download schedules to "0, 5".
This should be revised, probably after legacy/trac#20606 is implemented.
Split off legacy/trac#20597.https://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/33378Require chutney node bootstrap before running verify2020-06-27T13:18:33ZteorRequire chutney node bootstrap before running verifyAs part of testing relay reachability self-tests in legacy/trac#33232, we need to make sure that all chutney nodes bootstrap.As part of testing relay reachability self-tests in legacy/trac#33232, we need to make sure that all chutney nodes bootstrap.teorteorhttps://gitlab.torproject.org/tpo/core/chutney/-/issues/21461Require authentication on all tor control ports2020-06-27T13:18:53ZteorRequire authentication on all tor control portsIn legacy/trac#19765, I accidentally made control port authentication only on for clients.In legacy/trac#19765, I accidentally made control port authentication only on for clients.teorteor