rns.recipes

I want to share something I did to the network here, that might be of use for network operators, that have multiple LoRa/TCP stationary nodes, operating under a common Backbone TCP Interface, like I have in Sofia.
I want to thank Nick for his great propagation simulator, that I used to present this to you, albeit the graphics are additionally edited.
To explain I have used a setup of one Backbone node, working as a discoverable gateway (aka the server on my desk), connected to the big outside world, and two transport enabled aethernodes, placed up and high, each having a boundary interface, facing the server. This way, because of the announce propagation rules, the flood of announces coming from all over the world will not bog down the slow (in my case 1.35kBps) LoRa network. Of course path resolution works just fine. Mobile nodes are actually in full mode,but this is not relevant to the main question.

All is fine and dandy with this setup and I recommend it to anyone, who actually builds a community network. Except one thing...

With fewer aethernodes placed far apart, that do not hear each other over the air, and have not meshed over radio, the only path for announce propagation is trough the server. But because aethernodes are set up with Boundary mode facing the server, any announce, that comes form another one of the stationary nodes, will not get retransmitted by the one, that receives it, leaving the network kinda segmented. I really want people from far parts of the city to be able to hear eachother's announces, because for me this kinda socially stitches the network together, especially with lower number of those stationary aethernodes in it. I also want to lower the airtime as much as possible, especially in the beginning.
After consulting Mark and Nick, i decided to try something new, and create an additional bridge, between each aethernode in the network, that would pass announces freely, and I chose the Internal Interface mode. Here we go, drawing begins...

I set new routing rules in the routers and opened the aethernodes for port 4243, the next in line for the throne. Than I set up the Internal Backbone interfaces on each aethernode. I will give just Sofia 1 and Sofia 2 as examples for simplicity, but adding more is pretty straightforward. The first one is a listener, that listens on the local IP of the node. Mine are 192.168.0.5 (sofia1), 192.168.0.6 (sofia2), 192.168.0.7 (sofia3) and so on for different aethernodes. And the second one is the interface, that points to the neighbouring aethernode's listener.

I restarted RNS on both nodes and voila! They have successfully connected Internal-ly. :)

Sofia4 is being set up now, and I don't have an IP yet, but better be ready in advance. And now, when I have added all existing aethernodes to say, sofia2 config, the Internal group looks like this:
[[Backbone sofia2]]
type = BackboneInterface
enabled = Yes
mode = internal
listen_on = 192.168.0.6
port = 4243
[[sofia1 Backbone]]
type = BackboneInterface
enabled = yes
mode = internal
target_host = 193.193.182.147 (same as the server, behind same router)
target_port = 4243
[[sofia3 Backbone]]
type = BackboneInterface
enabled = yes
mode = internal
target_host = Sofia3 IP
target_port = 4243
[[sofia4 Backbone]]
type = BackboneInterface
enabled = no
mode = internal
target_host =
target_port = 4243
And you can see the result of an rnstatus:

And now any announce, received on any aethernode LoRa interface will be propagated over the city by the other aethernodes. :)
Cheers!
Bill

Thank you for sharing. You could have also created a second interface on rns.sofia in internal mode I think? Then you would not need to have every connection in every node. But its more decentralized or more meshed this way of course. Nickies simulator is great, but for more complex scenarios zeniths reticulated is even better :) Dont know if its already updated for internal mode though. https://github.com/RFnexus/reticulated

Anonymous wrote:

Thank you for sharing. You could have also created a second interface on rns.sofia in internal mode I think? Then you would not need to have every connection in every node. But its more decentralized or more meshed this way of course. Nickies simulator is great, but for more complex scenarios zeniths reticulated is even better :) Dont know if its already updated for internal mode though. https://github.com/RFnexus/reticulated

Adding an interface to any aethernode, that faces rns.sofia in Internal mode, will negate the whole idea and will allow the flood of announces on the LoRa side. This is why all interfaces facing it are Boundary. Thanks for the link, I know this one too. :) I just needed an example, Nick's is browser based and there is no need to install anything.

No, I meant, create a second backbone listener on rns.sofia in internal mode that lora nodes can connect to even in full mode. I actually just solved this issue myself this way. It was a bit of fiddling around but I think it worked:

If you have a single rnsd process running (you could do something similar with a second instance I think) you would need to put the regular, main backbone listener (rns.sofia) in boundary mode and set recursive_prs to true so people can still request paths via it. Then you create a second backbone listener on a different port in internal mode. Announces will go through in only one direction now. And you have an "internal" network and the rest.

That means you will also have to put all your other public backbone connections to boundary mode of course. And one issue coming out of this is that discoverable interfaces will always be forced into gateway mode. I circumvented that by creating a dummy backbone listener, listening on localhost only, just for the discovery announces and removed them from the main interface. I hope it will not create issues this way, but I used it similarly before to cover my ipv4 and ipv6 interface with a single discoverable interface.

Hope it makes sense. Its an alternative route. I also put a password on the internal interface so it would not become another public interface in the long run. Maybe I should have created my own thread for this, haha. May be handy for people.

I see, possible, but sounds a lot more convoluted to me, than just bridging the nodes internally. And, after all, it's up to ones abilities to grasp all possible implications. I grasp my setup, but not yours. :D Anyway, do create a thread, maybe Mark might have something to say about your way, maybe it is better than mine in some way I don't see. It is very important to network operators to share this type of information.

Its basically a star topoly, so the central nodes config is more complex, but the outer nodes need only one backbone connection to function. While you created a mesh where every node needs to keep track of each other. So different advantages on both sides. But yes, I will probably create a thread with my setup in a bit more detail :)

Yep, and this sounds a lot more reasonable to me. After all the server is open to the world and any problems, that might occur with it, including it going down for some reason, will not disrupt the network as a whole. Yes, some services will go down with it, like TCP If and Prop node, but all else will continue to function for all users seamlessly.
Please do! It will be nice to see your RNS Config files.
Have a good one!
Bill

Hey Bill, thanks very much this is great and as you know and have helped I am starting to build and deploy infrastructure in my area. One question I had was on whether or where to use network identity.Obviously all the nodes could have the she network identity but I'm not sure the advantage or disadvantage. I'm sure I have missed something in the docs so will check there too.

How are you connecting up faraway nodes using TCP? Just a case of getting Ethernet or WiFi or something from the property owner?

Sofia 2,3 are hosted by close people. At 2 i use their internet, at 3 i pay the internet and my friend uses it for free for hosting the node. Sofia 4 will be hosted at a ham radio club, i will pay the internet also there and like with 3 i will own the router.