rns.recipes

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!

That was quick!

Is the manual available as a nomad page? I can't see any manuals for 1.5.0 online

1.5.0 worked on our local mesh, whereas 1.4.2 was dropping connections. Thanks for the release and all who contributed.

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!

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!

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:

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.

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.

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.

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 :)

Thanks, sounds safe and like a good idea. Packets being dropped should only happen in absolute overwhelming situations then.

Could this be the reason traffic suddenly fell on my node? Upgrading now

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?

No, there's a regression there. I'm looking into it.