ISP pulls the plug

Last night at 3 am my ISP rebooted some equipment, as they often do. My node is offline since then, as CGNAT got turned on again. After lots of waiting and phone calls we were told that they will not turn it off again, as they have now too many customers in our area. Their solution: a business connection with a fixed IP, costing more than 3 times what we pay now.

A quick search seems to indicate that this is a widespread problem that will only get worse, as more and more devices get connected.

@storjlings There must be a way to connect nodes to satellites without having to jump through all the hoops of CGNAT and port forwarding. E.g. my Signum HD miner only gets the url of a mining pool and it doesn’t need any of that. Speed is of the essence for it. Since the node initiates the connection there should be no need for all this.

So where to now? The few suggestions I have seen say to use ssh tunneling or a VPN. Both require a server somewhere on the net. My node has earned $18 in almost 12 months. If there is a solution, it must be free or it makes no sense.

Regards,
Peter.

The difference is that your miner only contact the pool to provide your data. No one customer is accessing your miner from the outside.

In case of server - it must be available for the customers.
So there is no way to skip port forwarding if you behind the NAT. The only alternative is to use IPv6. Not all satellites currently working with IPv6 and not so much customers with IPv6 only. So the dual stack will be there for a long time.

You can solve this issue in two ways:

  • switch ISP to one who doesn’t have such a problem;
  • use VPN services with port forwarding feature such as portmap.io, ngrok, AirVPN, PureVPN, etc.
1 Like

Ok, I wasn’t aware customers contacted nodes directly. Thanks for the explanation.

My wife has already checked, but we are in a rural area and so far there is only one ISP that has strung fibre cable here.

I’ll see whether I can find a free way to use one of the services you mentioned, but I’m not holding my breath. I remember seeing a video a few months ago describing how to set up a 1 year trial on a cloud provider. It would mean having to re-do the setup every year.

I’m setting up portmap.io now. This looks like what we need, serving the dual purpose of DDNS and port forwarding. Except, I have to choose between tcp and udp. I chose tcp, but will that be enough?

I’m fairly certain I have set it up correctly, but it’s not working. In the log it says ‘connection refused’.

docker run -d --restart unless-stopped --stop-timeout 300 \
    -p 28967:28967 \
    -p 14001:14002 \
    -e WALLET="0xb1c9621fa5A9ce5a818e09B732334c4A8d05D47d" \
    -e EMAIL="beddhist@gmail.com" \
    -e ADDRESS="beddhist-54653.portmap.io:54653" \
    -e STORAGE="3.5TB" \
    --mount type=bind,source="/mnt/WDred4TBexQM2/storj1/identity/",destination=/app/identity \
    --mount type=bind,source="/mnt/WDred4TBexQM2/storj1/",destination=/app/config \
    --name storagenode1 storjlabs/storagenode:latest

On portmap.io I have:

 tcp://Beddhist-54653.portmap.io:54653 => 28967 

And this is the command to start the tunnel they gave me:

ssh -i ~/.ssh/Beddhist.first.pem Beddhist.first@Beddhist-54653.portmap.io -N -R 54653:localhost:28967

The only thing is, the tunnel runs as a normal user, docker as root.

And there is no udp.

I re-ran the ssh command and this time it did not exit and the port now shows as open. My node just sat there, doing nothing, so I re-started it and it went online. I THINK it’s working, although it started with some errors:


2021-06-25T12:33:09.181Z	INFO	failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 2048 kiB, got: 416 kiB). See https://github.com/lucas-clemente/quic-go/wiki/UDP-Receive-Buffer-Size for details.


2021-06-25T12:33:10.123Z	INFO	collector	delete expired	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Piece ID": "CDYGNWAKT5JYMV3FJU6EJNI36KUF2Z3FKNDWSLEUHKXQIBLRCYQA"}


2021-06-25T12:33:10.224Z	INFO	collector	delete expired	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Piece ID": "26NFNLDCZQ6ZGERZ6HWIMQFELZDBGEQTUVTJCWYW6VN6LTDD6JKA"}


2021-06-25T12:33:10.559Z	INFO	collector	delete expired	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Piece ID": "F6SDDDVBHKGJMI2ELEGXXRKJBEYJN66ZOZAEHCYPDLJS3SJWL7PA"}


2021-06-25T12:33:10.862Z	INFO	collector	delete expired	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Piece ID": "TAT3OHMEPYHC6UAQHNGHP7CI2FUQYQVDYYK6TGATFLCLVEILVLKA"}


2021-06-25T12:33:11.145Z	INFO	collector	delete expired	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Piece ID": "A6JRR2FK7KURORNNO4JSENKX4SGFYNDSPDJO3TRJ47QNMQM7QJTA"}


2021-06-25T12:33:11.617Z	INFO	collector	delete expired	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Piece ID": "VDGCNZV5LAE2F5TWFPUYJJC33E2RQF7HRR2QMAW6EEX3IYI4XXXQ"}


2021-06-25T12:33:11.907Z	INFO	collector	delete expired	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Piece ID": "36BRYINIQSX4AOY4Q6C4YART5GRFP2XOPZTY7DQAQ7DVRVKZZXZQ"}


2021-06-25T12:33:12.295Z	INFO	collector	delete expired	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Piece ID": "3NU4EOMOJ6G7EB5L7XHUSDIINSWUILR6PO2ABLRFDCHECUE52WKA"}


2021-06-25T12:33:12.761Z	INFO	collector	delete expired	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Piece ID": "TRPBHFP6RCJOA5FHNMPIRBHT2Y2XN2UCR4NNGEK6HDLPUK2V276A"}


2021-06-25T12:33:12.761Z	INFO	collector	collect	{"count": 9}


2021-06-25T12:33:16.006Z	WARN	contact:service	Your node is still considered to be online but encountered an error.	{"Satellite ID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Error": "contact: failed to dial storage node (ID: 121f1EnmKqxYgXFh6w9qEyewdQeZWde7jSQA6P7ZnTJrGsS2b42) at address beddhist-54653.portmap.io:54653 using QUIC: rpc: quic: timeout: no recent network activity"}


2021-06-25T12:33:16.070Z	WARN	contact:service	Your node is still considered to be online but encountered an error.	{"Satellite ID": "12rfG3sh9NCWiX3ivPjq2HtdLmbqCrvHVEzJubnzFzosMuawymB", "Error": "contact: failed to dial storage node (ID: 121f1EnmKqxYgXFh6w9qEyewdQeZWde7jSQA6P7ZnTJrGsS2b42) at address beddhist-54653.portmap.io:54653 using QUIC: rpc: quic: timeout: no recent network activity"}


2021-06-25T12:33:16.342Z	WARN	contact:service	Your node is still considered to be online but encountered an error.	{"Satellite ID": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6", "Error": "contact: failed to dial storage node (ID: 121f1EnmKqxYgXFh6w9qEyewdQeZWde7jSQA6P7ZnTJrGsS2b42) at address beddhist-54653.portmap.io:54653 using QUIC: rpc: quic: timeout: no recent network activity"}


2021-06-25T12:33:16.353Z	WARN	contact:service	Your node is still considered to be online but encountered an error.	{"Satellite ID": "12tRQrMTWUWwzwGh18i7Fqs67kmdhH9t6aToeiwbo5mfS2rUmo", "Error": "contact: failed to dial storage node (ID: 121f1EnmKqxYgXFh6w9qEyewdQeZWde7jSQA6P7ZnTJrGsS2b42) at address beddhist-54653.portmap.io:54653 using QUIC: rpc: quic: timeout: no recent network activity"}


2021-06-25T12:33:16.428Z	WARN	contact:service	Your node is still considered to be online but encountered an error.	{"Satellite ID": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE", "Error": "contact: failed to dial storage node (ID: 121f1EnmKqxYgXFh6w9qEyewdQeZWde7jSQA6P7ZnTJrGsS2b42) at address beddhist-54653.portmap.io:54653 using QUIC: rpc: quic: timeout: no recent network activity"}


2021-06-25T12:33:17.070Z	WARN	contact:service	Your node is still considered to be online but encountered an error.	{"Satellite ID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Error": "contact: failed to dial storage node (ID: 121f1EnmKqxYgXFh6w9qEyewdQeZWde7jSQA6P7ZnTJrGsS2b42) at address beddhist-54653.portmap.io:54653 using QUIC: rpc: quic: timeout: no recent network activity"}

The errors seem to have stopped now. One problem remains: the ssh command will terminate as soon as I shut down my PC, closing the ssh terminal. Do I now have to create a service to run ssh?

On Linux you can use “screen” to run it in background. For example “screen -dmS service command” starts the command in background, where service is the name of the screen session (you can name it how you want) and the command is the bash command which ist executed in the background. Jump in with “screen -r service” and jump out of it with CTRL-A-D. With “screen -ls” you can see all screen sessions which are running. Due to the first error line: Linux Configuration for UDP - Node Operator might help

1 Like

TCP should be enough yes

Thanks @zuik . I have used tmux for now, which does the same thing. But it needs to start automatically. On top of that, the first invocation has failed 2 out of 3 times. So I think a service is mandatory. Must do some reading, this is not that hard.

The rcv buffer error: I have already run the command to make it permanent, but looking at the numbers I think Linux does the sane thing here to protect itself. The server has only 2GB RAM. Also, this is a udp buffer and udp can’t be used, so I think I just ignore it.

Oh, and thank you @Alexey , you have saved the day, or rather the node.

2 Likes

It is enough for now. This said, UDP connectivity is being tested and both TCP and UDP will be recommended in the future.