# RNS 1.5.1 Released

_General · started by Mark on Fri, Aug 28, 2026 4:20 PM_

---

## Original post

**Mark** · Fri, Aug 28, 2026 4:20 PM

This release focuses on dataplane control, memory bounding and transport throughput, with adaptive ingress and egress control for interfaces, a new (and very efficient) zero-copy coalescing transmit buffer, an optimized HDLC deframer, and a range of other improvements to the inbound packet processing paths. It also introduces support for live profiling, and various new diagnostics output in `rnstatus`, along with a number of bug fixes and general improvements.

**Changes**
- Added adaptive dataplane egress control
- Added adaptive dataplane ingress control
- Added zero-copy coalescing transmit buffers to interfaces using the `BackboneInterface` backend
- Added early protocol violation checks for invalid frames
- Added transport implementation name and version to discovery information requirements
- Added full live profiling to the built-in `Profiler` primitive, by **K8**
- Added the `@RNS.Profiler.profile` decorator, by **K8**
- Added support for indefinitely running, reentrant profilers with bounded capture, by **K8**
- Added live profiling results output to `rnstatus`, by **K8**
- Added PPS statistics to `rnstatus`
- Added interface MTU display to `rnstatus`
- Added interface TX drop statistics to `rnstatus`
- Added interface TX buffer size output to `rnstatus`
- Added throughput benchmarker to the test suite
- Added support for natively compiled module builds, and the ability to load compiled modules when available
- Added module compilation status reporting from in-wheel build information
- Added parity tests for HDLC, IFAC and HKDF against the legacy implementations
- Added shared medium hints to interfaces
- Improved memory and CPU consumption under high traffic loads
- Improved traffic class handling
- Optimized HKDF to ~5.7x performance, if this worries you, **good**; then see the full parity and standard vector test suite and read the code
- Optimized inbound and outbound IFAC handling to ~90x performance on large frames
- Optimized inbound packet processing by reducing lock acquisitions and path table contention
- Optimized lookups for pending and active links using hash maps for lookup operations
- Optimized announce validation by caching signature validation results, significantly lowering announce storm CPU load
- Optimized the HDLC deframer
- Reduced redundant packet hashing in inbound processing
- Tuned default inbound queue lengths and announce queuing
- Tuned automatic interface MTU configuration
- Fixed `Resource` transfers failing when initialized from stream-based data sources that fell outside `MAX_EFFICIENT_SIZE`
- Fixed an invalid prefix stripping bug in the `rngit` page server (`.something` files not viewable)
- Fixed RSSI/SNR reporting regression
- Fixed keepalive handling on non-epoll backends
- Fixed a bug in `rngit` page navigation content initialization order
- Fixed the `rngit` page node not being able to serve in-tree downloads for large files
- Fixed `rnstatus` blocked IP listing including IPs that were actually not yet blocked
- Fixed `rnstatus` traffic totals counting the local shared instance inter-app transit in totals
- Fixed various minor bugs in `rnsh`, `rnir`, identity handling
- Fixed a latent bug in the AES module, where an exception would not resolve it's exception description correctly, and instead raise another exception.
- Removed dead Python 2 code from `umsgpack`

---

## Reply 1

**Mark** · Fri, Aug 28, 2026 4:22 PM

This time around, there's immediate updates for Sideband as well, including the RNS 1.5.1. Nomadnet has also been updated with new pinned versions and a few minor bugfixes, so not much new in the actual programs, but especially Sideband on Android, and the appimage builds will benefit from this update.

---

## Reply 2

**qbit** · Fri, Aug 28, 2026 5:26 PM

Seeing really high CPU usage after the upgrade, rnsd at 80 to 95% cpu usage across all cores.

Anything I should poke to see what's happening? There isn't anything odd looking as best as I can tell.

---

## Reply 3

**qbit** · Fri, Aug 28, 2026 5:44 PM

Attached `strace` and I see a lot of:

```
futex(0x7fd446c0b000, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY) = -1 EAGAIN (Resource temporarily unavailable)
```

---

## Reply 4

**Mark** · Fri, Aug 28, 2026 6:30 PM

That's very interesting qbit. On Linux or BSD? Looks like full kernel bufs maybe (being attempted written to repeatedly), but BackboneInterface *should* handle that... Hmm, or have I inadvertently created a busy loop under that condition somehow...? Are you seeing this on multiple machines or just one? What kind of interface setup is it? Really interested to know some more details, caus across the 9 different machines I've been testing on, I haven't seen anything like that.

---

## Reply 5

**Mark** · Fri, Aug 28, 2026 6:32 PM

Also the fact that it has high CPU usage across *multiple cores* is quite astonishing, unless you've been cheeky and pre-emptively started running RNS in free-threaded mode with `t`-build of Python.

(don't get any ideas, it's not quite ready yet, and several things need handling before that is possible)

---

## Reply 6

**Mark** · Fri, Aug 28, 2026 6:34 PM

And forgot to ask, does it happen or startup, or after some time? Any trigger conditions?

---

## Reply 7

**qbit** · Fri, Aug 28, 2026 6:37 PM

Seems to just be this one Linux machine. Here is a breakdown of the interfaces it has:

```
      1  AutoInterface
     15  BackboneInterface
      1  I2PInterface
      6  I2PInterfacePeer
      2  LocalInterface
      6  TCPInterface
      1  TCPServerInterface
```

Wondering if it's the I2P stuff.. I am now seeing a lot of: `[2026-08-28 12:36:02] [Debug]    Protocol violation on I2PInterfacePeer[Connected peer on ShutUpAndHack I2P]: Insufficient packet size for IFAC processing` now... though maybe that's legit bad traffic..

---

## Reply 8

**Anonymous** · Fri, Aug 28, 2026 6:56 PM

**qbit** wrote:
> Seems to just be this one Linux machine. Here is a breakdown of the interfaces it has:
> 
> ```
>       1  AutoInterface
>      15  BackboneInterface
>       1  I2PInterface
>       6  I2PInterfacePeer
>       2  LocalInterface
>       6  TCPInterface
>       1  TCPServerInterface
> ```
> 
> Wondering if it's the I2P stuff.. I am now seeing a lot of: `[2026-08-28 12:36:02] [Debug]    Protocol violation on I2PInterfacePeer[Connected peer on ShutUpAndHack I2P]: Insufficient packet size for IFAC processing` now... though maybe that's legit bad traffic..

this is the I2P bug I just literally reported in this stream and proposed a fix for.

---

## Reply 9

**qbit** · Fri, Aug 28, 2026 7:02 PM

Sorry Mark, doesn't seem like all the messages were loaded when I responded - It happens after a few minutes of uptime.

---

## Reply 10

**Mark** · Fri, Aug 28, 2026 7:02 PM

Could you do a quick edit and add `if not data: return` in I2PInterface.py's `process_incoming` method, so it looks like:

```python
def process_incoming(self, data):
    if not data: return
    self.rxb += len(data)
    if hasattr(self, "parent_interface") and self.parent_interface != None and self.parent_count:
        self.parent_interface.rxb += len(data)
    self.owner.inbound(data, self)
```

And tell me if it solves both the protocol violations and the CPU usage, or just the protocol violations, or nothing?

---

## Reply 11

**Mark** · Fri, Aug 28, 2026 7:13 PM

Hey, wait a sec... You're running discovery with pretty high stamp value on your public interfaces, right? So if the CPU usage across all cores starts at around 60 seconds uptime, it's just the stamp generation! At the value you're using it could take a couple of minutes to finish that unless you have some Threadripper show going on or something :)

---

## Reply 12

**qbit** · Fri, Aug 28, 2026 7:44 PM

ope :D - I think that was for sure part of it - but things never settled even after an hour and a half or so.. After the above change things have settled.

---

## Reply 13

**Mark** · Fri, Aug 28, 2026 10:11 PM

I'm pushing out a fixed release in a moment, there was some other issues as well.

---

## Reply 14

**Anonymous** · Fri, Aug 28, 2026 11:17 PM

Mark, I saw the note you have on Aleph about scraping nodes being blackholed. Can you expand on what you view as scraping? Don't want to accidentally trigger something.

---

## Reply 15

**Mark** · Sat, Aug 29, 2026 2:14 PM

Could you instead explain what it is you intend to do? And maybe post it in its own thread?

---

## Reply 16

**Mark** · Sat, Aug 29, 2026 2:15 PM

RNS 1.5.2 is out as well btw, with the fixes for the bugs discussed earlier here @qbit

---

## Reply 17

**C.S.Burner** · Thu, Sep 3, 2026 6:02 PM

I get this error with rnststus. I thought it might be a misconfiguration of an interface (allthough I hadn't changed something). But reduced it to one and followed the docs thouroghly for configuring. The error persists: 

Traceback (most recent call last):
  File "/home/reticulum/.local/bin/rnstatus", line 6, in <module>
    sys.exit(main())
             ~~~~^^
  File "/home/reticulum/.local/share/pipx/venvs/rns/lib/python3.13/site-packages/RNS/Utilities/rnstatus.py", line 897, in main
    program_setup(configdir = configarg, dispall = args.all, verbosity=args.verbose, name_filter=args.filter, json=args.json,
    ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                  astats=args.announce_stats, pstats=args.pr_stats, lstats=args.link_stats, sorting=args.sort, sort_reverse=args.reverse,
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                  remote=args.R, management_identity=args.i, remote_timeout=args.w, must_exit=must_exit, rns_instance=rns_instance,
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                  traffic_totals=args.totals, discovered_interfaces=args.discovered, config_entries=args.D, burst_filter=args.burst,
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                  blocked_ips=args.blocked_ips, queue_stats=args.queues, pps=args.pps, profiling=args.profiling)
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/reticulum/.local/share/pipx/venvs/rns/lib/python3.13/site-packages/RNS/Utilities/rnstatus.py", line 495, in program_setup
    if ifstat["txdrp"]:
       ~~~~~~^^^^^^^^^
KeyError: 'txdrp'

---

## Reply 18

**Mark** · Thu, Sep 3, 2026 9:02 PM

C.S. Burner, looks like your running rnsd instance is on a version older than 1.5.2, while `rnstatus` is on 1.5.2, it's trying to get an interface stat that wasn't available before.

---

## Reply 19

**Anonymous** · Fri, Sep 4, 2026 6:13 AM

Similar KeyError: 'txdrp' here with rnststus. Same config, just made update from 1.5.1 to 1.5.2.

---
