Verify path bias code plays well with optimistic data

In connection_ap_handshake_socks_reply() and some other places, we mark circuits as having successfully carried streams if we get certain end reason codes back. With optimistic data enabled, we may actually get these same end reason codes back even if the circuit/stream was damaged due to tagging after accepting an optimistic data stream attempt.

I probably need to instrument a tor client running with optimistic data to verify these codepaths can't happen.

changed milestone to %Tor: 0.2.5.x-final

added 024-backport MikePerry201308 component::core tor/tor milestone::Tor: 0.2.5.x-final owner::mikeperry parent::3890 points::2 priority::medium resolution::fixed status::closed tor-client type::task labels

Trac:
Milestone: N/A to Tor: 0.2.4.x-final

Trac:
Status: new to assigned

Until some apps actually support optimistic data (see sibling tickets), there is no way for me to test this. Yes, I realize that I am the maintainer one of the apps that are guilty of lack of support, but that still doesn't mean that support has to be implemented by the 0.2.4.x-stable deadline.

Trac:
Keywords: tor-client deleted, tor-client 024-deferrable added

Drop iang a line? I know he's got at least some testing app that he & his students used when they implemented optimistic data..

(This should probably get done in 0.2.4, since optimistic data support went into 0.2.3, and breaking it in 0.2.4 would count as a regression.)

Trac:
webfetch-4b-timing.diff

The simplest test program I have is webfetch 5.4.3 (http://tony.aiu.to/sa/webfetch/) with the attached patch to enable reporting of timing and "SOCKS 4b" (like SOCKS 4a, but allow the client to send data before hearing the response to the connection attempt).

Trac:
Cc: N/A to iang

Thanks Ian.

Trac:
Keywords: tor-client 024-deferrable deleted, tor-client 024-deferrable MikePerry201304 added

Trac:
Keywords: tor-client 024-deferrable MikePerry201304 deleted, tor-client 024-deferrable MikePerry201305 added

Can't block 0.2.4 on this any longer. If we find any bugs, we can backport the fixes, if the fixes are easy.

Trac:
Keywords: tor-client 024-deferrable MikePerry201305 deleted, tor-client 024-backport added
Milestone: Tor: 0.2.4.x-final to Tor: 0.2.5.x-final

whoops; removed Mike's magic tag.

Trac:
Keywords: tor-client 024-backport deleted, tor-client 024-backport MikePerry201305 added

Trac:
Keywords: tor-client 024-backport MikePerry201305 deleted, tor-client 024-backport MikePerry201307 added

It probably works? Seems to be fine so far. I think I might just let inertia take care of this one. Pushing this out to September.

Trac:
Keywords: tor-client 024-backport MikePerry201307 deleted, tor-client 024-backport MikePerry201309 added

I've gotten notices about low stream success counts while using optimistic data on bad connections. Calling this one closed.

Trac:
Resolution: N/A to fixed
Points: N/A to 2
Keywords: tor-client 024-backport MikePerry201309 deleted, tor-client 024-backport MikePerry201308 added
Status: assigned to closed

closed

changed time estimate to 16h

moved to tpo/core/tor#8184 (closed)