RNS Logo

rns.recipes

◈ 9ce92808be498e9e05590ff27cbfdfe4
Service restored

Discoverable interfaces - working around limitations

Started by jrrz.n a45e6508a37d2108... ·

jrrz.n 9cc44d13f629718a...
edited #1

Right now in RNS 1.5.5 you can only make interfaces discoverable that are in either gateway, ap, or internal mode (depending on the interface type). This can be frustrating. For example if you set up an interface in internal mode you will need to set the rest up as boundary for the internal mode to take effect. So not discoverable? I want to share my configuration showing how to work around this issue so to spare others some work and possibly also start a discussion that may or may not shape how discoverable interfaces work in the future (thanks mark).

 

Working around the limitation is pretty straightforward actually. Lets describe the scenario:

 

Say you already have your Backbone Listeners and Backbone connections to the wider net set up. You decided to also add another interface in internal mode protected by IFAC so you can save some battery life on your mobile devices. This will of course only work if you set your other, public, backbone listeners to boundary mode, so announces wont propagate to your internal interface, which was the whole point. In addition to that you also need to enable recursive_prs so people on the public interface can still request paths through it. You now finally want to make the public listener discoverable. But as soon as do that it will be forced to gateway mode again. Oh no. You internal interface still receives and propagates all announces you receive from the global ret.

 

Now, all you need to do to make this work properly is to create a third "dummy" interface that listens on something nobody will ever connect to, like localhost. Now simply move all the discovery configurations to it instead of the actual interface you want people to find. Just make sure the reachable_on parameter is set and points to where you are actually reachable. Now the announces will reach the wider net, people can connect to it, requests paths over it, and the internal interface only propagates announces received from its own peers. Et voilà!

 

Here is a config snippet that shows what I mean:

 

  [[Backbone Listener - Dummy]]
    type = BackboneInterface
    enabled = yes
    listen_on = localhost
    port = 4242

    discoverable = yes
    discovery_name = My-public-backbone-interface
    reachable_on = 203.0.113.0
    announce_interval = 720
    discovery_stamp_value = 24
    discovery_lxmf_address = xxxxxxxxxxxxxxxxxxxxx
    latitude = 0.0
    longitude = 0.0
    height = 0

  [[Backbone Listener]]
    type = BackboneInterface
    enabled = yes
    listen_on = 203.0.113.0
    port = 4242

    mode = boundary
    # so internal interfaces work, but paths can still be requested from here
    recursive_prs = yes
    gravity = 50

  [[Backbone Listener - Internal]]
    type = BackboneInterface
    enabled = yes
    listen_on = 203.0.113.0
    port = 4343

    mode = internal
    gravity = 100

    announce_rate_target = 10800 # 3 hours
    announce_rate_grace = 3
    announce_rate_penalty = 43200 # 12 hours

    passphrase = mysecretpassphrase
jrrz.n 9cc44d13f629718a...
edited #2

There is another usecase for this even. According to my experiments backbone listeners only ever listen to either IPv4 or IPv6 addresses. That means you have to set up an interface each for every IP version. You will probably then use a domain pointing to both IP version addresses. By using the dummy interface you can separate the discovery config in a very clean way. Its mostly aesthetics though.

 

Here is my example config showcasing it:

 

  [[Backbone Listener - Dummy]]
    type = BackboneInterface
    enabled = yes
    listen_on = localhost
    port = 4242

    discoverable = yes
    discovery_name = My-public-backbone-interface
    reachable_on = domain.example
    announce_interval = 720
    discovery_stamp_value = 24
    discovery_lxmf_address = xxxxxxxxxxxxxxxxxxxxx
    latitude = 0.0
    longitude = 0.0
    height = 0

  [[Backbone Listener - 4]]
    type = BackboneInterface
    enabled = yes
    listen_on = 203.0.113.0
    port = 4242

    mode = boundary
    # so internal interfaces work, but paths can still be requested from here
    recursive_prs = yes
    gravity = 50

  [[Backbone Listener - 6]]
    type = BackboneInterface
    enabled = yes
    listen_on = 2001:DB8::
    port = 4242

    mode = boundary
    # so internal interfaces work, but paths can still be requested from here
    recursive_prs = yes
    gravity = 50

  [[Backbone Listener - Internal 4]]
    type = BackboneInterface
    enabled = yes
    listen_on = 203.0.113.0
    port = 4343

    mode = internal
    gravity = 100

    announce_rate_target = 10800 # 3 hours
    announce_rate_grace = 3
    announce_rate_penalty = 43200 # 12 hours

    passphrase = mysecretpassphrase

  [[Backbone Listener - Internal 6]]
    type = BackboneInterface
    enabled = yes
    listen_on = 2001:DB8::
    port = 4343

    mode = internal
    gravity = 100

    announce_rate_target = 10800 # 3 hours
    announce_rate_grace = 3
    announce_rate_penalty = 43200 # 12 hours

    passphrase = mysecretpassphrase
jrrz 9cc44d13f629718a...
#3

(nomadnet connection keeps failing)

 

This works well for me, but I would wish for another way to configure those things. It looks to me that the discovery config inside an actual interface is not strictly needed and also sometimes not possible. Maybe there can be some flag to make sending discovery announces possible from any interface mode, basically not forcing the interface mode? That would also make it possible to send discovery announces via internal interfaces. Although they would then propagate to the boundary interfaces as well, which is not the idea. Just thinking out loud here. Having its own discovery interface type is an idea aswell..

 

Finally, just to make things clear: I have absolutely no intentions on "pushing" some idea about how things "should" work. This is not up to me and I dont want to come across as entitled or something :)

Zenith Admin
#4

jrrz wrote:

(nomadnet connection keeps failing)

 

Fixed now, should be back online

Fox d57e4cf58b77eb7b...
#5

I wonder if this is why my gateway won't show show any more announcements on rmap.world (and why it faded out on directory.rns.recipes). I have my listen_on config value set to ::, which does work in regards to responding both on IPv6 and IPv4, but it refuses to update/re-add to both sites lists even though I have set enable_transport=yes and discoverable=yes. Granted, I also haven't figured out if it's even possible to turn on NAT Hairpinning, or unblock ports on the modem's firewall for my IPv6 address, so I might as well test announcements with listening on IPv4 only as IPv6 is unusable for my hosting anyway. If it starts showing up on the list again, that might be the issue. I had set :: so I could have the BackboneInterface listen on both addresses, but that is possibly what's breaking announcements for me

Post a Reply

Supports Markdown: **bold**, *italic*, `code`, ```code blocks```, [links](url)

Log in to upload images

Quote
Copied to clipboard