Opened 5 months ago

Last modified 5 days ago

#29263 merge_ready enhancement

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 (12)

comment:1 Changed 3 months ago by teor

Keywords: network-team-roadmap-2019-Q1Q2 added

These chutney tickets are on the network team roadmap, or they are required for tickets that are on the network team roadmap.

comment:2 Changed 6 weeks ago by gaba

Sponsor: SponsorV → Sponsor19

comment:3 Changed 6 weeks ago by nickm

Actual Points: → 1
Owner: set to nickm
Status: new → accepted

comment:4 Changed 6 weeks ago by nickm

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 6 weeks ago by nickm

Status: accepted → needs_review

comment:6 Changed 6 weeks ago by nickm

Status: needs_review → needs_revision

Travis is complaining; I suspect there are some per-version issues to solve.

comment:7 Changed 5 weeks ago by nickm

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 5 weeks ago by nickm

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 5 weeks ago by nickm

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 7 days ago by teor

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:11 Changed 7 days ago by teor

I expect CI to fail on obsolete Tor versions due to #30826.

comment:12 Changed 5 days ago by teor

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.

Note: See TracTickets for help on using tickets.