"Unhandled exception: Path not found" when connecting through hops

[gyv4]

Hi, and thanks for writing this tool, first.
I am testing it in different configurations, and it works when the peers are directly visible on the same local network, but I have this issue when connected via at least one hop.
The listener waits, and the initiator returns
Unhandled exception: Path not found

In the same configuration, the peers can see each other (tested with nomadnet), and a link can successfully be created using the reticulum utility
rnx

For this specific case, reticulum v 0.5.5 and rnsh v 0.1.1 are used.
Linstener on Pizero2W Raspbian GNU/Linux 10 (buster) (32 Bit)
Initiator MacOs.

Any hints to solve the issue would be appreciated.

[markqvist]

I am pretty sure this is not a bug in rnsh, but just a general issue of never having sent an announce from the listening instance. Either way, just to shed some general light on stuff like this, here's a few notes:

In general, any Reticulum application should handle path resolution itself. This is intentionally done to let the developer choose how to an application should act if a path to a destination is not already known.

The developer should:

• Use the has_path() API call to check whether a path is already known.
• Use the request_path() API call to request a path if you need/want to.

As far as I know, and have seen in my own use of rnsh, this is already happening correctly, since I have never run into this before, even connecting to systems over many hops.

Maybe this could be something as simple as your listening rnsh instance never having sent an announce on the network, could it? If this is the case, and your network topology is not configured in a way that allows for recursive path resolution, the path request will simply time out, and you will get an exception in the end, because no path can be found within the timeout period.

The solution here is probably just to make sure your listener has actually sent an announce (once or periodically), or to set up recursive path resolution.

[acehoss]

Hi @gyv4 and @markqvist! I think @markqvist is correct that it is unlikely a bug in rnsh. The point in the code where this exception is raised is already using the method @markqvist mentions. The exception is raised when, after calling request_path(), has_path() does not return True after some timeout. The default timeout is the value of RNS.Transport.PATH_REQUEST_TIMEOUT, which comes from the Reticulum base library (written by @markqvist).

Now, that said, I have experienced this same issue intermittently, particularly when running from a machine that does not use a daemonized rnsd instance. I've found that just rerunning the command line usually works when this happens.

Something you could try, @gyv4, is to adjust the timeout value using the -w parameter; for example, add -w 10 to the command line to set the timeout to 10 seconds.

[gyv4]

Hi @acehoss and @markqvist,

and thanks for the answers, and the clarifications.

Something you could try, @gyv4, is to adjust the timeout value using the -w parameter; for example, add -w 10 to the command line to set the timeout to 10 seconds.

Regarding this, I had tried this before and there is a minor issue

Unhandled exception: unsupported operand type(s) for +: 'float' and 'str'

The initiator.py tries to combine a float and a string

timeout = time.time()+timeout

But I had fixed it locally, and it did not make any difference.
But clearly, @markqvist, I have just started to learn how to use reticulum, and still I have a lot to understand. Thanks for the explanation.

I was able to make it work. But still it is not clear to me if I was doing something wrong, or if now the network is set up correctly. Here are some details.

Maybe this could be something as simple as your listening rnsh instance never having sent an announce on the network, could it? If this is the case, and your network topology is not configured in a way that allows for recursive path resolution, the path request will simply time out, and you will get an exception in the end, because no path can be found within the timeout period.

For the announce part, I do not think so.
I was using a configuration with a single hop, through a reticulum node that was configured to be a TCP server. I had the simplest configuration, and no mode was specified explicitly (so I assume it was in mode =full).
Starting the rnsh listener, I could see the destination the path of the listener on the intermediate node. So the announce had been sent.
And I could connect via rnsh to both the "end nodes" from the middle one. And I could connect from one end-node to the other through the same hop with rnx, and the peers on those nodes could see each other with nomadnet.
So I was assuming that the network configuration was correct.

Then I made a test using one of the Testnet nodes as hop, and I could connect my two end-nodes with rnsh. So I went back to the reticulum manual to see what I could have done wrong with my TCP server configuration.
Reading the documentation in the Interface sections, I found

The gateway mode (or shorthand gw) also has all discovery, meshing and transport functionality available, but will additionally try to discover unknown paths on behalf of other nodes residing on the gateway interface.

I thought about changing the mode to gateway, and then the connection between the two nodes worked.

Is this the correct setting? I do not understand why the original configuration was good enough for rnxbut not for rnsh. I had started looking into the source codes of both, and could see that both were using the same mechanism.

Thanks again to both. I asked for some hints, and I got some.