# Discoverable interfaces - working around limitations

_Build Guides · started by jrrz.n on Fri, Oct 2, 2026 8:40 AM_

---

## Original post

**jrrz.n** · Fri, Oct 2, 2026 8:40 AM

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
```

---

## Reply 1

**jrrz.n** · Fri, Oct 2, 2026 8:45 AM

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
```

---

## Reply 2

**jrrz** · Fri, Oct 2, 2026 8:55 AM

(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 :)

---

## Reply 3

**Zenith** · Fri, Oct 2, 2026 9:15 AM

**jrrz** wrote:
> (nomadnet connection keeps failing)

Fixed now, should be back online

---

## Reply 4

**Fox** · Sun, Oct 4, 2026 3:18 AM

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

---