Essentially, I’m the only one running Qubes in this room right now, and I am the only one who isn’t able to connect to a router that has a Reticulum transport node connected to it. I’m trying to grasp how Reticulum works, but it seems this comment on interfaces in the config file for Reticulum might be relevant: “This interface enables communication with other link-local Reticulum nodes over UDP. It does not need any functional IP infrastructure like routers or DHCP servers, but will require that at least link-local IPv6 is enabled in your operating system, which should be enabled by default in almost any OS.”
I’m not sure if link-local IPv6 is enabled in THIS operating system, never mind whether I would need to enable it in my app qube I’m using for Reticulum, or somewhere else in the system.
I haven’t played with Reticulum yet, so this is me throwing spaghetti at the wall. I’d try inserting a new firewall qube, say sys-rns, in front of the reticulum appVM and then apply the following in dom0:
After playing around with MeshChatX for awhile, I gave up on trying to get the AutoInterface and IPv6 discovery to work. Simply enabling IPv6 in sys-net was not sufficient, but with the following setup LXMF messaging just worked (without IPv6)!
In a nutshell:
employ the following script in sys-net, but set port=4242 (borrowing from localsend setup)
add the following policy: qubes.ConnectTCP +4242 sys-net @default allow target=appVM
appVM with rns installed (comes bundled with MeshChatX)
set appVM network to none (not needed with qvm-connect-tcp)
in rns (MeshChatX) create a TCP Server interface listening to 127.0.0.1:4242
I tested with the Columba app on a Graphene phone over LAN. Since there is no discovery option, I had to manually enter the following:
custom TCP Client interface
Target Host = sys-net (wlan) IP and Target Port = 4242
At this point I’d just consider this proof of concept, not necessarily the ideal Reticulum setup on Qubes…
The following sounds promising wrt the possibility of building a discoverability mechanism for Reticulum instances behind Qubes’ NAT layers:
“Dynamic Resolution: This option also accepts a path to an external executable script or binary. If a path is provided, Reticulum will execute the script and use its stdout as the reachability address. This is useful for devices behind dynamic DNS, NATs, or complex cloud environments where the external IP is not known locally. The script must simply print the address to stdout and exit.”
As noted above, qvm-features allows for enabling link-local IPv6. However, since Qubes employs NATv6, the following requirement also applies (source: reticulum.network):
“If you are connected to the Internet with IPv6, and your provider will route IPv6 multicast, you can potentially configure the Auto Interface to globally autodiscover other Reticulum nodes within your selected Group ID. You can specify the discovery scope by setting it to one of link, admin, site, organisation or global.” (emphasis added)
Even with qvm-features sys-net ipv6 1 and RNS discovery scope set to site, IPv6 multicast traffic is not routed to the Reticulum enabled appVM. Looking at the configuration, after enabling IPv6, one finds the following:
Which clarifies that, while IPv6 unicast packets are forwarded, IPv6 multicast packets are dropped. I believe this is the reason discovery on the Reticulum Auto Interface fails and will require a more involved solution (similar to LocalSend and Samba posts in the forum). Fortunately Reticulum is designed to work across a variety of network topologies, so the lack of multicast forwarding is likely not prohibitive.