At. My. Wits. End

Node Operators troubleshooting
21

definitely not, QUIC is a network communication protocol between Peers in the Storj network.

Did you try to refresh a dashboard with Ctrl-F5?

22

yes I did try that. Just recently and before the move

23

are other two nodes running the same way? Both docker and both on the same host?
If yes, please show your current port forwarding rules for all three nodes, the firewall rules and port mapping options for each of the node.
Do you use docker-composer by the way?

24

The other two nodes are running the exact same way. Same machine. Same ISP. Same router. Same DDNS. Same Docker. Not sure what host means…

Red Node and blue node are the new ones that run just fine. 100% up time and NO quic misconfigured.

“old girl” is using port 28989 on internal and external on port forwarding in the router app.
“blue node” is using port 28991 on internal and external on port forwarding in the router app.
“red node” is using port 28968 on internal and external on port forwarding in the router app.

You’ll have to explain to me how to get the firewall rules. A reminder that you and I did explore the possibility of it being the firewall about a month ago and concluded that was not the issue.

My docker run commands are below. I have deleted parts of the run command that are identical for all nodes. The first line is not part of the run command I just put it there for explanation.

"Old Girl"  Oldest node that has been giving QUIC misconfigured for 2+ months
    -p 28989:28967/tcp \
    -p 28989:28967/udp \
    -p 127.0.0.1:14004:14002 \
    -e ADDRESS="REDACTED.tplinkdns.com:28989" \
    --mount type=bind,source="/mnt/OLDGIRL/storagenode/identity/storjidentity",destination=/app/identity \
    --mount type=bind,source="/mnt/OLDGIRL/storagenode/data",destination=/app/config \
    --name storagenodeoldgirl storjlabs/storagenode:latest
    
    
  

"Blue Node"  -working
    -p 28991:28967/tcp \
    -p 28991:28967/udp \
    -p 127.0.0.1:14005:14002 \
    -e ADDRESS="REDACTED.tplinkdns.com:28991" \
    --mount type=bind,source="/mnt/SEA4TBBLUE/identity/storagenode",destination=/app/identity \
    --mount type=bind,source="/mnt/SEA4TBBLUE/storage",destination=/app/config \
    --name storagenodeblue storjlabs/storagenode:latest
    
    
    
    
 
"red Node"   -Working
    -p 28968:28967/tcp \
    -p 28968:28967/udp \
    -p 127.0.0.1:14002:14002 \
    -e ADDRESS="REDACTED.tplinkdns.com:28968" \
    --mount type=bind,source="/mnt/SEA4TBRED/identity/storagenode",destination=/app/identity \
    --mount type=bind,source="/mnt/SEA4TBRED/storage",destination=/app/config \
    --name storagenodered storjlabs/storagenode:latest
25

@Alexey

I have had a couple of fresh ideas on this node that is still displaying “quic misconfigured” but also still coming up as online 95% of the ime and bringing in about $6.00 a month.

Could the quic misconfigured be caused by a failing drive? I’m trying to move the node to a different drive right now and I have run into all sorts of errors. I tried cloning using gparted and it keeps freezing. So now I’m trying using the “dd” command in terminal and input/output errors keep poping up.

Also it says in SMART that there are 42 bad sectors (4 TB SSD)

and finally it says using “df -BG” that the drive is using 2.7 TB but in the node dashboard it says there is 3.55 TB stored on the node.

If I make it through the cloneing process using “dd” and am able to get the node back up and running, will the node repair itself if some data was lost in the cloning? or will my node get disqualified because the bad sectors caused data loss?

26

No, QUIC is just a networking protocol, and misconfigured or not it should only inform you whether your node is reachable or not, regardless of how the data looks in the end.

Just for fun did you try to switch the “Old girl” port with one of the others in your docker run command? Because these are the ones you know are working.

If not too much data has been lost or corrupted, your node will repair itself. If there were too many, it will be disqualified. I think 4-5% should be survivable.

1 Like
27

As @revyte noted the QUIC is a network protocol, it’s not related to stored data.

It will not repair itself. Lost pieces can be repaired only to other nodes. If it would lost more than 4% data, it will be disqualified. However, the node could survive, if it would have a great ingress, because it will reduce a loss percentage, but it’s matter of luck.

28

I never had problems with quick missconfigured; I always used unique ports, internal and external, for each node. Something like 28967:28967 on node1 and 28968:28968 on node2. The contact address and all other addresses must be modified accordingly.
I tryed the recommended way, by keeping the internal 28967 for all, but quick missconfigured poped up instantly on one or the other node. So, my rule now is always to start a new node in the same network with unique ports, in all locations found in config.yaml… contact address, dashhoard, etc etc. Never had problems.

29

I have messed with the ports plenty and have 4 other nodes on the same machine/network running just fine.

THEOLDGIRL is a true enigma.

30

Maybe she dosen’t like calling her OLD. :grin:

2 Likes