rns.recipes

In case I'm way off the mark, what I'm actually trying to do is accept announcements from Lora access points from a central server that has a Lora interface itself. According to this chart https://reticulum.network/manual/understanding.html#announce-propagation-rules boundary interfaces can propagate announcements from access points to the rest of the network while access point to access points never propagate any announcements and thus a lora only transport node would be completely invisible to the rest of the network, which is not what I want.

However just plainly changing the rnode settings in ~/.reticulum/config and restarting rnsd doesn't actually change anything and the Rnode stays as an access point. So I'm assuming this isn't possible, maybe intentionally. In that case, where did I go wrong with my logic.

Here's the config (with the discovery information cut off) in case it's just me being stupid here.

[[Rnode]]
  type = RnodeInterface
  enabled = yes
  port = /dev/ttyACM0
  mode = boundary

  frequency = 869525000
  bandwidth = 125000
  
  txpower = 28
  spreadingfactor = 10
  codingrate = 6

Also your Transport would not be invisible to the network in boundary mode. If you need a bit clearer picture of the announce prop rules, see the image below.

Zenith wrote:

Also your Transport would not be invisible to the network in boundary mode. If you need a bit clearer picture of the announce prop rules, see the image below.
[image]

When I was talking about the transport nodes being invisible I was referring to the access point nodes that are connected to my server through a lora interface, my server and it's associated Lora interface is fine because it has tons of gateway/full connections that it propagates its own interface announcements through, I'm speaking specifically of being able to re-transmit announcements from the access point transport nodes to the rest of the network through that central server by its Lora interface

Zenith wrote:

mode is an option specific to the RNS config itself, not interfaces. Add the mode underneath where you enable transport

Hm. Maybe I misunderstood something, but that doesn't sound right.
An example config from the manual where it is set differently:
https://reticulum.network/manual/interfaces.html#example-configuration
Also the section about roaming mode wouldn't make sense if it isn't handled per interface:
https://reticulum.network/manual/interfaces.html#interfaces-modes

welo wrote:

In case I'm way off the mark, what I'm actually trying to do is accept announcements from Lora access points from a central server that has a Lora interface itself. According to this chart https://reticulum.network/manual/understanding.html#announce-propagation-rules boundary interfaces can propagate announcements from access points to the rest of the network while access point to access points never propagate any announcements and thus a lora only transport node would be completely invisible to the rest of the network, which is not what I want.

However just plainly changing the rnode settings in ~/.reticulum/config and restarting rnsd doesn't actually change anything and the Rnode stays as an access point. So I'm assuming this isn't possible, maybe intentionally. In that case, where did I go wrong with my logic.

Here's the config (with the discovery information cut off) in case it's just me being stupid here.

[[Rnode]]
  type = RnodeInterface
  enabled = yes
  port = /dev/ttyACM0
  mode = boundary

  frequency = 869525000
  bandwidth = 125000
  
  txpower = 28
  spreadingfactor = 10
  codingrate = 6

How did you confirm that the Rnode stays in boundary mode? I tested it with mine and rnstatus outputs that the rnode is set to boundary correctly.
These are 2 different devices right? It's important to node that the propagation rules are only applied internally for interfaces connected directly to the same instance.
An access point interface will never send out announces to the outside world itself, it can only get announces and hand them over to other interfaces on the same 'device' which than can send them out if they are set to do so.
What you could do is set all the LoRa only nodes to gateway and the LoRa 'server' interface to access point.
That way announces from the LoRa net will make it to the wider net, but not the other way around.
You than would want to set the rest of the 'server' interfaces to something that isn't gateway or access point or play around with the new path request limit features, so your LoRa net won't be flooded with path requests.

Thats at least how I understand the announce propagation rules and stuff :D

mode is per interface. Your issue with access_point being forced is because of this:

If an interface is configured as discoverable, Reticulum will automatically force the mode gateway for server-style interfaces (like BackboneInterface and TCPServerInterface) or access_point for radio interfaces (like RNodeInterface).

Anonymous wrote:

welo wrote:
> In case I'm way off the mark, what I'm actually trying to do is accept announcements from Lora access points from a central server that has a Lora interface itself. According to this chart https://reticulum.network/manual/understanding.html#announce-propagation-rules boundary interfaces can propagate announcements from access points to the rest of the network while access point to access points never propagate any announcements and thus a lora only transport node would be completely invisible to the rest of the network, which is not what I want.
>
> However just plainly changing the rnode settings in ~/.reticulum/config and restarting rnsd doesn't actually change anything and the Rnode stays as an access point. So I'm assuming this isn't possible, maybe intentionally. In that case, where did I go wrong with my logic.
>
> Here's the config (with the discovery information cut off) in case it's just me being stupid here.
>
> > [[Rnode]] > type = RnodeInterface > enabled = yes > port = /dev/ttyACM0 > mode = boundary > > frequency = 869525000 > bandwidth = 125000 > > txpower = 28 > spreadingfactor = 10 > codingrate = 6 >

How did you confirm that the Rnode stays in boundary mode? I tested it with mine and rnstatus outputs that the rnode is set to boundary correctly.
These are 2 different devices right? It's important to node that the propagation rules are only applied internally for interfaces connected directly to the same instance.
An access point interface will never send out announces to the outside world itself, it can only get announces and hand them over to other interfaces on the same 'device' which than can send them out if they are set to do so.
What you could do is set all the LoRa only nodes to gateway and the LoRa 'server' interface to access point.
That way announces from the LoRa net will make it to the wider net, but not the other way around.
You than would want to set the rest of the 'server' interfaces to something that isn't gateway or access point or play around with the new path request limit features, so your LoRa net won't be flooded with path requests.

That's at least how I understand the announce propagation rules and stuff :D

Yea it's set to access_point because of what joakim said above. I was planning on have a backbone interface connection all on all the rnodes anyways, but I was wondering about the case if the internet failed for whatever reason that the interface would still send announcements occasionally to the network but I guess not. I do have enough Rnodes that I could technically set up an undiscoverable node as a boundary node but there's not much point to that.

Did accidentally figure out that you can set RNodeInterfaces to Gateway mode instead of only access point, so that's also a possible option. Sending a bunch of announcements through lora seems like a poor idea though (but I guess the 2% announcement limit means this is a non issue?).

It's possible, but usually not a good idea as it eats up air time. access_point is basically gateway for radio interfaces like LoRa, without announces but with path seeking.

joakim wrote:

It's possible, but usually not a good idea as it eats up air time. access_point is basically gateway for radio interfaces like LoRa, without announces but with path seeking.

A thing that one should be aware of:

Standard Rnodes won't try to discover paths on it's own interface. So something like Client -> AP -> AP -> Client won't work, since neither announces or path requests are send from AP to AP.

The microReticum firmware behaves differently thought.