Opened 9 years ago

Closed 9 years ago

Last modified 6 years ago

#1834 closed defect (fixed)

Backport client handling for END_STREAM_REASON_NOROUTE

Reported by: nickm Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

0.2.1.x Tor clients should handle the new reason 8: NOROUTE correctly by retrying it. See the commits merged in Sebastian's misc-reason branch, plus Roger's 4c948ffd6.

This is worth backporting because these errors happen not infrequently, and if the exit has a bad network configuration, clients really should retry the stream.

Child Tickets

Change History (7)

comment:1 Changed 9 years ago by arma

On further thought, it seems that returning a REASON_NOROUTE will cause all clients that haven't upgraded to fail to retry the stream, whereas if it's MISC they will retry.

Does that argue for teaching clients to retry NOROUTE ends, both in maint-0.2.1 and in master, and then only later (say, when 0.2.1.27 is well established) starting to actually send them?

comment:2 Changed 9 years ago by nickm

That actually seems pretty sensible, though it means we need to #if out the code in master that sends REASON_NOROUTE before we put out a new alpha.

comment:3 Changed 9 years ago by nickm

Status: newneeds_review

Okay; hacked it up. So my plan would be to merge the "no_NOROUTE_yet" branch into master, and merge "backport_noroute" into maint-0.2.1. Please review?

comment:4 Changed 9 years ago by Sebastian

Both branches look good to me.

comment:5 Changed 9 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merged. Actually, merging backport_noroute into maint-0.2.1 and then into master obviated the need to merge no_NOROUTE_yet into master.

comment:6 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:7 Changed 6 years ago by nickm

Milestone: Tor: 0.2.1.x-final

Milestone Tor: 0.2.1.x-final deleted

Note: See TracTickets for help on using tickets.