[tor-bugs] #20472 [Core Tor/Tor]: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL) failed

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Oct 28 03:31:39 UTC 2016

#20472: circuit_pick_extend_handshake: Non-fatal assertion !(node_prev == NULL)
 Reporter:  cypherpunks                          |          Owner:
     Type:  defect                               |         Status:
                                                 |  needs_revision
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.2.9.x-final
Component:  Core Tor/Tor                         |        Version:  Tor:
 Severity:  Normal                               |     Resolution:
 Keywords:  TorCoreTeam201610, regression,       |  Actual Points:  0.3
  029-backport                                   |
Parent ID:                                       |         Points:  0.3
 Reviewer:                                       |        Sponsor:
Changes (by teor):

 * status:  needs_review => needs_revision


 Replying to [comment:3 nickm]:
 > Are there any versions on the network that don't support EXTEND2,
 though? If not, we might be better off just using EXTEND2 unconditionally
 in this case.

 tor-spec.txt says:
    [Support for EXTEND2 was added in Tor]

    Clients SHOULD use the EXTEND format whenever sending a TAP
    handshake, and MUST use it whenever the EXTEND cell will be handled
    by a node running a version of Tor too old to support EXTEND2.  In
    other cases, clients SHOULD use EXTEND2.

    When encoding a non-TAP handshake in an EXTEND cell, clients SHOULD
    use the format with 'client handshake type tag'.

 And is not in recommended versions, and has not been for some
 time, and the directory authorities reject descriptors less than

 So the answer is: there are no nodes that affirmatively claim to only
 support EXTEND, but some custom or versionless implementations might not
 support it, and might not tell us. And other nodes could say they don't
 support it using the new supported protocols lines in descriptors.

 Oh, but some bridges might only support CREATE/EXTEND. I don't think this
 matters, because we use CREATE_FAST for the first hop anyway.

 So I think you're right, we should simplify this logic and just use
 versionless/unknown version/etc. nodes support EXTEND2. It's not worth
 having the extra code just for a few nodes that are really old.

 The corresponding tor-spec.txt for CREATE is:

    In general, clients SHOULD use CREATE whenever they are using the TAP
    handshake, and CREATE2 otherwise.  Clients SHOULD NOT send the
    second format of CREATE cells (the one with the handshake type tag)
    to a server directly.

    Servers always reply to a successful CREATE with a CREATED, and to a
    successful CREATE2 with a CREATED2.  On failure, a server sends a
    DESTROY cell to tear down the circuit.

    [CREATE2 is handled by Tor and later.]

Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20472#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

More information about the tor-bugs mailing list