# Are reticulum links normally this unstable? _Help · started by welo on Wed, Jul 8, 2026 9:43 PM_ Tags: Question --- ## Original post **welo** · Wed, Jul 8, 2026 9:43 PM Sup weavers Currently forking [rns-proxy](https://github.com/mytecor/rns-proxy) to add udp support and other utilities to tunnel regular internet traffic through reticulum (coming soon in showcase post) but I keep having the issue where my links disconnect often enough that it's causing real issues and would make this way less useful for real usecases, happens roughly every 2-3 minutes after forming the link but can be anything between connecting for about 5 seconds and 20 minutes. ![image.png](/storage/forum/1N1kp7ZY86AhdEQfnGnqHtCIYoloa3zL3JxPU4hZ.png) To ask the title question, Are links normally this unstable? I'm directly connected to the reticulum instance I'm connecting to, which also happens to be a public backbone running on a spare pc on the same network, and so latency and network throughput shouldn't constraint. I was originally gonna blame and possibly fix the [rns-net](https://github.com/lelloman/rns-rs/tree/master/rns-net) implementation but I remember that even using `rnsh` on my personal devices would have similar issues where it'd disconnect pretty often even with a direct backbone connection. Are links just like this? I could always switch to using normal packets from the link destination to avoid this and reconstruct the stream myself, might make more sense specifically for udp as it's not meant to reliable like tcp but fragmentation (Internet MTU >> Reticulum MTU) and as well as I think being more inefficient than a link destination (according to the docs anyways) makes me second guess that possibility. --- ## Reply 1 **Zenith** · Wed, Jul 8, 2026 9:50 PM You are trying to fit a square peg through a round hole and asking why the hammer isn't working. You want to tunnel regular IPv4 traffic over Reticulum (something it is NOT designed to do and there are almost ZERO benefits of and there are a DOZEN better options for), using a WIP project, that uses in turn a WIP Rust port. I have no idea how to answer "Are reticulum links normally this unstable?" because the question has so many variables that it would be impossible to answer. --- ## Reply 2 **welo** · Thu, Jul 9, 2026 4:14 AM man I just needed a "Yea links are unstable sometimes here's how you work around that" or a "nah something wrong on your end go check your end/implementation" For the record I did read [this thread](https://github.com/markqvist/Reticulum/discussions/290) and I'm aware the zen part of the manual says in about 5 different ways to not do this, i just found those arguments for that unconvincing. Yes if applications used RNS directly that'd more efficient and whatever, but I'm a practicalist not an idealist, if an 300% overhead means that people can use programs written 30 years ago by tunneling tcp then so be it, ironically this would probably lead to more full RNS ports because people would get used to the feature and would like a version without the overhead that would be 4 times faster. I'd also argue that a good socksv5 implementation (which is what the tunneling is based on) is good for anticensorship reasons too plus possibly being to proxy to the clearnet through packet radio or whatever, which gives reticulum more of a usecase which is always good. Also for the record, I'm half making this cause I thought making a *tf2* and *minecraft* server connectable through reticulum would be both be funny to play (because it would be impractical and would barely work) and interesting from a networking perspective. Obviously not the most serious usecase but those games are pretty hands on ways of feeling network packet loss, latency and bandwidth as well as a decent network stress test as I don't think there's any services on reticulum that take a large amount of constant bandwidth yet, only thing I can think of is downloading a large file from nomadnet and it's probably good to check if that would cause any issues on the network before a group of people decide it's a good idea to send 10gb/s through the network. Even if you fully disagree of what I'm doing (which is kinda fair) you have to know that someone else will either do the ipv4 tunneling or sending a lot of data through the network because it's *by the people for the people* and nobody truly controls it so people will abuse and betray the original purpose and zen of it, better make a ipv4 tunnel as efficient as possible (i'll try my best) and prepare for network load rather than sticking our heads in the sand hoping people won't discover this wonderful technology. --- ## Reply 3 **aetherlab** · Thu, Jul 9, 2026 5:20 AM Why this jumpyness? Zenith is correct in many aspects, and the most important ones are not at all addressed in your reply. It's like another kid is trying to pull the toy from your hands, as you enjoy bashing it in a wall, because it's yours, because you want to, because if not you, someone else will bash it, because... because... You do not need to generate this ample amount of self-righteousness, but stop and think for a moment of any possible implications, think what more experienced people have to say. This childish, reactive behavior was the bread and butter of the Matrix channel, that got closed down. All Zenith is saying, is that you use underthought tools to perform underthought tasks, that can be performed a lot more efficiently with other, well thought out tools, and by this you have overlayed so much variables, that might not only coincide, but spawn new unknown ill effects, that by all means this is not a good approach. And he never said, we should not test the network to find it's limits. We have to, for sure, but do it in an educated, understanding and meaningful way, using well prepared tools, optimized for the task, that will return predictable results, and will keep the whole task away from unexpected effects. This is how it's done properly. The ability of people to grasp tasks, effects, complexities and complications, to listen and deduct, has fallen to rock bottom recently. So suggest, share ideas, share your concerns and let's discuss like grown-ups. And not bash our new beautiful toy against a wall, because we can... Also: man I just needed a "Yea links are unstable sometimes here's how you work around that" or a "nah something wrong on your end go check your end/implementation"" You wanted what? For him to justify what you do? And maybe fix it for you? Yeah, this is how life works, it bends and conformal-coats yourself... It should NEVER put your face in the mud! Because you don't need this shit! :D This is disrespectful, self-centered and needy. Very descriptive. --- ## Reply 4 **aetherlab** · Thu, Jul 9, 2026 5:20 AM Somehow posted twice... --- ## Reply 5 **pla55** · Thu, Jul 9, 2026 7:28 AM Ok, to bring this thread a bit closer to actual meaningful discusson I'll focus on the unadressed part of the OP: rnsh has also cut out occasionally for me, but in my case I didn't have a direct connection to the node hosting it. So I understand why it would cut out in my case, not so much with yours. It's true that it could be designed a bit more like mosh where it handles intermittent link loss and has local echo to make high latency links more pleasant to use. But it's not a big deal for me, I just spin up a tmux session to not lose my history. --- ## Reply 6 **welo** · Thu, Jul 9, 2026 10:35 AM Okay I apologies for my previous response I was just pissed off at 1am irrationally, I'm just doing it cause I think it's a fun and interesting project and I hope that it might be useful to someone in very specific usecases when there's no better alternative and I turned that into 3 paragraphs of cry-typing. However Zenith's original response was a little bit out of left field and was more mean-spirited than helpful in any way and didn't offer any good questions or suggestions besides just "stop". Also to clarify: > you wanted what? For him to justify what you do? I just wanted to know what I was seeing of links losing connection occasionally was just a normal thing in the network/stack currently and thus I should go build my systems with that in mind or if that isn't normal that I should go looking for any bugs instead of building ontop of shaky foundation, I didn't want any code or anything I just wanted to know if I gonna be chasing a bug that didn't exist and figured someone would know that piece of information. I just phrased that either-or badly so it came off wrong. on that semi-related note to making old applications work with reticulum, I do wonder how hard it would be to fork an existing app and change the connectivity from ip based to RNS based internally by editing the source code and syncing all future upstream commits, for example Syncthing. Would it only take an hour and thus gaining a back catalogue of reticulum supporting apps would be trivial or would it take so long to port that it would just make make a similar implementation from scratch would be more practical. That would be an interesting thing to investigate and that might be a more fruitful and efficient than my solution of naively tunneling ip traffic and if it is viable it makes much more sense than reinventing the wheel for every reticulum application if 99% of the code should be the same anyways, though I would still argue that ability to tunnel ip traffic through reticulum AS A LAST RESORT WHEN THERE IS NO BETTER ALTERNATIVE (or for non serious "I just need something to work for 2 minutes" tasks) is a useful but objectively terrible tool in the toolbox. also thanks pla55 that's what I needed to know. PS, can an admin move all these replies to a separate "TCP/UDP through Reticulum - META thread" or something along those lines cause while this devolved from the original title post a tad, this is a quite interesting discussion with fair and good points if you ignore the fact we are all a bit more emotionally charged about a damn network stack than what is probably healthy for us all |: --- ## Reply 7 **Anonymous** · Thu, Jul 9, 2026 12:14 PM rnsh has had line-interactive / local echo mode almost from the beginning. Works brilliantly for even extremely slow links. Personally, it's extremely rare that I see a link drop, and often have rnsh sessions running for several days. If path goes over all kinds of random nodes, where the underlying physical connections may drop, or nodes are restarted or whatnot, you'll of course see links drop as well, but in just semi-good conditions, I practically never see a link "just drop". If you're using work-in-progress / non-reference implementations, that's a whole different story, though. All of the WIP implementations that I've tried has had serious issues and are not at all stable or "every-day functional" yet. --- ## Reply 8 **welo** · Fri, Jul 10, 2026 7:09 PM Okay I discovered that this had more to do with `autoconnect_discovered_interfaces` and reticulum's pathing (maybe) I originally had `autoconnect_discovered_interfaces` set to 80 from earlier testing and messing about and I assumed reticulum would recognise the direct LAN backbone connection between my computer and my server 5 meters away, but it turns out RNS would instead send the link through some foreign flacky connection with little bandwidth instead my local LAN connection, turning off that setting and only having that LAN connection solved all issues instantly. Even when I explicitly would connect to a server half way across the world, as long as it was a server with good bandwidth, there was no issues. I can't tell if this [rns-net](https://github.com/lelloman/rns-rs/tree/master/rns-net) being ass or if the reticulum python implementation that I had running on both machines was causing the issue, but It's good to know that more interfaces isn't necessarily better ---