Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:48:53Zhttps://gitlab.torproject.org/legacy/trac/-/issues/32680Circpad: More/better pattern recognition events2020-06-13T15:48:53ZMike PerryCircpad: More/better pattern recognition eventsResearchers might want other internal events for custom packet pattern recognition, so that they do not have to build quite so complicated state machines. One such example would be an event for ANY_BINS_EMPTY. Others might include packet...Researchers might want other internal events for custom packet pattern recognition, so that they do not have to build quite so complicated state machines. One such example would be an event for ANY_BINS_EMPTY. Others might include packet arrival length counts or patterns.
These are best implemented by adding new circpad_internal_event_*() functions and internal event enums, so that it is easy for machines to make use of them.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32671Circpad padding timer flag is not properly reset2020-06-13T15:48:50ZMike PerryCircpad padding timer flag is not properly resetThis appears to have no consequences outside of the circpad simulator, but we are forgetting to reset the is_padding_timer_scheduled flag in circpad_send_padding_cell_for_callback(). It should get set to 0 at the top of that function.This appears to have no consequences outside of the circpad simulator, but we are forgetting to reset the is_padding_timer_scheduled flag in circpad_send_padding_cell_for_callback(). It should get set to 0 at the top of that function.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32670Provide and use higher resolution padding callback timers2020-06-13T15:48:50ZMike PerryProvide and use higher resolution padding callback timersDuring testing, I noticed that the timers.c callbacks could be up to 10 milliseconds late on an otherwise idle Linux laptop tor client. They might be even later on busy relays.
Circuit fingerprinting results may be impacted by this dela...During testing, I noticed that the timers.c callbacks could be up to 10 milliseconds late on an otherwise idle Linux laptop tor client. They might be even later on busy relays.
Circuit fingerprinting results may be impacted by this delay. If a deep learning classifier is able to determine padding cells through recognizing this delay, padding will entirely ineffective.
It would be nice to have either high priority timers for things like this, or at least better idle resolution.
We do not yet have enough results to say with certainty if high accuracy padding timers are more important for clients, or for relays.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/32040HS intro padding machine reactivates after receiving INTRODUCE_ACK2020-06-16T11:27:52ZGeorge KadianakisHS intro padding machine reactivates after receiving INTRODUCE_ACKWhile reseaching wtf-pad I noticed that the intro machines display a weird shutdown/reactivation pattern.
In particular, what happens is that after INTRODUCE1 is sent, the machine starts up and sends all its padding, and then shuts down...While reseaching wtf-pad I noticed that the intro machines display a weird shutdown/reactivation pattern.
In particular, what happens is that after INTRODUCE1 is sent, the machine starts up and sends all its padding, and then shuts down. Then when INTRODUCE_ACK arrives, it reactivates (probably because INTRODUCE_ACK is part of the accepted purposes and the machine is shutdown/freed at that time) and sends again padding, then again shuts down...
This does not work as intended and causes extra cells to fly in with a pattern that probably does not help them blend in.
Here are some Tor logs (with padanalysis incoming/outgoing cells logs):
```
Oct 11 13:25:54.000 [warn] outgoing-cell: EXTEND2 0
Oct 11 13:25:54.000 [warn] incoming-cell: EXTENDED2 0 66
Oct 11 13:25:54.000 [warn] outgoing-cell: EXTEND2 0
Oct 11 13:25:54.000 [warn] incoming-cell: EXTENDED2 0 66
Oct 11 13:25:57.000 [warn] outgoing-cell: EXTEND 0
Oct 11 13:25:58.000 [warn] incoming-cell: EXTENDED 0 148
Oct 11 13:25:58.000 [warn] outgoing-cell: INTRODUCE1 4
Oct 11 13:25:58.000 [warn] outgoing-cell: PADDING_NEGOTIATE 4
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [info] circpad_handle_padding_negotiated(): Received STOP command on PADDING_NEGOTIATED for circuit 5
Oct 11 13:25:58.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 5 (7)
Oct 11 13:25:58.000 [warn] incoming-cell: INTRODUCE_ACK 4 0
Oct 11 13:25:58.000 [info] rend_client_introduction_acked(): Received ack. Telling rend circ...
Oct 11 13:25:58.000 [info] circpad_setup_machine_on_circ(): Registering machine client_ip_circ to origin circ 5 (8)
Oct 11 13:25:58.000 [info] circpad_node_supports_padding(): Checking padding: supported
Oct 11 13:25:58.000 [info] circpad_negotiate_padding(): Negotiating padding on circuit 5 (8), command 2
Oct 11 13:25:58.000 [warn] outgoing-cell: 8 PADDING_NEGOTIATE 4
Oct 11 13:25:58.000 [info] circpad_machine_spec_transition(): Circuit 5 circpad machine 0 transitioning from 0 to 1
Oct 11 13:25:58.000 [info] circpad_marked_circuit_for_padding(): Circuit 5 is not marked for close because of a pending padding machine in index 0.
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: DROP 4 0
Oct 11 13:25:58.000 [warn] incoming-cell: PADDING_NEGOTIATED 4 4
Oct 11 13:25:58.000 [info] circpad_handle_padding_negotiated(): Received STOP command on PADDING_NEGOTIATED for circuit 5
Oct 11 13:25:58.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 5 (15)
...
Oct 11 13:36:11.000 [info] circuit_mark_for_close_(): Circuit 4130340667 (id: 5) marked for close at src/core/or/circuituse.c:1509 (orig reason: 9, new reason: 0)
```
I'm not sure what the fix should be here. It might be that we need to remove INTRODUCE_ACK from the list of accepted purposes, but if we do that then if INTRODUCE_ACK arrives earlier we will stop padding after. Hmm.Tor: 0.4.4.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/31806Update padding-spec.txt to cover hs circuit setup obfuscation2020-06-13T15:45:49ZMike PerryUpdate padding-spec.txt to cover hs circuit setup obfuscationhttps://github.com/mikeperry-tor/torspec/tree/hs-padding-spec is the updated padding spec with the necessary changes. Current HEAD to merge is 479f0dc4bd2a873ab153ed0e7d7066e975069929https://github.com/mikeperry-tor/torspec/tree/hs-padding-spec is the updated padding spec with the necessary changes. Current HEAD to merge is 479f0dc4bd2a873ab153ed0e7d7066e975069929Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31790Add easy-to-parse event and packet tracing logs to circuit padding2020-06-13T15:45:46ZMike PerryAdd easy-to-parse event and packet tracing logs to circuit paddingWhen we developed the onion service circuit setup obfuscation, it was helpful to instrument Tor with log messages that told us when padding and non-padding cells were sent.
This same kind of instrumentation would be useful for a trace s...When we developed the onion service circuit setup obfuscation, it was helpful to instrument Tor with log messages that told us when padding and non-padding cells were sent.
This same kind of instrumentation would be useful for a trace simulator, but we should do it at the circuit padding cell event callback layer, so that it can be used separately from Tor.
For reference, the analyzer we used is at https://github.com/asn-d6/padanalyzerhttps://gitlab.torproject.org/legacy/trac/-/issues/31789Make networking usage in circuit padding more abstract2020-06-13T15:45:46ZMike PerryMake networking usage in circuit padding more abstractWhen we send packets in the framework, we call into relay.c and do some cell parsing setup. If we moved this code into a separate c file, it will be easier to replace it with simulated calls for a trace simulator.
This is not strictly r...When we send packets in the framework, we call into relay.c and do some cell parsing setup. If we moved this code into a separate c file, it will be easier to replace it with simulated calls for a trace simulator.
This is not strictly required, but it will allow us to more easily update both the simulator and the in-tor implementation without conflicts.https://gitlab.torproject.org/legacy/trac/-/issues/31788Circuit padding trace simulator2020-06-13T15:45:46ZMike PerryCircuit padding trace simulatorThis is the parent ticket for the pieces of work required to make it possible to use circuitpadding.c in a trace simulator outside of Tor, so that defenses could be re-applied to crawl traces quickly without needing to re-crawl a set of ...This is the parent ticket for the pieces of work required to make it possible to use circuitpadding.c in a trace simulator outside of Tor, so that defenses could be re-applied to crawl traces quickly without needing to re-crawl a set of sites.
An alternate way to do this, instead of extracting this code, is to make use of our unit testing framework and build the tracer as a unit test. We have mechanisms to mock the networking functions so that they output new traces, and then we can use the unit-test style to read in a trace file and output a new one, instead of performing a test.https://gitlab.torproject.org/legacy/trac/-/issues/31787Full HMM support for circuit padding state transition2020-06-13T15:45:45ZMike PerryFull HMM support for circuit padding state transitionThe circuit padding state transition system is quasi-deterministic. A non-deterministic state machine can be built from this using many states through clever use of the infinity bin, but this will lead to excessively complicated machines...The circuit padding state transition system is quasi-deterministic. A non-deterministic state machine can be built from this using many states through clever use of the infinity bin, but this will lead to excessively complicated machines.
One can imagine a non-deterministic state machine/HMM that simulates an entire web browsing session on a circuit. If this kind of machine seems useful, it may be better simply to transform the circpad_state_t.next_state transition field into an array of structs that specifies the next state as well as a probability for transitioning to that state for that event.
We would accept patches for this modification if it seems useful.https://gitlab.torproject.org/legacy/trac/-/issues/31783Circuit padding support for multi-circuit behavior2020-06-13T15:45:44ZMike PerryCircuit padding support for multi-circuit behaviorTor's circuit padding only operates on individual circuits. For fingerprints that span the creation of multiple circuits, it may be useful to provide some probability of launching new circuits devoted exclusively to padding (CIRCUIT_PURP...Tor's circuit padding only operates on individual circuits. For fingerprints that span the creation of multiple circuits, it may be useful to provide some probability of launching new circuits devoted exclusively to padding (CIRCUIT_PURPOSE_C_CIRCUIT_PADDING).
At the moment, it is not clear if these circuits should be launched probabilisticly, or by some event-driven mechanism.https://gitlab.torproject.org/legacy/trac/-/issues/31782Circuit padding is not subject to flow control2020-06-13T15:45:44ZMike PerryCircuit padding is not subject to flow controlBecause Tor's flow control only applies to RELAY_COMMAND_DATA cells, the padding injected by circuit padding is not subject to flow control (RELAY_COMMAND_SENDME).
For small amounts of padding, this is insignificant, but for larger amou...Because Tor's flow control only applies to RELAY_COMMAND_DATA cells, the padding injected by circuit padding is not subject to flow control (RELAY_COMMAND_SENDME).
For small amounts of padding, this is insignificant, but for larger amounts, it may be desirable to subject it to flow control, or to create some other form of flow control specifically for padding.https://gitlab.torproject.org/legacy/trac/-/issues/31653Padding cells sent with 0ms delay cause circuit failures2020-06-13T15:45:20ZpullsPadding cells sent with 0ms delay cause circuit failuresBelow appears to be a bug that results in a closed circuit due to a relay sending a padding cell (RELAY_COMMAND_DROP) to the client.
At links below you find code for two circuit padding machines:
1. circpad_machine_client_close_circuit_...Below appears to be a bug that results in a closed circuit due to a relay sending a padding cell (RELAY_COMMAND_DROP) to the client.
At links below you find code for two circuit padding machines:
1. circpad_machine_client_close_circuit_minimal
2. circpad_machine_relay_close_circuit_minimal
Machine 1 runs on a client on CIRCUIT_PURPOSE_C_GENERAL circuits with 3 hops as soon as CIRCPAD_CIRC_OPENED: the only thing it does is set a timer 1000s in the future and waits for the timer to expire. The purpose of the machine is to negotiate padding with the relay to activate Machine 2 on the middle relay.
Machine 2 runs at the middle relay and repeatedly sends a padding cell to the client 1 usec after the event CIRCPAD_EVENT_NONPADDING_SENT. In other words, for every non-padding cell we directly add a padding cell. At the client, this causes `relay_decrypt_cell(): Incoming cell at client not recognized. Closing.` for all circuits triggering Machine 2 at the relay. Closing a circuit by injecting padding cells seems unintended.
Here is part of a log from a client on info level showing how the machine registers, negotiates with the relay (starting Machine 2 at the relay), eventually fails to decrypt, and the circuit closes.
```
Sep 05 10:32:19.000 [info] circpad_setup_machine_on_circ(): Registering machine client_close_circuit_minimal to origin circ 3 (5)
Sep 05 10:32:19.000 [info] circpad_node_supports_padding(): Checking padding: supported
Sep 05 10:32:19.000 [info] circpad_negotiate_padding(): Negotiating padding on circuit 3 (5), command 2
Sep 05 10:32:19.000 [info] link_apconn_to_circ(): Looks like completed circuit to [scrubbed] does allow optimistic data for connection to [scrubbed]
Sep 05 10:32:19.000 [info] connection_ap_handshake_send_begin(): Sending relay cell 0 on circ 3296464733 to begin stream 20575.
Sep 05 10:32:19.000 [info] connection_ap_handshake_send_begin(): Address/port sent, ap socket 13, n_circ_id 3296464733
Sep 05 10:32:19.000 [info] rep_hist_note_used_port(): New port prediction added. Will continue predictive circ building for 2355 more seconds.
Sep 05 10:32:19.000 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for circuit' state. Leaving it on buffer.
Sep 05 10:32:19.000 [info] exit circ (length 3): $[manually-scrubbed](open) $[manually-scrubbed](open) $[manually-scrubbed](open)
Sep 05 10:32:19.000 [info] pathbias_count_use_attempt(): Used circuit 3 is already in path state use attempted. Circuit is a General-purpose client currently open.
Sep 05 10:32:19.000 [info] link_apconn_to_circ(): Looks like completed circuit to [scrubbed] does allow optimistic data for connection to [scrubbed]
Sep 05 10:32:19.000 [info] connection_ap_handshake_send_begin(): Sending relay cell 0 on circ 3296464733 to begin stream 20576.
Sep 05 10:32:19.000 [info] connection_ap_handshake_send_begin(): Address/port sent, ap socket 14, n_circ_id 3296464733
Sep 05 10:32:19.000 [info] circpad_deliver_recognized_relay_cell_events(): Got padding cell on origin circuit 3.
Sep 05 10:32:20.000 [info] relay_decrypt_cell(): Incoming cell at client not recognized. Closing.
Sep 05 10:32:20.000 [info] circuit_receive_relay_cell(): relay crypt failed. Dropping connection.
Sep 05 10:32:20.000 [info] command_process_relay_cell(): circuit_receive_relay_cell (backward) failed. Closing.
Sep 05 10:32:20.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing padding info idx 0 on circuit 3 (23)
Sep 05 10:32:20.000 [info] circpad_node_supports_padding(): Checking padding: supported
Sep 05 10:32:20.000 [info] circpad_negotiate_padding(): Negotiating padding on circuit 3 (23), command 1
Sep 05 10:32:20.000 [info] pathbias_send_usable_probe(): Sending pathbias testing cell to 0.233.9.53:25 on stream 20577 for circ 3.
Sep 05 10:32:20.000 [info] relay_decrypt_cell(): Incoming cell at client not recognized. Closing.
Sep 05 10:32:20.000 [info] circuit_receive_relay_cell(): relay crypt failed. Dropping connection.
Sep 05 10:32:20.000 [info] command_process_relay_cell(): circuit_receive_relay_cell (backward) failed. Closing.
Sep 05 10:32:20.000 [info] pathbias_send_usable_probe(): Got pathbias probe request for circuit 3 with outstanding probe
Sep 05 10:32:20.000 [info] pathbias_check_close(): Circuit 3 closed without successful use for reason 2. Circuit purpose 23 currently 1,open. Len 3.
Sep 05 10:32:20.000 [info] circuit_mark_for_close_(): Circuit 3296464733 (id: 3) marked for close at src/core/or/command.c:582 (orig reason: 2, new reason: 0)
Sep 05 10:32:20.000 [info] connection_edge_destroy(): CircID 0: At an edge. Marking connection for close.
Sep 05 10:32:20.000 [info] connection_edge_destroy(): CircID 0: At an edge. Marking connection for close.
Sep 05 10:32:20.000 [info] circuit_free_(): Circuit 0 (id: 3) has been freed.
```
If we delay sending the padding from the relay I cannot trigger the bug (see commented out fix in the Machine 2 function). With the code below, the code triggers on every circuit that has the machine negotiated.
Code: https://github.com/pylls/tor/tree/circuit-padding-relay-padding-bug (https://github.com/pylls/tor/blob/circuit-padding-relay-padding-bug/src/core/or/circuitpadding_machines.c#L460, as well as circuitpadding_machines.h and registration in circpad_machines_init() of circuitpadding.c).Tor: unspecifiedMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/31636Circuit padding: Add meta probability distribution type2020-06-13T15:45:14ZMike PerryCircuit padding: Add meta probability distribution typeTobias Pulls pointed out that his APE system actually randomized the *parameters* of the probability distributions that he used, for each circuit.
If this is indeed helpful (it probably is), we should find out which form or forms of per...Tobias Pulls pointed out that his APE system actually randomized the *parameters* of the probability distributions that he used, for each circuit.
If this is indeed helpful (it probably is), we should find out which form or forms of per-circuit parameter randomization is best to use, and get it supported by the circuit padding framework.Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/31393Stop declaring support for Padding=1 after 0.4.1-stable is released2020-06-13T15:44:15ZteorStop declaring support for Padding=1 after 0.4.1-stable is releasedOnce 0.4.1-stable is released (and on deb.tpo as the stable version), there will be a lot of relays with Padding=2. So we can stop declaring support for Padding=1.Once 0.4.1-stable is released (and on deb.tpo as the stable version), there will be a lot of relays with Padding=2. So we can stop declaring support for Padding=1.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31392Explain Padding 1 and 2 in tor-spec.txt2020-06-13T15:44:14ZteorExplain Padding 1 and 2 in tor-spec.txtPadding=1 is declared by some versions of tor without Padding support. We will stop declaring support for it I once #31356 is merged into 0.4.1.
Padding=2 is the guaranteed working version once #31356 is merged into 0.4.1 and later.Padding=1 is declared by some versions of tor without Padding support. We will stop declaring support for it I once #31356 is merged into 0.4.1.
Padding=2 is the guaranteed working version once #31356 is merged into 0.4.1 and later.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31387Make 0.4.1 and later clients require Padding=22020-06-13T15:44:13ZteorMake 0.4.1 and later clients require Padding=2As part of #31356, we need to make 0.4.1 and later clients require Padding=2.As part of #31356, we need to make 0.4.1 and later clients require Padding=2.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/313560.4.1 relays should list Padding=22020-06-13T15:44:06ZMike Perry0.4.1 relays should list Padding=2Somehow we accidentally merged the protover for padding support while doing the incremental merge thing, and 0.4.0 relays are advertising padding that they don't support. This is mostly harmless, because the negotiation will not succeed ...Somehow we accidentally merged the protover for padding support while doing the incremental merge thing, and 0.4.0 relays are advertising padding that they don't support. This is mostly harmless, because the negotiation will not succeed and then clients will stop, but it will result in those clients emitting a "Middle node did not accept our padding request" protocol warn/info message.
~~We should just remove this protover field from 0.4.0.x.~~
At the weekly meeting last week, we decided that we can't remove a protover once it's been released.
Instead, we will:
* make 0.4.1 and later relays declare Padding=2 (pre-0.4.1 stable)
* make 0.4.1 and later clients require Padding=2 (padding is not on by default, so we can do this at any time)
Edited to simplify: we don't need to preserve compatibility with alphas.Tor: 0.4.1.x-finalMike PerryMike Perryhttps://gitlab.torproject.org/legacy/trac/-/issues/31112remove specified target_hopnum from relay-side machines2020-06-13T15:43:30Zpullsremove specified target_hopnum from relay-side machinesFor circuit padding machines, the `target_hopnum`field in `struct circpad_machine_spec_t`is only for origin-side machines. Currently, the relay side of the two onion-related machines set the field. This should be safe to remove. PR here:...For circuit padding machines, the `target_hopnum`field in `struct circpad_machine_spec_t`is only for origin-side machines. Currently, the relay side of the two onion-related machines set the field. This should be safe to remove. PR here: https://github.com/torproject/tor/pull/1170.Tor: 0.4.2.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31111Properly support two padding machines per circuit2020-06-13T15:43:29ZpullsProperly support two padding machines per circuitAs part of `circuitpadding.c`, in `circpad_add_matching_machines()`, the macros `FOR_EACH_CIRCUIT_MACHINE_BEGIN` and `SMARTLIST_FOREACH_REVERSE_BEGIN` currently expand to a for loop each. Below a slightly cropped (...) version of `circpa...As part of `circuitpadding.c`, in `circpad_add_matching_machines()`, the macros `FOR_EACH_CIRCUIT_MACHINE_BEGIN` and `SMARTLIST_FOREACH_REVERSE_BEGIN` currently expand to a for loop each. Below a slightly cropped (...) version of `circpad_add_matching_machines()`:
```
circpad_add_matching_machines(origin_circuit_t *on_circ,
smartlist_t *machines_sl)
{
...
FOR_EACH_CIRCUIT_MACHINE_BEGIN(i) {
...
SMARTLIST_FOREACH_REVERSE_BEGIN(machines_sl,
circpad_machine_spec_t *,
machine) {
...
if (circpad_negotiate_padding(on_circ, machine->machine_num,
machine->target_hopnum,
CIRCPAD_COMMAND_START) < 0) {
log_info(LD_CIRC, "Padding not negotiated. Cleaning machine");
circpad_circuit_machineinfo_free_idx(circ, i);
circ->padding_machine[i] = NULL;
on_circ->padding_negotiation_failed = 1;
} else {
/* Success. Don't try any more machines */
return;
}
}
} SMARTLIST_FOREACH_END(machine);
} FOR_EACH_CIRCUIT_MACHINE_END;
}
```
The outer loop goes over each machine index (currently 2, set by `CIRCPAD_MAX_MACHINES`), while the inner loop looks for a suitable machine for that index to negotiate. As soon as one is found and negotiated, currently, the function returns without looking for a machine for later indices in the outer loop. The `return` should be replaced by a `break` to continue looking for a machine for the next index.
See https://github.com/torproject/tor/pull/1168 for a PR.Tor: 0.4.3.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30992circpadding machines have shutdown sync issues (with intro circ NACKs and oth...2020-06-13T15:43:02ZGeorge Kadianakiscircpadding machines have shutdown sync issues (with intro circ NACKs and other cases)When client-side intro circuits get NACKed they re-extend to a different intro point using the same circuit.
This seems to mess up the circsetup machines and we get "padding came from wrong hop" log warns.When client-side intro circuits get NACKed they re-extend to a different intro point using the same circuit.
This seems to mess up the circsetup machines and we get "padding came from wrong hop" log warns.Tor: 0.4.4.x-finalMike PerryMike Perry