Setup

[HansNilovitsch]

Hi,

I'm a student at an technical school. i am new to this and having trouble setting up an local or testnet instance.
the plan is to set up three devices (1 node, 2 client) to analyze the network traffic between these to have a look at how "anonymized" header with destination hashes look like.
so i want to read out network traffic "caused" by reticulum too see its anonymity features

i installed reticulum as described in the manual on all devices. each got own identities (and hashes).

the configuration files include both testnets interfaces as shown. the rnstatus shows connectivity on all three devices. the node an device2 (debian-based linux) additionally got an autointerface (if i add autointerfaces to device1(macOS), it throws an error)

Client 1 (MacOS) is struggeling if i add an autointerface (like below) :

[[Default Interface]]
type = AutoInterface
enabled = yes

throws this error:
[Warning] AutoInterface[Default Interface] Detected possible carrier loss on utun0: [Errno 55] No buffer space available
--> wants to use utun0, if im right, the interface is used by vpn. (but im not connecting via any vpn)

if only the testnet interfaces are included in the config it wont throw an error.

TCP/IP interface to the RNS Amsterdam Hub

[[RNS Testnet Amsterdam]]
  type = TCPClientInterface
  enabled = yes
  target_host = amsterdam.connect.reticulum.network
  target_port = 4965

TCP/IP interface to the BetweenTheBorders Hub (community-provided)

[[RNS Testnet BetweenTheBorders]]
  type = TCPClientInterface
  enabled = yes
  target_host = reticulum.betweentheborders.com
  target_port = 4242

--> [Notice] Started rnsd version 1.0.0
rnstatus

Shared Instance[37428]
Status : Up
Serving : 0 programs
Rate : 1.00 Gbps
Traffic : ↑0 B 0 bps
↓0 B 0 bps

TCPInterface[RNS Testnet Amsterdam/amsterdam.connect.reticulum.network:4965]
Status : Up
Mode : Full
Rate : 10.00 Mbps
Traffic : ↑200 B 0 bps
↓0 B 0 bps

TCPInterface[RNS Testnet BetweenTheBorders/reticulum.betweentheborders.com:4242]
Status : Up
Mode : Full
Rate : 10.00 Mbps
Traffic : ↑199 B 0 bps
↓0 B 0 bps

the node is set up on an raspberry pi (used as pi_hole) with all three interfaces (two testnet and the autointerface) and wont throw errors:

rnstatus ->

Shared Instance[rns/default]
Status : Up
Serving : 0 programs
Rate : 1.00 Gbps
Traffic : ↑0 B 0 bps
↓0 B 0 bps

AutoInterface[Default Interface]
Status : Up
Mode : Full
Rate : 10.00 Mbps
Peers : 0 reachable
Traffic : ↑2.83 KB 0 bps
↓0 B 0 bps

TCPInterface[RNS Testnet Amsterdam/amsterdam.connect.reticulum.network:4965]
Status : Up
Mode : Full
Rate : 10.00 Mbps
Traffic : ↑54.02 KB 0 bps
↓71.73 KB 0 bps

TCPInterface[RNS Testnet BetweenTheBorders/reticulum.betweentheborders.com:4242]
Status : Up
Mode : Full
Rate : 10.00 Mbps
Traffic : ↑54.22 KB 0 bps
↓36.41 KB 0 bps

Transport Instance <HASH> running
Uptime is 1h, 20m and 28.28s

although i'm using the hashes of all three devices generated with rnid -g [name] like displayed via rnid -i [name], i wont get any feedback when using rnprobe .
i also did not see why the "transport instance" hash differ from the nodes actual identity hash.

maybe any of you is more into this and can help me troubleshoot to achieve my goals. tell me which further information you need to help me.

thank you very much

[kc1awv]

I believe you can disable the AutoInterface if you're not using it. The AutoInterface is used to discover other Reticulum nodes on the same network i.e.: devices all connected to the same local LAN. If you're running individual nodes that don't need to discover each other locally, then I believe the AutoInterface can be turned off.

The important thing to know about AutoInterface is that you need to have a working IPv6 stack running on all the devices that have RNS running. I don't know much about MacOS to tell you how/what is going on there, but if you're not using AutoInterface, you should be able to turn it off with no harm done. Of course, I'm just a guy who dabbles with Reticulum here, so there may be people here with answers that are more correct. 😄

[HansNilovitsch]

thanks for that fast reply.
the main problem here is not that one device is not able to use autointerface. the problem is, all setups of reticulum seems to be fine, but i can't reach any destinatination/device or node with rnprobe , i just want to route packages local via RNS and tunneled on tcp to see what you can detect on traffic analysis.

[skyguy]

If your clients are connecting to the wider Reticulum network succesfully, you can just use WireShark to inspect the data flowing on the network.

If you want a more controlled environment, I would suggest removing the interfaces to the Testnet from all devices. Then:

On the node/server device, disable the AutoInterface and configure a single TCPServerInterface with entries in the config like this:

[[Default Interface]]
type = AutoInterface
interface_enabled = False

[[TCP Server Interface]]
type = TCPServerInterface
enabled = yes
listen_ip = 0.0.0.0
listen_port = 4242

On the clients, disable the AutoInterface and configure a single TCPClientInterface:

[[Default Interface]]
type = AutoInterface
interface_enabled = False

[[TCP Client Interface]]
type = TCPClientInterface
enabled = yes
target_host = 1.2.3.4
target_port = 4242

[Replace the "1.2.3.4" with the address of your node/server.]

Also, to get the node/server to route traffic and respond to probes, make sure you configure these options in the [reticulum] section:

enable_transport = yes
respond_to_probes = yes

[HansNilovitsch]

Also thanks again for that fast reply. i think this helped a lot to come further achieving my goal but i still need some help i think.

So i deleted these public testnodes.

my client config contains:

[[TCP Client Interface]]
type = TCPClientInterface
enabled = yes
target_host = IP-Address x.x.x.x
target_port = 4242

node config:

enable_transport = yes
respond_to_probes = Yes

[[TCP Server Interface]]
type = TCPServerInterface
enabled = yes
listen_ip = 0.0.0.0
listen_port = 4242

---

Node rnstatus:

Shared Instance[rns/default]
Status : Up
Serving : 0 programs
Rate : 1.00 Gbps
Traffic : ↑0 B 0 bps
↓0 B 0 bps

TCPServerInterface[TCP Server Interface/0.0.0.0:4242]
Status : Up
Clients : 1 <----------- edit (10:55): now 2 clients
Mode : Full
Rate : 10.00 Mbps
Traffic : ↑169 B 0 bps
↓297 B 0 bps

Transport Instance HASH1 running
Probe responder at HASH2 active <---------- is it fine that Transport Instance and Probe responder are different?
Uptime is 12m and 56.62s

---

Client rnstatus:

Started rnsd version 1.0.0

Shared Instance[37428]
Status : Up
Serving : 0 programs
Rate : 1.00 Gbps
Traffic : ↑0 B 0 bps
↓0 B 0 bps

TCPInterface[TCP Client Interface/:4242]
Status : Up
Mode : Full
Rate : 10.00 Mbps
Traffic : ↑198 B 0 bps
↓0 B 0 bps

client rnprobe: (i think this should be fine and output on both clients is the same)

• to Destination/Identity HASH1 (Transport)
  rnprobe RaspNode HASH1
  Path request timed out

• to Destination/Identity HASH2 (Probe responder)
  rnprobe RaspNode HASH2
  Probe timed out
  Sent 1, received 0, packet loss 100.0%

what am i missing here?
edit (10:55):
both clients respond to rnpath with this:
rnpath (Probe responder HASH2)
Path found, destination is 1 hop away via on TCPInterface[TCP Client Interface/IP-Address:4242]

BUT:
both clients respond with "Path not found" if i rnpath to their destination hashes (client 1 -> 2 and client 2 -> 1)

[markqvist]

Reticulum works very differently than what you might expect if you're used to IP networks. The first thing to realize is that devices themselves actually don't have an address. Not even a transport node (router) will have an address itself, per se. The packet transport (routing) is completely transparent.

This means that any routing device doesn't actually "show up" on the network, nor is it addressable. This is by design. As you found out, you can however enable a "probe responder" destination (but this is turned off by default). With this setting on, a Reticulum transport instance will create a destination (addressable endpoint) at startup dedicated to responding to probes (similar to ping in IP networks). This destination is derived from it's transport identity, the primary Reticulum identity used by the transport instance (this is the hash you see in Transport Instance <...> running). But that's an identity hash - nothing more! It is not in itself addressable in any way. You can think of it as a top-level, verifiable cryptographic identity; not addressable in itself, but it can be used to create any number of destinations (addressable endpoints).

In Reticulum, all "addresses" (destinations) are managed by the application that created them, making them much more functional, portable and secure.

[HansNilovitsch]

Thank you for your reply. I think i have some more Questions and hope you can answer these too.
I somehow thought, that Reticulum is able to "replace" packet transport with tcp/ip. Destinations within the network could be addressed between devices (directly) or via node (i think related to a "classic" network) and that the analyzed network traffic is kind of obfuscated. Also, that it is capable of resolving the technically and functionally necessary use of IP addresses (in plain text) for routing. I also assumed that for my testing purposes, no application is required to access destinations or devices or to initiate data transfers (rnprobe, rncp...). Maybe I did not fully comprehend to what extent anonymity (outwardly) is given when looking at the network traffic, especially the persistent header information.

Thank you much for your help.

[skyguy]

In Reticulum, the Destinations are similar to socket endpoints under TCP/IP - the devices on which the Destinations are located are not important as the routing takes place based on Announcements of the Destinations.
In Reticulum, you can't 'ping' a device, you can only probe a Destination, so an application is required to create the Destination and be listening for Link Requests.

-Kevin