How to use rnx (or establish links)?

[ddJRC-sys]

Love Reticulum, finding it super useful. One problem I've been having is getting rnx to work. My current setup has two nodes I'll call Sender and Receiver. Sender and Receiver can both send messages to each other in Sideband. Running rnpath shows a path exists 1 hop away. Each is using an I2P interface.

For Sender, I've tried a bunch of variations of rnx [Receiver address] [command or -x]. I've tried swapping [Receiver address] for the Receiver's rnx identity. I've tried adding [-i .reticulum/storage/identities/rnx] to explicitly use the rnx identity generated the first time, though I'm pretty sure that's the default anyway. I've tried using the -v and -d flags, but neither makes any difference at the stage where my commands are failing. I've tried increasing the timeout with -w 10000 but no link ever gets established.

For Receiver, I've tried rnx --listen -a [Sender rnx identity]. I've also tried rnx --listen -n which I understand means it doesn't matter what identity I've used for Sender, it should still accept the command.

Receiver will listen forever. Sender says it's requesting a path and then Establishing link with [address]. It'll run for a little bit and then say Could not establish link with [address].

I have the same issue with rncp and rnsh, so I presume the issue is with establishing the link. I've tried the link.py from the example code and have a similar problem of no link being established. Is there something I'm missing in getting these utilities to work?

[markqvist]

Taking a bit of a wild guess here, since there's no log output or anything to go by, but it could look like you're simply not using the correct destination hash (address).

To make this simple, let's just focus on rnsh. On the listener, first tell rnsh to print its identity used in listener mode, by running rnsh -lp:

$ rnsh -lp

Using service name "default"
Identity     : <d650ac93861d88c1b990248d491ed80d>
Listening on : <e86d97cba9b4976e3f6e5be6940f3ec4>

You'll get the correct destination hash from the "Listening on" line. After that, you should be able to connect with rnsh e86d97cba9b4976e3f6e5be6940f3ec4 (of course, given that you have allowed the remote, or disabled authentication altogether).

It's a common enough misconception, when you're used to IP, to think that addresses are tied to the system, not individual applications or endpoints, and I've seen several people being confused with that, understandably.

[ddJRC-sys]

That did it. I was using rnid -i .reticulum/storage/identities/rnx and thinking that that value was both send and receive. For rnx, just like your example, rnx -p shows Identity, which matches the identity I'm printing in rnid, and then Listening on, which, on the other node, is the address I need to send the command to. So should anyone come across this later with a similar problem, run rnx -p on both nodes (or rncp -p, if using that). The sender addresses the command to the listener's "Listening on" output. The listener listens for the output of the sender's Identity. Something like this:

[Sender]: rnx -p
Identity : <xxxxxxx>
Listening on : <yyyyyyy>

[Listener]: rnx -p
Identity : <aaaaaaa>
Listening on : <bbbbbbb>

[Listener]: rnx --listen -a xxxxxxx

[Sender]: rnx bbbbbbb -x