# RNS 1.5.0 Released _General · started by Mark on Sat, Aug 22, 2026 3:13 PM_ --- ## Original post **Mark** · Sat, Aug 22, 2026 3:13 PM Ready to grab over RNS itself or `pip` a8d24177d946de4f1f0a0fe1af9a1338:/page/release.mu`g=reticulum|r=reticulum|t=1.5.0 This release significantly improves the core Transport handling of RNS, with a priority-based ingress queue backend, substantially improved efficiency of both data and management traffic handling, more efficient ingress/egress limiting, and a long list of other improvements and bugfixes. **Changes** - Added ability to include operator LXMF address in interface discovery information - Added prioritized inbound traffic processing to the transport core - Added configurable inbound queue lengths for data, announce, path request and ingress limited traffic - Added early filtering for inbound traffic and improved filtering performance - Added per-interface protocol violation tracking - Added in-flight path requests tracking - Added request and response batching for in-flight path requests - Added ability to signal blackholed status in announce validation return to the API - Added full link MDU utilization for `Channel` and `Buffer` - Added inbound queue pressure and queue drop statistics to `rnstatus` - Added detailed announce and path request traffic flow statistics per interface to `rnstatus` - Added total announce and PR count/frequency stats per interface to `rnstatus` - Added data flow speed and composition stats to `rnstatus` - Added protocol violation stats to `rnstatus` - Added active link statistics to `rnstatus` - Added blocked IP listings to `rnstatus` - Added medium bitrate based timeout calculation helpers and RPC functions, by **Zenith** - Added extra timeout for discovery path requests when slow interfaces are online, by **Zenith** - Added adaptive timeouts to `rncp`, `rnpath`, `rnprobe` and `rnx`, by **Zenith** - Added adaptive timeout calculation to `rngit`, by **Zenith** - Improved overall Transport inbound processing speed - Improved path request handling significantly - Improved path request ingress limiting and accounting - Improved egress limiting responsiveness under high incoming path request load - Improved transport background job processing - Improved early rejection of packets with excessive hop counts - Fixed `BackboneInterface` EPOLL receive starvation and ingress control timestamp handling, by **JRG** - Fixed potential transport deadlock on receipts lock when callbacks sends packets, by **JRG** - Fixed transport state handling edge cases in path request, announce queue and pending link processing, by **JRG** - Fixed link watchdog not resetting on receive exceptions, by **JRG** - Fixed `Resource` cancellation on multi-segment resources, by **JRG** - Fixed `Resource` transfer part index alignment and rebinding, by **JRG** - Fixed stale BLE device reference in `RNodeInterface`, by **JRG** - Fixed ratchet cleaning retained preservation, by **JRG** - Fixed invalid `rnstatus` statistics handling, by **JRG** - Fixed various bugs in packet, link and interface handling, by **JRG** - Fixed per-interface burst count inconsistencies in `rnstatus` output - Fixed `rngit` file resource operations failing on Windows - Fixed `rnodeconf` config summary incorrectly displaying WiFi mode - Fixed speedtest example aborting transfers on stale link status - Updated documentation, including manual sections on queue tuning and interface discovery options Enjoy! --- ## Reply 1 **joakim** · Sat, Aug 22, 2026 4:25 PM That was quick! --- ## Reply 2 **Anonymous** · Sat, Aug 22, 2026 6:30 PM Is the manual available as a nomad page? I can't see any manuals for 1.5.0 online --- ## Reply 3 **Anonymous** · Sat, Aug 22, 2026 7:07 PM 1.5.0 worked on our local mesh, whereas 1.4.2 was dropping connections. Thanks for the release and all who contributed. --- ## Reply 4 **joakim** · Sat, Aug 22, 2026 7:53 PM Looks to be running fine on my transport node. I don't notice anything except things running smoothly, and that's the sign of good work. Appreciate all the work that went into this! --- ## Reply 5 **aetherlab** · Sat, Aug 22, 2026 8:00 PM Thank you Mark, updated all rns.sofia network devices. Looks good for now! I hope we will see 1.5.0 in Sideband soon. Best of the best! --- ## Reply 6 **Mark** · Sat, Aug 22, 2026 9:17 PM Thanks everyone, good to hear! If you find anything weird, post it over in the RNS 1.5.0 testing thread. This was a massive piece of work, and I've tried to be ultra careful here, but if bugs snuck in, we'll get them fixed :) Yes @aetherlab, I'll have an updated Sideband build soon including RNS 1.5.0 :) --- Regarding the manual, you can always fetch the latest manual in PDF and EPUB formats directly using `rngit`: ```sh rngit release rns://7649a50d84610232d1416b41d2896aff/reticulum/reticulum fetch "latest:Reticulum Manual.pdf" ``` Or download it using nomadnet from the latest release page: a8d24177d946de4f1f0a0fe1af9a1338:/page/release.mu`g=reticulum|r=reticulum|t=latest Or, there's also a fully nomadnet browsable version on Aleph: a8d24177d946de4f1f0a0fe1af9a1338:/page/blob.mu`g=reticulum|r=reticulum|ref=HEAD|path=docs/markdown/index.md Or, if you clone the RNS repository, there's a static HTML version in there as well. And, I've also pushed the latest manual to the reticulum.network website now, so it's available on the web too now. --- ## Reply 7 **Anonymous** · Sun, Aug 23, 2026 7:41 PM Would you mind talking a bit about how the ingress queue works? In the manual it says: > If an inbound packet arrives and its target queue is full, the packet is dropped. Naturally I dont want packets to be dropped at all if they are legitimate, but now I worry they might be ^^ what does the queue lenght mean in practice when running a public backbone node for example? I am not competent enough to figure this out from the code. --- ## Reply 8 **Mark** · Mon, Aug 24, 2026 12:01 AM By default, there's four queues. In prioritized order: - Data (highest priority) - Announces - Path requests - Ingress limited traffic (lowest priority) If your system can't keep up with transporting packets as fast as they're arriving (for example, if it is at 100% CPU utilization), something will have to get dropped. You want ingress limited traffic to get dropped first (PR and announce spam, for example, or bogus data traffic from interfaces with many protocol violations). If dropping that is still not enough to keep up, path requests are dropped, then announces, and only then is data packets considered for dropping. The data queue is much larger than the other three by default. In almost all cases, you will never drop a legitimate packet. You can watch the queue pressure and drop stats with `rnstatus -qmI1` for example. --- ## Reply 9 **Mark** · Mon, Aug 24, 2026 12:05 AM This also serves to prioritize drainage by traffic class. For example, you don't want your live voice call to cut out and go all wonky because some arsehole decides to connect and dump 10k bogus path requests on your node in a second. The queues solve that :) --- ## Reply 10 **Anonymous** · Mon, Aug 24, 2026 6:08 PM Thanks, sounds safe and like a good idea. Packets being dropped should only happen in absolute overwhelming situations then. --- ## Reply 11 **Anonymous** · Tue, Aug 25, 2026 1:43 AM Could this be the reason traffic suddenly fell on my node? Upgrading now --- ## Reply 12 **G6PHF** · Tue, Aug 25, 2026 9:49 AM Hi Has rnprobe had the received signal level removed from it in 1.5? Pretty sure it used to report it. I tried a probe to a recently marginal rnode and used to get around 60% now it’s showing more or less 100% quality but no rssi? --- ## Reply 13 **Mark** · Tue, Aug 25, 2026 10:44 AM No, there's a regression there. I'm looking into it. ---