<spanid="interfaces-main"></span><h1>Configuring Interfaces<aclass="headerlink"href="#configuring-interfaces"title="Link to this heading">¶</a></h1>
<p>Reticulum supports using many kinds of devices as networking interfaces, and
allows you to mix and match them in any way you choose. The number of distinct
network topologies you can create with Reticulum is more or less endless, but
common to them all is that you will need to define one or more <em>interfaces</em>
for Reticulum to use.</p>
<p>The following sections describe the interfaces currently available in Reticulum,
and gives example configurations for the respective interface types.</p>
<p>For a high-level overview of how networks can be formed over different interface
types, have a look at the <aclass="reference internal"href="networks.html#networks-main"><spanclass="std std-ref">Building Networks</span></a> chapter of this
manual.</p>
<sectionid="custom-interfaces">
<spanid="interfaces-custom"></span><h2>Custom Interfaces<aclass="headerlink"href="#custom-interfaces"title="Link to this heading">¶</a></h2>
<p>In addition to the built-in interface types, Reticulum is <strong>fully extensible</strong> with
custom, user- or community-supplied interfaces, and creating custom interface
modules is straightforward. Please see the <aclass="reference internal"href="examples.html#example-custominterface"><spanclass="std std-ref">custom interface</span></a>
example for basic interface code to build upon.</p>
</section>
<sectionid="auto-interface">
<spanid="interfaces-auto"></span><h2>Auto Interface<aclass="headerlink"href="#auto-interface"title="Link to this heading">¶</a></h2>
<p>The <codeclass="docutils literal notranslate"><spanclass="pre">AutoInterface</span></code> enables communication with other discoverable Reticulum
nodes over any kind of local Ethernet or WiFi-based medium. Even though it uses IPv6 for peer
discovery, and UDP for packet transport, it <strong>does not</strong> need any functional IP
infrastructure like routers or DHCP servers, on your physical network.</p>
<divclass="admonition warning">
<pclass="admonition-title">Warning</p>
<p>If you have <strong>firewall</strong> software running on your computer, it may block traffic
required for <codeclass="docutils literal notranslate"><spanclass="pre">AutoInterface</span></code> to work. If this is the case, you will have to
allow UDP traffic on port <codeclass="docutils literal notranslate"><spanclass="pre">29716</span></code> and <codeclass="docutils literal notranslate"><spanclass="pre">42671</span></code>.</p>
</div>
<p>As long as there is at least some sort of switching medium present between peers (a
wired switch, a hub, a WiFi access point or similar, or simply two devices connected
directly by Ethernet cable), it will work without any configuration, setup or intermediary devices.</p>
<p>For <codeclass="docutils literal notranslate"><spanclass="pre">AutoInterface</span></code> peer discovery to work, it’s also required that link-local
IPv6 support is available on your system, which it should be by default in all
current operating systems, both desktop and mobile.</p>
<divclass="admonition note">
<pclass="admonition-title">Note</p>
<p>Almost all current Ethernet and WiFi hardware will work without any kind
of configuration or setup with <codeclass="docutils literal notranslate"><spanclass="pre">AutoInterface</span></code>, but a small subset of
devices turn on options that limit device-to-device communication by default,
resulting in <codeclass="docutils literal notranslate"><spanclass="pre">AutoInterface</span></code> peer discovery being blocked. This issue is
most commonly seen on very cheap, ISP-supplied WiFi routers, and can sometimes
be turned off in the router configuration.</p>
</div>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># This example demonstrates a bare-minimum setup</span>
<spanclass="c1"># of an Auto Interface. It will allow communica-</span>
<spanclass="c1"># tion with all other reachable devices on all</span>
<p>If you are connected to the Internet with IPv6, and your provider will route
IPv6 multicast, you can potentially configure the Auto Interface to globally
autodiscover other Reticulum nodes within your selected Group ID. You can specify
the discovery scope by setting it to one of <codeclass="docutils literal notranslate"><spanclass="pre">link</span></code>, <codeclass="docutils literal notranslate"><spanclass="pre">admin</span></code>, <codeclass="docutils literal notranslate"><spanclass="pre">site</span></code>,
<codeclass="docutils literal notranslate"><spanclass="pre">organisation</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">global</span></code>.</p>
<spanid="interfaces-backbone"></span><h2>Backbone Interface<aclass="headerlink"href="#backbone-interface"title="Link to this heading">¶</a></h2>
<p>The Backbone interface is a very fast and resource efficient interface type, primarily
intended for interconnecting Reticulum instances over many different types of mediums.
It uses a kernel-event I/O backend, and can handle thousands of interfaces and/or clients
with relatively low system resource utilisation. <strong>This interface type is currently only
supported on Linux and Android</strong>.</p>
<divclass="admonition note">
<pclass="admonition-title">Note</p>
<p>The Backbone Interface is fully compatible with the <codeclass="docutils literal notranslate"><spanclass="pre">TCPServerInterface</span></code> and <codeclass="docutils literal notranslate"><spanclass="pre">TCPClientInterface</span></code>
types, and they can be used interchangably, and cross-connect with each other. On systems that support
<codeclass="docutils literal notranslate"><spanclass="pre">BackboneInterface</span></code>, it is generally recommended to use it, unless you need specific options or
features that the TCP server and client interfaces provide.</p>
</div>
<p>While the goal is to support <em>all</em> socket types and I/O devices provided by the underlying
operating system, the initial release only provides support for TCP connections over IPv4
and IPv6.</p>
<p>For all types of connections over a <codeclass="docutils literal notranslate"><spanclass="pre">BackboneInterface</span></code>, Reticulum will gracefully
handle intermittency, link loss, and connections that come and go.</p>
<sectionid="listeners">
<h3>Listeners<aclass="headerlink"href="#listeners"title="Link to this heading">¶</a></h3>
<p>The following examples illustrates various ways to set up <codeclass="docutils literal notranslate"><spanclass="pre">BackboneInterface</span></code> listeners.</p>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># This example demonstrates a backbone interface</span>
<spanclass="c1"># that listens for incoming connections on the</span>
<spanclass="c1"># specified IP address and port number.</span>
<p>To use the <codeclass="docutils literal notranslate"><spanclass="pre">BackboneInterface</span></code> over <aclass="reference external"href="https://yggdrasil-network.github.io/">Yggdrasil</a>, you
can simply specify the Yggdrasil <codeclass="docutils literal notranslate"><spanclass="pre">tun</span></code> device and a listening port, like so:</p>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># This example demonstrates a backbone interface</span>
<spanclass="c1"># listening for connections over Yggdrasil.</span>
<h3>Connecting Remotes<aclass="headerlink"href="#connecting-remotes"title="Link to this heading">¶</a></h3>
<p>The following examples illustrates various ways to connect to remote <codeclass="docutils literal notranslate"><spanclass="pre">BackboneInterface</span></code> listeners.
As noted above, <codeclass="docutils literal notranslate"><spanclass="pre">BackboneInterface</span></code> interfaces can also connect to remote <codeclass="docutils literal notranslate"><spanclass="pre">TCPServerInterface</span></code>,
and as such these interface types can be used interchangably.</p>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># Here's an example of a backbone interface that</span>
<spanclass="c1"># connects to a remote listener.</span>
<spanid="interfaces-tcps"></span><h2>TCP Server Interface<aclass="headerlink"href="#tcp-server-interface"title="Link to this heading">¶</a></h2>
<p>The TCP Server interface is suitable for allowing other peers to connect over
the Internet or private IPv4 and IPv6 networks. When a TCP server interface has been
configured, other Reticulum peers can connect to it with a TCP Client interface.</p>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># This example demonstrates a TCP server interface.</span>
<spanclass="c1"># It will listen for incoming connections on all IP</span>
<p>If you are using the interface on a device which has both IPv4 and IPv6 addresses available,
you can use the <codeclass="docutils literal notranslate"><spanclass="pre">prefer_ipv6</span></code> option to bind to the IPv6 address:</p>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># This example demonstrates a TCP server interface.</span>
<spanclass="c1"># It will listen for incoming connections on the</span>
<spanclass="c1"># specified IP address and port number.</span>
<p>To use the TCP Server Interface over <aclass="reference external"href="https://yggdrasil-network.github.io/">Yggdrasil</a>, you
can simply specify the Yggdrasil <codeclass="docutils literal notranslate"><spanclass="pre">tun</span></code> device and a listening port, like so:</p>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="k">[[Yggdrasil TCP Server Interface]]</span>
<p>In almost all cases, it is easier to use the dedicated <codeclass="docutils literal notranslate"><spanclass="pre">I2PInterface</span></code>, but for complete
control, and using I2P routers running on external systems, this option also exists.</p>
</section>
<sectionid="tcp-client-interface">
<spanid="interfaces-tcpc"></span><h2>TCP Client Interface<aclass="headerlink"href="#tcp-client-interface"title="Link to this heading">¶</a></h2>
<p>To connect to a TCP server interface, you can use the TCP client
interface. Many TCP Client interfaces from different peers can connect to the
same TCP Server interface at the same time.</p>
<p>The TCP interface types can also tolerate intermittency in the IP link layer.
This means that Reticulum will gracefully handle IP links that go up and down,
and restore connectivity after a failure, once the other end of a TCP interface reappears.</p>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># Here's an example of a TCP Client interface. The</span>
<spanclass="c1"># target_host can be a hostname or an IPv4 or IPv6 address.</span>
<p>It is also possible to use this interface type to connect via other programs
or hardware devices that expose a KISS interface on a TCP port, for example
software-based soundmodems. To do this, use the <codeclass="docutils literal notranslate"><spanclass="pre">kiss_framing</span></code> option:</p>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># Here's an example of a TCP Client interface that connects</span>
<spanclass="c1"># to a software TNC soundmodem on a KISS over TCP port.</span>
<p><strong>Caution!</strong> Only use the KISS framing option when connecting to external devices
and programs like soundmodems and similar over TCP. When using the
<codeclass="docutils literal notranslate"><spanclass="pre">TCPClientInterface</span></code> in conjunction with the <codeclass="docutils literal notranslate"><spanclass="pre">TCPServerInterface</span></code> you should
never enable <codeclass="docutils literal notranslate"><spanclass="pre">kiss_framing</span></code>, since this will disable internal reliability and
recovery mechanisms that greatly improves performance over unreliable and
intermittent TCP links.</p>
<p>For KISS devices that need only supports a particular MTU, you can use the
<p>It can take anywhere from a few seconds to a few minutes to establish
I2P connections to the desired peers, so Reticulum handles the process
in the background, and will output relevant events to the log.</p>
<divclass="admonition note">
<pclass="admonition-title">Note</p>
<p>While the I2P interface is the simplest way to use
Reticulum over I2P, it is also possible to tunnel the TCP server and
client interfaces over I2P manually. This can be useful in situations
where more control is needed, but requires manual tunnel setup through
the I2P daemon configuration.</p>
</div>
<p>It is important to note that the two methods are <em>interchangably compatible</em>.
You can use the I2PInterface to connect to a TCPServerInterface that
was manually tunneled over I2P, for example. This offers a high degree
of flexibility in network setup, while retaining ease of use in simpler
use-cases.</p>
</section>
<sectionid="rnode-lora-interface">
<spanid="interfaces-rnode"></span><h2>RNode LoRa Interface<aclass="headerlink"href="#rnode-lora-interface"title="Link to this heading">¶</a></h2>
<p>To use Reticulum over LoRa, the <aclass="reference external"href="https://unsigned.io/rnode/">RNode</a> interface
can be used, and offers full control over LoRa parameters.</p>
<divclass="admonition warning">
<pclass="admonition-title">Warning</p>
<p>Radio frequency spectrum is a legally controlled resource, and legislation
varies widely around the world. It is your responsibility to be aware of any
relevant regulation for your location, and to make decisions accordingly.</p>
</div>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># Here's an example of how to add a LoRa interface</span>
<spanclass="c1"># using the RNode LoRa transceiver.</span>
<spanid="interfaces-rnode-multi"></span><h2>RNode Multi Interface<aclass="headerlink"href="#rnode-multi-interface"title="Link to this heading">¶</a></h2>
<p>For RNodes that support multiple LoRa transceivers, the RNode
Multi interface can be used to configure sub-interfaces individually.</p>
<divclass="admonition warning">
<pclass="admonition-title">Warning</p>
<p>Radio frequency spectrum is a legally controlled resource, and legislation
varies widely around the world. It is your responsibility to be aware of any
relevant regulation for your location, and to make decisions accordingly.</p>
</div>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="c1"># Here's an example of how to add an RNode Multi interface</span>
<spanclass="c1"># using the RNode LoRa transceiver.</span>
<p>Reticulum will write all packets to <cite>stdin</cite> of the <codeclass="docutils literal notranslate"><spanclass="pre">command</span></code> option, and will
continuously read and scan its <cite>stdout</cite> for Reticulum packets. If <codeclass="docutils literal notranslate"><spanclass="pre">EOF</span></code> is reached,
Reticulum will try to respawn the program after waiting for <codeclass="docutils literal notranslate"><spanclass="pre">respawn_interval</span></code> seconds.</p>
</section>
<sectionid="kiss-interface">
<spanid="interfaces-kiss"></span><h2>KISS Interface<aclass="headerlink"href="#kiss-interface"title="Link to this heading">¶</a></h2>
<p>With the KISS interface, you can use Reticulum over a variety of packet
radio modems and TNCs, including <aclass="reference external"href="https://unsigned.io/openmodem/">OpenModem</a>.
KISS interfaces can also be configured to periodically send out beacons
for station identification purposes.</p>
<divclass="admonition warning">
<pclass="admonition-title">Warning</p>
<p>Radio frequency spectrum is a legally controlled resource, and legislation
varies widely around the world. It is your responsibility to be aware of any
relevant regulation for your location, and to make decisions accordingly.</p>
</div>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="k">[[Packet Radio KISS Interface]]</span>
<spanid="interfaces-discoverable"></span><h2>Discoverable Interfaces<aclass="headerlink"href="#discoverable-interfaces"title="Link to this heading">¶</a></h2>
<p>Reticulum includes a powerful system for publishing your local interfaces to the wider network, allowing other peers to <aclass="reference internal"href="using.html#using-interface-discovery"><spanclass="std std-ref">discover, validate, and automatically connect to them</span></a>. This feature is particularly useful for creating decentralized networks where peers can dynamically find entrypoints, such as public Internet gateways or local radio access points, without relying on static configuration files or centralized directories.</p>
<p>When an interface is made <strong>discoverable</strong>, your Reticulum instance will periodically broadcast an announce packet containing the connection details and parameters required for other peers to establish a connection. These announces are propagated over the network using the standard Reticulum announce mechanism using the <codeclass="docutils literal notranslate"><spanclass="pre">rnstransport.discovery.interface</span></code> destination type.</p>
<divclass="admonition note">
<pclass="admonition-title">Note</p>
<p>To use the interface discovery functionality, the <codeclass="docutils literal notranslate"><spanclass="pre">LXMF</span></code> module must be installed in your Python environment. You can install it using pip:</p>
<h3>Enabling Discovery<aclass="headerlink"href="#enabling-discovery"title="Link to this heading">¶</a></h3>
<p>Interface discovery is enabled on a per-interface basis. To make a specific interface discoverable, you must add the <codeclass="docutils literal notranslate"><spanclass="pre">discoverable</span></code> option to that interface’s configuration block and set it to <codeclass="docutils literal notranslate"><spanclass="pre">yes</span></code>.</p>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="k">[[My Public Gateway]]</span>
<p>Once enabled, Reticulum will automatically handle the generation, signing, stamping, and broadcasting of the discovery announces. It is not <em>required</em> to enable Transport to publish interface discovery information, but for most use cases where you want others to connect to you, you will likely want <codeclass="docutils literal notranslate"><spanclass="pre">enable_transport</span></code> set to <codeclass="docutils literal notranslate"><spanclass="pre">yes</span></code> in the <codeclass="docutils literal notranslate"><spanclass="pre">[reticulum]</span></code> section of your configuration.</p>
</section>
<sectionid="discovery-parameters">
<h3>Discovery Parameters<aclass="headerlink"href="#discovery-parameters"title="Link to this heading">¶</a></h3>
<p>When <codeclass="docutils literal notranslate"><spanclass="pre">discoverable</span></code> is enabled, a variety of additional options become available to control how the interface is presented to the network. These parameters allow you to fine-tune the metadata, security requirements, and visibility of your interface.</p>
<p><strong>Basic Metadata</strong></p>
<dlclass="simple">
<dt><codeclass="docutils literal notranslate"><spanclass="pre">discovery_name</span></code></dt><dd><p>A human-readable name for the interface. This name will be displayed to users on remote systems when they list discovered interfaces. If not specified, the interface name (the section header) will be used.</p>
</dd>
<dt><codeclass="docutils literal notranslate"><spanclass="pre">announce_interval</span></code></dt><dd><p>The interval in minutes between successive discovery announces for this interface. Default is 360 minutes (6 hours). For stable, long-running infrastructure, higher intervals (12 to 22 hours) are usually sufficient and reduce network load. Minimum allowed value is 5 minutes (but expect to have your announces throttled if using intervals below one hour).</p>
<dt><codeclass="docutils literal notranslate"><spanclass="pre">reachable_on</span></code></dt><dd><p>Specifies the address that remote peers should use to connect to this interface.</p>
<ulclass="simple">
<li><p>For TCP and Backbone interfaces, this is typically the public IP address or hostname. Do not include the port, this is fetched automatically from the interface.</p></li>
<li><p>For I2P interfaces, this is usually the I2P <codeclass="docutils literal notranslate"><spanclass="pre">b32</span></code> address. This value is fetched automatically from the <codeclass="docutils literal notranslate"><spanclass="pre">I2PInterface</span></code> once it is up and connected to the I2P network, so you should not set this manually, unless you absolutely know what you’re doing.</p></li>
</ul>
<p><strong>Dynamic Resolution:</strong> This option also accepts a path to an external executable script or binary. If a path is provided, Reticulum will execute the script and use its <codeclass="docutils literal notranslate"><spanclass="pre">stdout</span></code> as the reachability address. This is useful for devices behind dynamic DNS, NATs, or complex cloud environments where the external IP is not known locally. The script must simply print the address to stdout and exit.</p>
</dd>
</dl>
<divclass="admonition note">
<pclass="admonition-title">Note</p>
<p>When using an executable script for <codeclass="docutils literal notranslate"><spanclass="pre">reachable_on</span></code>, Reticulum expects the script to output only the IP address or hostname to <codeclass="docutils literal notranslate"><spanclass="pre">stdout</span></code>, followed by a newline character. Any additional output or errors may cause the resolution to fail. Ensure the script has executable permissions and is robust against temporary network failures.</p>
</div>
<p>A minimal example of a script that resolves the externally available, public IP of an internet-connected system could look like this:</p>
<p>On a real system, you should make the script robust enough to deal with intermittent Internet or service failures, such that the script <em>always</em> returns a sensible value, or if not possible at least exits with a non-zero exit return code, so Reticulum knows the output is invalid.</p>
<p><strong>Security & Cost</strong></p>
<dlclass="simple">
<dt><codeclass="docutils literal notranslate"><spanclass="pre">discovery_stamp_value</span></code></dt><dd><p>Defines the proof-of-work difficulty for the cryptographic stamp included in the announce. This value acts as a cost barrier to prevent network flooding. The default value is <codeclass="docutils literal notranslate"><spanclass="pre">14</span></code>. Increasing this value makes it computationally more expensive to generate an announce, which can be useful to prevent spam on very large networks, but it also increases CPU load on your system when generating announces. Stamps are cached, and only generated if interface information changes, or at instance restart. If you have the computational resources, it is generally advisable to use as high a stamp value as possible.</p>
</dd>
</dl>
<p><strong>Privacy & Encryption</strong></p>
<dlclass="simple">
<dt><codeclass="docutils literal notranslate"><spanclass="pre">discovery_encrypt</span></code></dt><dd><p>If set to <codeclass="docutils literal notranslate"><spanclass="pre">yes</span></code>, the discovery announce payload will be encrypted. To decrypt the announce, remote peers must possess the <em>network identity</em> configured for your instance (see <codeclass="docutils literal notranslate"><spanclass="pre">network_identity</span></code> in the <codeclass="docutils literal notranslate"><spanclass="pre">[reticulum]</span></code> section). This allows you to publish private interfaces that are only discoverable to specific trusted networks.</p>
</dd>
</dl>
<divclass="admonition important">
<pclass="admonition-title">Important</p>
<p>If you enable <codeclass="docutils literal notranslate"><spanclass="pre">discovery_encrypt</span></code> but do not configure a valid <codeclass="docutils literal notranslate"><spanclass="pre">network_identity</span></code> in the <codeclass="docutils literal notranslate"><spanclass="pre">[reticulum]</span></code> section of your configuration, Reticulum will abort the interface discovery announce. Encryption requires a valid network identity key to function.</p>
</div>
<dlclass="simple">
<dt><codeclass="docutils literal notranslate"><spanclass="pre">publish_ifac</span></code></dt><dd><p>If set to <codeclass="docutils literal notranslate"><spanclass="pre">yes</span></code>, the Interface Access Code (IFAC) name and passphrase for this interface will be included in the discovery announce. This allows peers to automatically configure the correct authentication parameters when connecting to the interface.</p>
<dt><codeclass="docutils literal notranslate"><spanclass="pre">latitude</span></code>, <codeclass="docutils literal notranslate"><spanclass="pre">longitude</span></code>, <codeclass="docutils literal notranslate"><spanclass="pre">height</span></code></dt><dd><p>Optional physical coordinates for the interface. These are useful for mapping discovered interfaces geographically or for clients to automatically select the nearest access point. Coordinates should be in decimal degrees, height in meters above mean sea level.</p>
</dd>
<dt><codeclass="docutils literal notranslate"><spanclass="pre">location_cmd</span></code></dt><dd><p>Optional path to executable or script that returns the physical coordinates for the interface. This can be used instead of manually setting <codeclass="docutils literal notranslate"><spanclass="pre">latitude</span></code>, <codeclass="docutils literal notranslate"><spanclass="pre">longitude</span></code> and <codeclass="docutils literal notranslate"><spanclass="pre">height</span></code>. Reticulum expects the script to output the location data to <codeclass="docutils literal notranslate"><spanclass="pre">stdout</span></code> on a single line, separated by commas, with values as floating point numbers in the format <codeclass="docutils literal notranslate"><spanclass="pre">LAT,</span><spanclass="pre">LON,</span><spanclass="pre">HEIGHT</span></code>. Coordinates should be in decimal degrees, height in meters above mean sea level.</p>
<p>The height value for interface discovery is specified in <em>height above mean sea level</em>! This is the geoid-corrected height value, and is distinct from GPS altitude. If you manually specify height, it will typically be set to what you find on a topographical map. If you are using a script to output the location data, make sure that you are using the geoid-corrected altitude, not height above the GPS ellipsoid. Most GPS systems will make both figures available.</p>
<p>For physical radio interfaces like <codeclass="docutils literal notranslate"><spanclass="pre">RNodeInterface</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">KISSInterface</span></code>, the following optional parameters allow you to broadcast the operating frequency and characteristics, allowing clients to verify compatibility before connecting:</p>
<dlclass="simple">
<dt><codeclass="docutils literal notranslate"><spanclass="pre">discovery_frequency</span></code></dt><dd><p>The operating frequency in Hz. Auto-configured on RNode interfaces. Necessary on KISS-based radio interfaces and <codeclass="docutils literal notranslate"><spanclass="pre">TCPClientInterfaces</span></code> connecting to radio modems.</p>
</dd>
<dt><codeclass="docutils literal notranslate"><spanclass="pre">discovery_bandwidth</span></code></dt><dd><p>The signal bandwidth in Hz. Auto-configured on RNode interfaces. Useful on KISS-based radio interfaces and <codeclass="docutils literal notranslate"><spanclass="pre">TCPClientInterfaces</span></code> connecting to radio modems.</p>
</dd>
<dt><codeclass="docutils literal notranslate"><spanclass="pre">discovery_modulation</span></code></dt><dd><p>The modulation type or scheme. Auto-configured on RNode interfaces, but highly advisable to include on other radio-based interfaces.</p>
</dd>
</dl>
</section>
<sectionid="interface-modes">
<h3>Interface Modes<aclass="headerlink"href="#interface-modes"title="Link to this heading">¶</a></h3>
<p>When you enable discovery on an interface, Reticulum enforces certain interface modes to ensure the interface is actually useful for remote peers.</p>
<p>If an interface is configured as <codeclass="docutils literal notranslate"><spanclass="pre">discoverable</span></code>, but its mode is not explicitly set to <codeclass="docutils literal notranslate"><spanclass="pre">gateway</span></code> (for server-style interfaces like <codeclass="docutils literal notranslate"><spanclass="pre">BackboneInterface</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">TCPServerInterface</span></code>) or <codeclass="docutils literal notranslate"><spanclass="pre">access_point</span></code> (for radio interfaces like <codeclass="docutils literal notranslate"><spanclass="pre">RNodeInterface</span></code>), Reticulum will automatically configure the appropriate mode and log a notice.</p>
<p>For example, if you enable discovery on a <codeclass="docutils literal notranslate"><spanclass="pre">RNodeInterface</span></code> without specifying the mode, Reticulum will automatically set it to <codeclass="docutils literal notranslate"><spanclass="pre">access_point</span></code> mode.</p>
</section>
<sectionid="security-considerations">
<h3>Security Considerations<aclass="headerlink"href="#security-considerations"title="Link to this heading">¶</a></h3>
<p>When making interfaces discoverable, you are effectively broadcasting an invitation to connect to your system. It is important to understand the security implications of the configuration options you choose.</p>
<p><strong>Publishing Credentials</strong></p>
<p>If you enable <codeclass="docutils literal notranslate"><spanclass="pre">publish_ifac</span><spanclass="pre">=</span><spanclass="pre">yes</span></code>, your interface’s authentication passphrase will be included in the announce. If you are operating a public network and want anyone to connect, this is acceptable. However, if you wish to restrict access to a specific group of users, you <strong>must</strong> enable <codeclass="docutils literal notranslate"><spanclass="pre">discovery_encrypt</span><spanclass="pre">=</span><spanclass="pre">yes</span></code>. This ensures that only peers possessing the correct <codeclass="docutils literal notranslate"><spanclass="pre">network_identity</span></code> can decode the passphrase.</p>
<p><strong>Topology Exposure</strong></p>
<p>A discoverable interface announces its presence, location (if configured), and capabilities to the network. Even if the connection details are encrypted, the <em>fact</em> that a connectable node exists within a certain network becomes public information. In high-security or scenarios requiring operational secrecy, consider the implications of advertising your infrastructure’s existence.</p>
</section>
<sectionid="example-configuration">
<h3>Example Configuration<aclass="headerlink"href="#example-configuration"title="Link to this heading">¶</a></h3>
<p>Below is an example configuration for a public backbone gateway. This configuration publishes a high-value, publicly discoverable interface, that anyone can connect to.</p>
<divclass="highlight-ini notranslate"><divclass="highlight"><pre><span></span><spanclass="k">[[My Public Gateway]]</span>
<spanclass="w"></span><spanclass="na">discovery_name</span><spanclass="w"></span><spanclass="o">=</span><spanclass="w"></span><spanclass="s">Region A Public Entrypoint</span>
<p>The next example create an encrypted discovery-enabled interface, requiring a specific network identity to decode, and includes IFAC credentials for seamless authentication.</p>
<spanclass="w"></span><spanclass="na">discovery_name</span><spanclass="w"></span><spanclass="o">=</span><spanclass="w"></span><spanclass="s">Region A Private Backbone</span>
<p>In the <codeclass="docutils literal notranslate"><spanclass="pre">[reticulum]</span></code> section of your configuration, you would define the network identity used for encryption as follows:</p>
<p>With these configuration options applied, your Reticulum instance will actively participate in the network’s discovery ecosystem. Other peers running Reticulum with discovery enabled will be able to see your interface, validate its cryptographic stamp, and (depending on their configuration) automatically connect to it.</p>
<p>For information on how to use these discovered interfaces and configure your system to auto-connect to them, refer to the <aclass="reference internal"href="using.html#using-interface-discovery"><spanclass="std std-ref">Discovering Interfaces</span></a> chapter.</p>
</section>
</section>
<sectionid="common-interface-options">
<spanid="interfaces-options"></span><h2>Common Interface Options<aclass="headerlink"href="#common-interface-options"title="Link to this heading">¶</a></h2>
<p>A number of general configuration options are available on most interfaces.
These can be used to control various aspects of interface behaviour.</p>
<blockquote>
<div><ul>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">enabled</span></code> option tells Reticulum whether or not
to bring up the interface. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">False</span></code>. For any
interface to be brought up, the <codeclass="docutils literal notranslate"><spanclass="pre">enabled</span></code> option
must be set to <codeclass="docutils literal notranslate"><spanclass="pre">True</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">Yes</span></code>.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">mode</span></code> option allows selecting the high-level behaviour
of the interface from a number of options.</div>
</div>
<blockquote>
<div><ulclass="simple">
<li><p>The default value is <codeclass="docutils literal notranslate"><spanclass="pre">full</span></code>. In this mode, all discovery,
meshing and transport functionality is available.</p></li>
<li><p>In the <codeclass="docutils literal notranslate"><spanclass="pre">access_point</span></code> (or shorthand <codeclass="docutils literal notranslate"><spanclass="pre">ap</span></code>) mode, the
interface will operate as a network access point. In this
mode, announces will not be automatically broadcasted on
the interface, and paths to destinations on the interface
will have a much shorter expiry time. This mode is useful
for creating interfaces that are mostly quiet, unless when
someone is actually using them. An example of this could
be a radio interface serving a wide area, where users are
expected to connect momentarily, use the network, and then
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">gravity</span></code> option specifies the pathing affinity of an interface.
If not set specifically, and unless otherwise configured by
<codeclass="docutils literal notranslate"><spanclass="pre">default_gravity</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">autoconnect_interface_gravity</span></code>,
it defaults to <codeclass="docutils literal notranslate"><spanclass="pre">0</span></code>. Positive values increase pathing affinity,
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">outgoing</span></code> option sets whether an interface is allowed
to transmit. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">True</span></code>. If set to <codeclass="docutils literal notranslate"><spanclass="pre">False</span></code> or <codeclass="docutils literal notranslate"><spanclass="pre">No</span></code>
the interface will only receive data, and never transmit.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">network_name</span></code> option sets the virtual network name for
the interface. This allows multiple separate network segments
to exist on the same physical channel or medium.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">passphrase</span></code> option sets an authentication passphrase on
the interface. This option can be used in conjunction with the
<codeclass="docutils literal notranslate"><spanclass="pre">network_name</span></code> option, or be used alone.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ifac_size</span></code> option allows customising the length of the
Interface Authentication Codes carried by each packet on named
and/or authenticated network segments. It is set by default to
a size suitable for the interface in question, but can be set
to a custom size between 8 and 512 bits by using this option.
In normal usage, this option should not be changed from the
default.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">announce_cap</span></code> option lets you configure the maximum
bandwidth to allocate, at any given time, to propagating
announces and other network upkeep traffic. It is configured at
2% by default, and should normally not need to be changed. Can
be set to any value between <codeclass="docutils literal notranslate"><spanclass="pre">1</span></code> and <codeclass="docutils literal notranslate"><spanclass="pre">100</span></code>.</div>
</div>
<blockquote>
<div><p><em>If an interface exceeds its announce cap, it will queue announces
for later transmission. Reticulum will always prioritise propagating
announces from nearby nodes first. This ensures that the local
topology is prioritised, and that slow networks are not overwhelmed
by interconnected fast networks.</em></p>
<p><em>Destinations that are rapidly re-announcing will be down-prioritised
further. Trying to get “first-in-line” by announce spamming will have
the exact opposite effect: Getting moved to the back of the queue every
time a new announce from the excessively announcing destination is received.</em></p>
<p><em>This means that it is always beneficial to select a balanced
announce rate, and not announce more often than is actually necesarry
for your application to function.</em></p>
</div></blockquote>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">bitrate</span></code> option configures the interface bitrate.
Reticulum will use interface speeds reported by hardware, or
try to guess a suitable rate when the hardware doesn’t report
any. In most cases, the automatically found rate should be
sufficient, but it can be configured by using the <codeclass="docutils literal notranslate"><spanclass="pre">bitrate</span></code>
option, to set the interface speed in <em>bits per second</em>.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">bootstrap_only</span></code> option designates an interface as a temporary
bridge for initial connectivity. If this option is enabled, the
interface will be monitored and automatically detached once the
number of auto-connected interfaces reaches the limit configured by
<codeclass="docutils literal notranslate"><spanclass="pre">autoconnect_discovered_interfaces</span></code>. This is particularly useful
for using a slow or expensive connection (such as a single LoRa
link or a remote TCP tunnel) solely to discover better local
infrastructure, which then supersedes the bootstrap interface.</div>
<divclass="line">To allow an interface that would <em>otherwise not</em> propagate
announces to <codeclass="docutils literal notranslate"><spanclass="pre">internal</span></code> mode interfaces to do so, you can
configure the <codeclass="docutils literal notranslate"><spanclass="pre">announces_to_internal</span></code> option to <codeclass="docutils literal notranslate"><spanclass="pre">True</span></code>.</div>
<spanid="id4"></span><h2>Interface Modes<aclass="headerlink"href="#interfaces-modes"title="Link to this heading">¶</a></h2>
<p>The optional <codeclass="docutils literal notranslate"><spanclass="pre">mode</span></code> setting is available on all interfaces, and allows
selecting the high-level behaviour of the interface from a number of modes.
These modes affect how Reticulum selects paths in the network, how announces
are propagated, how long paths are valid and how paths are discovered.</p>
<p>Configuring modes on interfaces is <strong>not</strong> strictly necessary, but can be useful
when building or connecting to more complex networks. If your Reticulum
instance is not running a Transport Node, it is rarely useful to configure
interface modes, and in such cases interfaces should generally be left in
the default mode.</p>
<blockquote>
<div><ul>
<li><divclass="line-block">
<divclass="line">The default mode is <codeclass="docutils literal notranslate"><spanclass="pre">full</span></code>. In this mode, all discovery,
meshing and transport functionality is activated.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">gateway</span></code> mode (or shorthand <codeclass="docutils literal notranslate"><spanclass="pre">gw</span></code>) also has all
discovery, meshing and transport functionality available,
but will additionally try to discover unknown paths on
behalf of other nodes residing on the <codeclass="docutils literal notranslate"><spanclass="pre">gateway</span></code> interface.
If Reticulum receives a path request for an unknown
destination, from a node on a <codeclass="docutils literal notranslate"><spanclass="pre">gateway</span></code> interface, it
will try to discover this path via all other active interfaces,
and forward the discovered path to the requestor if one is
found.</div>
</div>
<divclass="line-block">
<divclass="line">If you want to allow other nodes to widely resolve paths or connect
to a network via an interface, it might be useful to put it in this
mode. By creating a chain of <codeclass="docutils literal notranslate"><spanclass="pre">gateway</span></code> interfaces, other
nodes will be able to immediately discover paths to any
destination along the chain.</div>
</div>
<divclass="line-block">
<divclass="line"><em>Please note!</em> It is the interface <em>facing the clients</em> that
must be put into <codeclass="docutils literal notranslate"><spanclass="pre">gateway</span></code> mode for this to work, not
the interface facing the wider network (for this, the <codeclass="docutils literal notranslate"><spanclass="pre">boundary</span></code>
mode can be useful, though).</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">In the <codeclass="docutils literal notranslate"><spanclass="pre">access_point</span></code> (or shorthand <codeclass="docutils literal notranslate"><spanclass="pre">ap</span></code>) mode, the
interface will operate as a network access point. In this
mode, announces will not be automatically broadcasted on
the interface, and paths to destinations on the interface
will have a much shorter expiry time. In addition, path
requests from clients on the access point interface will
be handled in the same way as the <codeclass="docutils literal notranslate"><spanclass="pre">gateway</span></code> interface.</div>
</div>
<divclass="line-block">
<divclass="line">This mode is useful for creating interfaces that remain
quiet, until someone actually starts using them. An example
of this could be a radio interface serving a wide area,
where users are expected to connect momentarily, use the
network, and then disappear again.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">roaming</span></code> mode should be used on interfaces that are
roaming (physically mobile), seen from the perspective of
other nodes in the network. As an example, if a vehicle is
equipped with an external LoRa interface, and an internal,
WiFi-based interface, that serves devices that are moving
<em>with</em> the vehicle, the external LoRa interface should be
configured as <codeclass="docutils literal notranslate"><spanclass="pre">roaming</span></code>, and the internal interface can
be left in the default mode. With transport enabled, such
a setup will allow all internal devices to reach each other,
and all other devices that are available on the LoRa side
of the network, when they are in range. Devices on the LoRa
side of the network will also be able to reach devices
internal to the vehicle, when it is in range. Paths via
<codeclass="docutils literal notranslate"><spanclass="pre">roaming</span></code> interfaces also expire faster.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The purpose of the <codeclass="docutils literal notranslate"><spanclass="pre">boundary</span></code> mode is to specify interfaces
that establish connectivity with network segments that are
significantly different than the one this node exists on.
As an example, if a Reticulum instance is part of a LoRa-based
network, but also has a high-speed connection to a
public Transport Node available on the Internet, the interface
connecting over the Internet should be set to <codeclass="docutils literal notranslate"><spanclass="pre">boundary</span></code> mode.</div>
network different from any marked as <codeclass="docutils literal notranslate"><spanclass="pre">boundary</span></code>. Announces from
a <codeclass="docutils literal notranslate"><spanclass="pre">boundary</span></code> interface will not propagate to interfaces set as
<codeclass="docutils literal notranslate"><spanclass="pre">internal</span></code>, but announces <em>will</em> propagate from <codeclass="docutils literal notranslate"><spanclass="pre">internal</span></code><em>to</em>
<codeclass="docutils literal notranslate"><spanclass="pre">boundary</span></code>. Devices on the <codeclass="docutils literal notranslate"><spanclass="pre">internal</span></code> side of the network will
still be able to resolve paths to destinations across the boundary
when needed, since recursive path requests are enabled for <codeclass="docutils literal notranslate"><spanclass="pre">internal</span></code>
<p>For a table describing the impact of all modes on announce propagation,
please see the <aclass="reference internal"href="understanding.html#understanding-announcepropagation"><spanclass="std std-ref">Announce Propagation Rules</span></a> section.</p>
</section>
<sectionid="announce-rate-control">
<spanid="interfaces-announcerates"></span><h2>Announce Rate Control<aclass="headerlink"href="#announce-rate-control"title="Link to this heading">¶</a></h2>
<p>The built-in announce control mechanisms and the default <codeclass="docutils literal notranslate"><spanclass="pre">announce_cap</span></code>
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">announce_rate_target</span></code> option sets the minimum amount of time,
in seconds, that should pass between received announces, for any one
destination. As an example, setting this value to <codeclass="docutils literal notranslate"><spanclass="pre">3600</span></code> means that
announces <em>received</em> on this interface will only be re-transmitted and
propagated to other interfaces once every hour, no matter how often they
are received.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The optional <codeclass="docutils literal notranslate"><spanclass="pre">announce_rate_grace</span></code> defines the number of times a destination
can violate the announce rate before the target rate is enforced.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The optional <codeclass="docutils literal notranslate"><spanclass="pre">announce_rate_penalty</span></code> configures an extra amount of
time that is added to the normal rate target. As an example, if a penalty
of <codeclass="docutils literal notranslate"><spanclass="pre">7200</span></code> seconds is defined, once the rate target is enforced, the
destination in question will only have its announces propagated every
3 hours, until it lowers its actual announce rate to within the target.</div>
<p>You can also configure default announce rate parameters for all interfaces that
do not have these parameters set explicitly by setting the <codeclass="docutils literal notranslate"><spanclass="pre">default_ar_target</span></code>
<codeclass="docutils literal notranslate"><spanclass="pre">default_ar_penalty</span></code> and <codeclass="docutils literal notranslate"><spanclass="pre">default_ar_grace</span></code> options in the <codeclass="docutils literal notranslate"><spanclass="pre">[reticulum]</span></code>
section of the configuration file. If any of these options are set, they will
automatically be applied to any interface if transport is enabled, and the
interface does not have the parameters set explicitly.</p>
<p>For auto-connected interfaces, sensible default announce rate control parameters
will <strong>always</strong> be set, even if the defaults are not configured explicitly, but
if you set the defaults, auto-connected interfaces will adhere to these as well.</p>
that a large span of network types can seamlessly <em>co-exist</em> and interconnect.</p>
</section>
<sectionid="new-destination-rate-limiting">
<spanid="interfaces-ingress-control"></span><h2>New Destination Rate Limiting<aclass="headerlink"href="#new-destination-rate-limiting"title="Link to this heading">¶</a></h2>
<p>On public interfaces, where anyone may connect and announce new destinations,
it can be useful to control the rate at which announces for <em>new</em> destinations are
processed.</p>
<p>If a large influx of announces for newly created or previously unknown destinations
occur within a short amount of time, Reticulum will place these announces on hold,
so that announce traffic for known and previously established destinations can
continue to be processed without interruptions.</p>
<p>After the burst subsides, and an additional waiting period has passed, the held
announces will be released at a slow rate, until the hold queue is cleared. This
also means, that should a node decide to connect to a public interface, announce
a large amount of bogus destinations, and then disconnect, these destination will
never make it into path tables and waste network bandwidth on retransmitted
sub-interfaces</em>. As an example, this means that one client on a <aclass="reference internal"href="#interfaces-tcps"><spanclass="std std-ref">TCP Server Interface</span></a>
cannot disrupt processing of incoming announces for other connected clients on the same
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ic_new_time</span></code> option configures how long (in seconds) an
interface is considered newly spawned. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">2*60*60</span></code> seconds. This
option is useful on publicly accessible interfaces that spawn new
sub-interfaces when a new client connects.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ic_burst_freq_new</span></code> option sets the maximum announce ingress
frequency for newly spawned interfaces. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">3.5</span></code>
announces per second.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ic_burst_freq</span></code> option sets the maximum announce ingress
frequency for other interfaces. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">12</span></code> announces
per second.</div>
</div>
<blockquote>
<div><p><em>If an interface exceeds its burst frequency, incoming announces
for unknown destinations will be temporarily held in a queue, and
not processed until later.</em></p>
</div></blockquote>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ic_max_held_announces</span></code> option sets the maximum amount of
unique announces that will be held in the queue. Any additional
unique announces will be dropped. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">256</span></code> announces.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ic_burst_hold</span></code> option sets how much time (in seconds) must
pass after the burst frequency drops below its threshold, for the
announce burst to be considered cleared. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">60</span></code>
seconds.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ic_burst_penalty</span></code> option sets how much time (in seconds) must
pass after the burst is considered cleared, before held announces can
start being released from the queue. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">5*60</span></code>
seconds.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ic_held_release_interval</span></code> option sets how much time (in seconds)
must pass between releasing each held announce from the queue. Defaults
to <codeclass="docutils literal notranslate"><spanclass="pre">30</span></code> seconds.</div>
<p>All of the above settings can be configured both as instance-wide defaults
under the <codeclass="docutils literal notranslate"><spanclass="pre">[reticulum]</span></code> section of the configuration file, or on a per-
interface basis under the relevant interface configuration section.</p>
</section>
<sectionid="path-request-burst-control">
<h2>Path Request Burst Control<aclass="headerlink"href="#path-request-burst-control"title="Link to this heading">¶</a></h2>
<p>In addition the announce controls for newly created destination, Reticulum will also
monitor incoming path request activity, and enforce burst controls if per-client rates
exceed configured limits. Once path request burst control is activated on an
interface, path requests will no longer be propagated further on the network.
As with announce burst control, this happens on a per sub-interface basis. One
client connecting to a public gateway will not be able to disrupt path request
processing for other clients.</p>
<divclass="admonition warning">
<pclass="admonition-title">Warning</p>
<p>Applications that send large amounts of unnecessary path requests will very
quickly get rate limited by transport nodes, and the entire system they are
running on will not be able to resolve any paths on the network, until the
burst subsides and hold period expires. <strong>Do not</strong> write applications like
this. Only request paths for destinations you need to communicate with.</p>
</div>
<p>By default, Reticulum will handle this automatically, and ingress path request
control will be enabled on interface where it is sensible to do so. It should
generally not be neccessary to modify the ingress control configuration,
but all the parameters are exposed for configuration if needed.</p>
<blockquote>
<div><ul>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ingress_control</span></code> option tells Reticulum whether or not
to enable ingress control on the interface. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">True</span></code>.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ic_new_time</span></code> option configures how long (in seconds) an
interface is considered newly spawned. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">2*60*60</span></code> seconds. This
option is useful on publicly accessible interfaces that spawn new
sub-interfaces when a new client connects.</div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ic_pr_burst_freq_new</span></code> option sets the maximum path request
ingress frequency for newly spawned interfaces. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">3</span></code>
control per-interface. Defaults to <codeclass="docutils literal notranslate"><spanclass="pre">False</span></code></div>
</div>
</li>
<li><divclass="line-block">
<divclass="line">The <codeclass="docutils literal notranslate"><spanclass="pre">ec_pr_freq</span></code> option sets the hard limit for outbound path requests
per second on a given interface.</div>
</div>
</li>
</ul>
</div></blockquote>
<p>All of the above settings can be configured both as instance-wide defaults
under the <codeclass="docutils literal notranslate"><spanclass="pre">[reticulum]</span></code> section of the configuration file, or on a per-
interface basis under the relevant interface configuration section.</p>
