This maintenance release adds improved handling for RNodes with a PA/LNA combo.

Changes
-  Improved handling for RNodes with PA/LNA combo
- Added interference detection stats to rnstatus output for RNode interfaces
- Updated documentation

Release Hashes

7a2b7893410833b42c0fa7f9a9e3369cebb085cdd26bd83f3031fa6c1051653c rns-1.0.4-py3-none-any.whl
ee647e7b3b94abdf1fab618a861390531a4aacc93eecce12c9e97280195c0e2d rnspure-1.0.4-py3-none-any.whl

Get this #release via pip or GitHub.

This release initiates migration of Reticulum from AES-128 to AES-256 as the default link and packet cipher mode. It is a compatibility/migration release, that while supporting AES-256 doesn't use it by default. It will work with both the old AES-128 based modes, and the new AES-256 based modes. There's a very slight penalty in performance to support both the old and new modes at the same time, but only for single packet APIs (not links), and it really shouldn't be noticeable in any everyday use.

In the next release, version 0.9.6, Reticulum will transition fully to AES-256 and use it by default for all communications. That means that both single packets and links will use AES-256 by default. The old AES-128 link mode may or may not be available for a few releases, but will ultimately be phased out entirely.

The update requires no intervention, configuration changes or anything similar from a users or developers perspective. Everything should simply work. This goes both for the 0.9.5 update, and the next 0.9.6 update that transitions fully to AES-256.

Changes
- Added support for AES-256 mode to links and packets
- Added dynamic link mode support
- Added temporary backwards compatibility for AES-128 link and packet modes
- Added get_mode() method to link API
- Added tests for all enabled link modes
- Added instance_name option and description to default config file
- Improved ratchet persist reliability if Reticulum is force killed while persisting ratchets
- Fixed interface string representation for some interfaces
- Fixed instance name config option being overwritten if option was not last in section
- Fixed unhandled potential exception on fast-flapping BackboneInterface connections

Release Hashes

ae6587c86c98cae0df73567af093cc92fe204e71bb01f2506da9aec626a27e97 rns-0.9.5-py3-none-any.whl
96208c1d1234e3e4b1c18ca986bad5d4693aeb431453efd7ade33b87f35600e1 rnspure-0.9.5-py3-none-any.whl

Get this #release via pip or GitHub.

@adingbatponder What you might be able to do is solder wires from the 5V pads on the bottom of the Pi 4 PCB to the 5V USB input pad on the Pi Zero. If the PSU can provide enough current for them both, that should work.

@adingbatponder Yes, depending on what you want to do, it may also be worth looking into just using lxmd, since it's easier to script and interact with externally. It can host propagation nodes, but also receive messages and just run external commands when those messages are received. So if this is for some kind of testing setup or similar, that may be a more flexible option.

@adingbatponder Normally the program would set that option when initialising the LXMF router instance, and it shouldn't really be overridden by something in the environment. Both Sideband, nomadnet and the lxmd program supports setting the delivery limit via config file options or user preferences. Isn't there an option for that in MeshChat as well? I'm thinking it would be a lot easier to simply provide a modified config file to MeshChat before startup that sets the delivery limit correctly, instead of trying to patch the source code.

@adingbatponder @smurfy Nice! Good to hear!

@adingbatponder You should be able to link them with AutoInterface if the VMs are on the same bridged network (ie., can hear ethernet multicast packets from each other. I'm not terribly familiar with Proxmox, so don't know if that is standard there. On KVM/QEMU, you need to enable it in the VM configuration at least, since it defaults to a routed, NATed network for each guest.

@kev RNS sticker in the wild! Hooray!

@geekmomprojects Woooow, so mesmerizing! Very cool build! I can't quite tell from the video, but all the segments are identical, right?

@adingbatponder @easytarget Yes, that should work automatically. Just add two different RNode interfaces, one fast and one long range, and it will use the faster one when available.

This release significantly improves memory utilisation and performance. It also includes a few new features and general improvements to the included utilities and programs.

Changes
- Significantly improved memory utilisation, thread count and performance on nodes with many interfaces or clients
- Switched local instance communication to run over abstract domain sockets on Linux and Android
- Switched instance IPC to run over abstract domain sockets on Linux and Android
- Added kernel event based I/O backend on Linux and Android
- Added fast BackboneInterface type
- Added support for XIAO-ESP32S3 to rnodeconf
- Added interactive shell option to rnsd
- Added API option to search for identity by identity hash
- Added option to run TCP and Backbone interfaces in AP mode
- Improved RNodeMultiInterface host communications specification
- Improved rncp statistics output
- Improved link and reverse-table culling
- Fixed an occasional I/O thread hang on instance shutdown, that would result in an error printed to the console
- Fixed various minor interface logging inconsistencies
- Fixed various minor interface checking inconsistencies
- Updated internal configobj implementation
- Refactored various parts of the transport core code
- Swicthed to using internal netinfo implementation instead of including full ifaddr library
- Cleaned out unneeded dependencies

Release Hashes

4b01260519d0c995f343ad325c302b779557fa686ec81bf00161696f0d657689 rns-0.9.4-py3-none-any.whl
c590be37c813f5c145649fcf488a4fdd1687b6187ab02a8679ca730c511fb042 rnspure-0.9.4-py3-none-any.whl

Get this #release via pip or GitHub.

@adingbatponder The coding rate does in fact not need to be the same! Only frequency, bandwidth and spreading factor.

The upcoming 0.9.4 release of Reticulum will include a series of significant improvements to system resource utilization. Work has been focused on the core I/O handling and internal in-memory data structures. This has resulted in substantial reductions in both memory consumption, thread counts and CPU utilization, especially noticeable on nodes with many interfaces or connected clients.

Lighter Memory Footprint
The in-memory table structures have been optimized significantly, and disk caching added for data that doesn't need to stay loaded in resident memory. Memory cleanup, path table management and table entry purging has also been overhauled and optimized.

The net result is a reduction in resident memory load of approximately 66%. As an example, one testnet node with 270 interfaces and around 800 concurrently active links incurred a memory load of 710 MB on rnsd version 0.9.3.



With the new optimizations in 0.9.4, memory load stabilizes at a much lighter 230 MB under similar conditions.



These improvements are of course going to be most noticeable on well-connected transport nodes, but even for small or singular application-launched instances, the improvements are important, and contribute to the goal of running even complex RNS applications on very limited hardware.

Faster I/O Backend
A new backend for handling interface I/O, and shipping packets off to the RNS transport core, has also been added in this upcoming release. It uses kernel-event based I/O polling, instead of threads for reading and writing the underlying hardware (or virtual) devices. This approach is *much* faster, and of course decreases processing time wasted in multi-threading context switches significantly.

On RNS `0.9.3`, the example node from before utilized around 275 threads, but on version `0.9.4`, everything is handled by a mere *6 threads*, grand total. That includes *all* the threads of RNS, like those needed for running memory maintenance, managing storage and caching, and other backend handling.



Additionally, the new I/O backend uses abstract domain sockets for communication between different RNS applications on the same system, offering a slight, but still welcome performance improvement. More importantly, though, using domain sockets for intra-RNS instance communications makes it *much* easier to handle several different RNS instances running on the same system, as these can now simply be given human-readable namespaces, making config file management and complex setups a lot more manageable.

To run several isolated RNS instances on the same system, simply set the `instance_name` parameter in your RNS config files. You can verify that your instance is indeed running under the correct namespace (here the default system namespace) by using the rnstatus command, which should give you output such as the following:

Shared Instance[rns/system]
  Status    : Up
  Serving   : 3 programs
  Rate      : 1.00 Gbps
  Traffic   : ↑8.61 GB   798.45 Kbps
              ↓11.51 GB  859.64 Kbps

In this initial release, the new I/O backend is available on Linux and Android. The plan is to extend it to Windows and macOS in future releases, but since these operating systems have different ways of interacting with kernel event queues, it makes sense to stage the deployment a bit, and make sure that everything is working correctly before adding support for these as well.

Lower CPU Load
The improvements to memory structure, increased I/O efficiency and decreased thread counts all contribute to lowering the CPU load required to run Reticulum. Especially the much decreased need for context switching makes a positive difference here, and this is very noticeable on systems that handle very large numbers of interfaces or connected clients.

The testnet node referred to in this post is a small single-core VM, that handles between 250 to 320 interfaces, and between 700 to 1,000 active links at any given time. Even on such a small machine, CPU usage rarely spikes above 15%, and long-time load average is essentially always at `0.01`.

While there is still many more options to work on, for even better performance and lower resource utilization, this work is a big step forwards in terms of immediately useful scalability, and the ability to deploy even large and complex Reticulum-based systems and applications on very modest hardware, such as low-power SBCs and embedded devices.

#reticulum #performance #networking #meshnetworks

We have to stop consuming our culture. We have to create culture. Don't watch TV, don't read magazines, don't even listen to NPR. Create your own roadshow. You want to reclaim your mind, and get it out of the hands of the cultural engineers, who want to turn you into a half-baked moron consuming all this trash, that's being manufactured out of the bones of a dying world.

- Terence McKenna

Back in 2008, I recorded this track with an old guitar, a Korg Kaoss Pad and a very cheap midi keyboard. It's been hanging out in my drawer for 17 years, but now it's available here. McKenna's words are as relevant today as ever.

If you like it, you can download Cultural Diversion from my channel.

https://hub.federated.channel/attach/d96a0741-d11b-41d5-b94b-2419f85b6fc8?f=&zid=m_u_v%40mastodon.social