On 28 Apr 2020, at 11:47, Eli Vakrat <eli@xxxxxxxxxx> wrote:
But then I looked at the debug log of my guard node (remember that my guard node is on my local machine) and it said that it had received a DESTROY Cell back from the middle node and was passing on a RELAY_TRUNCATED cell to me:
Apr 26 16:11:03.014 [debug] command_process_destroy_cell: Received for circID 2297363203. <------this is the circuit ID between my gaurd node and the middle node
Apr 26 16:11:03.014 [debug] command_process_destroy_cell: Delivering 'truncated' back.
Apr 26 16:11:03.014 [debug] relay_send_command_from_edge_: delivering 9 cell backward.
To my understanding what this log means is that some part of the EXTEND cell I sent to the middle node was wrong or malformed and because of this when the middle node tried to extend the circuit, an error occurred, and the circuit needed to be torn down.
This is very weird because when I send an EXTEND cell that is meant for my guard node (meaning I want to extend the circuit from one hop to two hops) everything works fine, and I can even successfully derive the shared key material for the middle node.
It looks like there are at least two bugs here: * encryption to the guard node * decryption from the guard node
So I have several questions regarding this:
1. First of all, I didn't quite understand the exact format of a RELAY_TRUNCATED cell. Does it contain a relay cell command + recognized+field +digest and so on? or is it just a single octet that immediately follows the cell command field? If some could show me an example of the cell, it would be much appreciated...
It's a relay cell, so it contains all the relay cell fields: Then the relay cell's "data" contains a single byte "reason" field.
I agree it's confusing, I've fixed it in the spec. 2. What are some common errors that would make an OR drop a RELAY EXTEND cell? I thought maybe it was a problem with my TAP handshake data, but after extensive checking that doesn't seem to be the case.
Have you tried running the middle relay on your machine as well?
You can run a whole tor network on your machine using chutney: (If you're using Windows, Chutney won't work, because directory authorities don't work on Windows.)
Try: CHUTNEY_STOP_TIME=-1 chutney/tools/test-network.sh Then extend to the relays on 127.0.0.1.
It looks like you can't encrypt cells to the guard.
Have you tried sending a RELAY_DROP cell to the guard? That's a good way to test encryption.
It also looks like you can't decrypt cells from the guard.
What's the data in the first CREATED cell from the guard? Should it be all-zero? (Check the tor source code.)
Have you tried opening a stream to the guard node? That's a good way to test decryption.
Most guards are directory caches, so you should be able to open a RELAY_BEGINDIR stream, and download something small. Like the relay's descriptor.
3. If someone could describe the exact steps of extending a circuit to a third node, it would greatly help me to make sure that I didn't miss a step or do something wrong.
Here's the spec for multi-hop circuits:
It's hard to know what steps you're missing, without more information. Feel free to share your code, or ask questions about any confusing parts of the spec.
|