Opened 16 months ago
Closed 12 months ago
#29263 closed enhancement (fixed)
prop289: add bidirectional data transfers to chutney
| Reported by: | teor | Owned by: | nickm |
|---|---|---|---|
| Priority: | Medium | Milestone: | |
| Component: | Core Tor/Chutney | Version: | |
| Severity: | Normal | Keywords: | prop289, network-team-roadmap-2019-Q1Q2 |
| Cc: | dgoulet, teor | Actual Points: | 2 |
| Parent ID: | Points: | 5 | |
| Reviewer: | Sponsor: | Sponsor19 |
Description
To test authenticated sendmes, we need to send data in both directions.
Child Tickets
Change History (13)
comment:1 Changed 15 months ago by
| Keywords: | network-team-roadmap-2019-Q1Q2 added |
|---|
comment:2 Changed 13 months ago by
| Sponsor: | SponsorV → Sponsor19 |
|---|
comment:3 Changed 13 months ago by
| Actual Points: | → 1 |
|---|---|
| Owner: | set to nickm |
| Status: | new → accepted |
comment:4 Changed 13 months ago by
See branch bidi with PR at https://github.com/torproject/chutney/pull/28
This was much easier than I'd expected, once I refactored Traffic.py to be a little more ergonomic.
comment:5 Changed 13 months ago by
| Status: | accepted → needs_review |
|---|
comment:6 Changed 13 months ago by
| Status: | needs_review → needs_revision |
|---|
Travis is complaining; I suspect there are some per-version issues to solve.
comment:7 Changed 13 months ago by
| Actual Points: | 1 → 2 |
|---|
I've updated the branch, and the travis failure rate is lower, but still real. I don't know why; I've spent about a day searching for the problem in various ways.
For some reason, the issue seems to be that one of the Tor clients is sent a socks request, and never replies. I don't know why that would happen. It does not seem to happen with 0.4.0 or later quite so often as it does with 0.3.5.
I'm going to take a break from this and hope that Teor or I will have a big insight.
comment:8 Changed 13 months ago by
Hm. I didn't see this before, but it shows up in my logs on the exit node:
May 13 09:45:20.498 [info] connection_handle_write_impl(): in-progress connect failed. Removing. (Connection refused) May 13 09:45:20.498 [info] errno_to_stream_end_reason(): Didn't recognize errno 0 (Success); telling the client that we are ending a stream for 'misc' reason. May 13 09:45:20.498 [info] connection_handle_write_impl(): in-progress connect failed. Removing. (Connection refused) May 13 09:45:20.498 [info] errno_to_stream_end_reason(): Didn't recognize errno 0 (Success); telling the client that we are ending a stream for 'misc' reason.
comment:9 Changed 13 months ago by
If I am diagnosing this right, it might be because of our evdns code on 0.3.5.x and earlier not having a fix for #21900. I have NO IDEA why this is not affecting chutney without this patch though.
comment:10 Changed 12 months ago by
About a month ago, chutney CI was unstable. This failure pattern looks familiar: older releases and newer pythons.
Since then, I've fixed a bunch of bugs, and merged to master.
I closed and re-opened the pull request to get the latest merge, let's see how it goes.
comment:12 Changed 12 months ago by
| Status: | needs_revision → merge_ready |
|---|
Seems to work fine now, except for 0.3.4, which is an expected fail.
Let's re-run CI after the #30876 merge, and then merge this PR?
We'll need to close and re-open the pull request so GitHub re-does the merge to master.
comment:13 Changed 12 months ago by
| Resolution: | → fixed |
|---|---|
| Status: | merge_ready → closed |
Merged to master as 49dceb9.
These chutney tickets are on the network team roadmap, or they are required for tickets that are on the network team roadmap.