~~SBC Network?~~ NAT nightmares

Just for fun, I am toying with the idea of a SBC-Comnet.
No cloud instances no PC nodes only single-board computers like Raspberry pi, Pine64 etc.

This is only to gauge how many people would have a single-board computer to add as a node.

If you can/want to add a node and will be able to commit to keeping it online for the duration please let me know.

I would like to exclude the use of scripts to fill it, so we could agree a higher put max? 20MB?
The goal simply being keeping it up as long as possible.

Thoughts or suggestions welcome.

(This will only be Wed or Thursdayish)
Reevaluating when…


Rpi 4 4gb ram 128gb sd card here (I’d have 2 of them but iirc somehow more than one node behind the same router wasn’t possible in the past…?)


I don’t think 2 is an issue as long as ports differ. I am planning on 3 to 5 myself.

On a similar note, I dont think Maidsafe are stopping nodes behind NAT yet, at least I have not noticed code go in.


I have unused Orange Pi PC ( AllWinner H3 SoC, 1GB DDR3) running 24/7. It is probably too low on RAM, but I can try.


But I think they don’t actually work either? Or do they?


From my experience if that is exceeded we are already having troubles. I guess you could consider increasing swap but idk if it would be beneficial.

We will find out, tests are always heavily reliant on DO so harder to tell. I think nodes behind NAT are only going to be avoided until stability is certain not because of a particular problem.


Last time I got my node pseudo-joined, meaning my node was able to initiate connection to other nodes and even get a bunch of chunks. But the other nodes were not able to initiate connection towards me. That is, if I understood somewhat correctly how it was.

But all experimentation is good in my opinion of course.

1 Like

Yes, you are right. It’s a problem for the network to have non contactable nodes like that. So we need to ban them for now. Later when we get back to NAT traversal that nightmare can start again :scream:


Does this affect all nodes behind NAT or some.
I feel I have had nodes from behind without issue but I could have been oblivious.


Right now, it will be all nodes behind NAT. It just means it kinda looks like it’s working then calamity stikes as nodes and their data are lost as nobody can connect to them. If any is an elder then the network will quickly die.

We should get the NAT block PR in place really as this is a major issue right now for testing.


ok will pause this idea until the block is in place and we know those who join can be reached.


With a fiber connection you can add a switch between the NID and your router.

Any device connected to this switch directly is not behind NAT right??

Tell me why I would be a fool to do this.


But it would still be cool to have some Comnets between those of us, who can use these droplets in different providers - or are otherwise not behind NAT. To make it so that one elder is really in different place from another.

Personally I am behind NAT, but I’ll see if I can change that without it being too expensive or difficult.


The devices would all need a public IP address. You will have one allocated for sure but I am not sure how this would work. Every device you set up would need to be allocated an address either via DHCP or manually.


I have done it before (many moons ago when I couldn’t connect to a test from home)

It worked, but at the time my questioning of how and why ended with I am connected ask no more questions.

On the road for a few days but when I get home I will experiment in more detail.


It theoretically can be, but I wouldn’t bet on it. Different ISPs can have different setup, but from what I have seen or worked with, it is mostly setup to only allow one device. With more devices it is more complicated and ISP wants clear border between his network and customers LAN.

I understand the reasoning, but this will effectively block most people from trying servers from home hw and only allow people who have/buy access to datacenter machines.
Am I correct the issue is with automatic port forwarding? So maybe switch off the automatic option and allow manually configured NAT could be enough? With a warning “please don’t use this if you are not sure what you are doing”.


It’s just too hard for folk to know how all this works. So stage 1 for us will be to kill NAT, then we will introduce tests to test for proper connectivity (i.e. STUN-like) and then let folk try and set up port forwarding either manually or IGD. We will likely also put hole punching back in play, but we do need to check the connectivity and kill nodes that cannot be connected to as it’s really an attack on the network.


How about this?



Existence of this is the best example of how bad is the current state of IPv4 internet.

All these hacks have the same problem, they sometimes work, sometimes don’t and it is very hard to diagnose why.


The projects GitHub: