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…