Rnsh over Multi hop RNodes

[dannydelcaribe]

Curious if anyone has been able to rnsh over 1 or more RNode hops. Key here being the entire connection is happening over LoRa RNodes. I've gotten it to work with other mediums like wifi and ethernet.

Currently I am able to rnsh to a Raspberry Pi by going p2p. However when I try to extend the range and put a transport node between them, the link fails to establish.

My transport node is a pi zero 2w + heltec v4 running rnsd. Here is a summarized config file:
...
enable_transport = yes
...
[[RNode1]]
type = RNodeInterface
enabled = yes
port = /dev/ttyACM0
[omitted]
mode = gateway

[dannydelcaribe]

I should also note that the rnsh serving device has an announce rate set to 10 second intervals. The server is a Raspberry pi 4b + heltec v4 RNode. The initiator is a Ubuntu Linux laptop with heltec v4. All the RNodeInterface settings match and were tested p2p before attempting the hop.

[markqvist]

Announce interval of ten seconds?!?!? On most LoRa channel configs, that's going to use up most of your bandwidth right there. Ain't gonna be getting much data through.

[metrafonic]

Well everything depends on your lora parameters. I assume you will hit a limit due to the interactive nature of rnsh, sending packets back and forth for each keypress, causing airtime collisions.
What is your lora bitrate? Maybe try out rnx instead?
The higher the bitrate, the lower the airtime, the fewer collisions. Go for something like 5kbps+?

[dannydelcaribe]

So my bitrate is 62kbps. I'm running 915 MHz, bw 500 kHz, sf5, and cr5. I have since reduced the announce rate to just once on start. Still can't say that my transport nodes work.

I have done some simple testing by going to a place where I just lose the p2p connection to my endpoint, then booting up a transport node and placing it in between the two endpoints. The hope being that the transport node can bridge the gap. At the moment it hasn't.

I'm setting the same configuration on all my nodes. I'm wondering if the transport node needs to hear an announce from my destination before it will route traffic to it. As in, if it doesn't hear an announce from my rnsh server, will it not route my rnsh initiator traffic.

I have put the transport node in gateway mode as it seems like the most appropriate. Thanks for all the help guys!

[dannydelcaribe]

Oh and I also enabled line-interactive mode, which is a huge help, but no luck working with transport nodes as of yet.

[skyguy]

Welcome to the fun world of network troubleshooting! My general approach to these kinds of problems is to keep simplifying the setup to try and isolate the problem: You mentioned initially that you have tested succesfully with WiFi and Ethernet - check that ethernet still works since you've probably changed the config a few times during testing :-) Check, especially, that the ethernet setup is actually using the transport node - be sure to disable the AutoInterface on all 3 devices to prevent direct connection from client to server. I would setup a TCPServer interface on the transport node and have the server and client connect to it via TCPClient interfaces. Leave the RNodes attached and configured. Configure Reticulum to run with at least DEBUG-level logging (loglevel=6) so you can see if the Announce from the server is reaching the transport node and client node. (You should see a message like "Destination <aabb..> is now 2 hops away via ...") Test if you can run rnsh on the transport node and connect to the server, then test you can run rnsh on the client. Once that is proven working, leave the config and just unplug one of the ethernet cables to isolate the problem to the RNodes replacing that link. Still working? Plug the cable back in and unplug the other ethernet cable to test the other RNode link. Good luck!

…

-Skyguy

--- https://codeberg.org/skyguy

[dannydelcaribe]

After some further testing, I got rnx to work via multiple RNode hops. On the other hand rnsh never worked for me in the exact same scenario/conditions rnx did. At this moment I don't know the reason, just the result.

I think there may be some issue with half-duplex technologies handling the interactive shell over a hop. The good news is rnx worked reliably.

Of note is that while it worked with the transport node set to mode = full and mode = gateway the latter option allows the transport node to discover unknown paths, thus eliminating the need to set an announce interval on your clients. This is probably well known by most, just something I learned while testing.

[markqvist]

For RNode-based interfaces, you should use ap instead of gateway (on the nodes that connect to wider networks). This means that it will only transmit announces when requested by other peers on that interface, and not waste bandwidth on re-transmitting everything it hears from the wide network (which will quickly consume a high percentage of your available bandwidth).