Opened 10 months ago
Closed 6 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 9 months ago by
Keywords: | network-team-roadmap-2019-Q1Q2 added |
---|
comment:2 Changed 7 months ago by
Sponsor: | SponsorV → Sponsor19 |
---|
comment:3 Changed 7 months ago by
Actual Points: | → 1 |
---|---|
Owner: | set to nickm |
Status: | new → accepted |
comment:4 Changed 7 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 7 months ago by
Status: | accepted → needs_review |
---|
comment:6 Changed 7 months ago by
Status: | needs_review → needs_revision |
---|
Travis is complaining; I suspect there are some per-version issues to solve.
comment:7 Changed 7 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 7 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 7 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 6 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 6 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 6 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.