hs-v3: Add the 2 missing SOCKS extended errors from prop304

The two missing codes are the intro failure and RP failure.

    * X'F2' Onion Service Introduction Failed

      Client failed to introduce to the service meaning the descriptor was
      found but the service is not anymore at the introduction points. The
      service has likely changed its descriptor or is not running.

    * X'F3' Onion Service Rendezvous Failed

      Client failed to rendezvous with the service which means that the client
      is unable to finalize the connection.

changed milestone to %Tor: 0.4.4.x-final

Trac:
Parent Ticket: #30025 (moved)

added 043-can actualpoints::0.4 component::core tor/tor milestone::Tor: 0.4.4.x-final network-team-roadmap-2020Q1 owner::dgoulet parent::30025 points::1 priority::medium resolution::fixed reviewer::asn severity::normal sponsor::27-must status::closed tor-hs type::defect labels

Trac:
Cc: N/A to brade, mcs

Discussion with asn on this:

• We'll send back the X'F2' code if we get a NACK from every IP in the descriptor (meaning that the service is actually offline and no service-side intro circuits could be found by the IP)

• We'll send back the X'F3' code when the RP circuit times out. We'll need a spec clarification.

• We'll send a new error code when all IP circuit timed out. Basically, if we try all IPs in the descriptor and they all gave us a circuit time out, we'll send back that code. (meaining that something is wrong with the client's network)

Branch: ticket32542_043_01 PR: https://github.com/torproject/tor/pull/1597

(No tor-spec patch since socks-extension.txt points to the man page for the error codes.)

This is a bit tricky as in the "from where we report the codes" so word of advise for the reviewer.

The introduction failure codes are reported back if the descriptor we just fetched has no usable introduction points. This is a bit counter intuitive but the reason is because tor will refetch a descriptor if all intro points fail and then notice they are the same again and stop. That very moment is where the failure is reported.

Trac:
Actualpoints: N/A to 0.4
Status: assigned to needs_review

tag all currently needs_review tickets with 043-can. (Since there's code before the feature freeze, maybe we can take it.)

Trac:
Keywords: N/A deleted, 043-can added

Trac:
Keywords: N/A deleted, network-team-roadmap-2020Q1 added

Looking good but I pointed out a few stuff on the PR.

Also the fact that this hasn't been tested in real life makes me a bit anxious that things might crash or not work as intended. We could at least test the introduction F2 by shutting down the service in a chutney network, and having the client download the descriptor and trying to connect to it (all intros would send NACKs).

Trac:
Status: needs_review to needs_revision

I guess this is 044 material now.

Trac:
Milestone: Tor: 0.4.3.x-final to Tor: 0.4.4.x-final

Trac:
Parent: #14389 (moved) to #30025 (moved)

I was able to test the F2 code and confirm we get it if all IPs NACK us. The F3 and F7 are timeout and apart from unit testing, I'm unable to test with chutney without some heavy tor modification.

At least that code base is unit tested so I'm confident for no crash. We'll have to see with 044 stabilization any bugs for those code.

Branch: ticket32542_044_01 PR: https://github.com/torproject/tor/pull/1857

Trac:
Status: needs_revision to needs_review

Merged!!! Fixed a syntax error in the man page before merging (Similar has X'F2' code... -> Similar to X'F2' code...) as well.

Thanks! :)

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

closed

changed time estimate to 8h

added 3h 12m of time spent

mentioned in issue #33035 (moved)

mentioned in issue #34226 (moved)

mentioned in issue #30025 (moved)

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