You did not get suspended for any QUIC-related issue.
Yes, QUIC is not needed to run a node. (This might change in the future.)
4 Likes
There is no way, if your VPN is supporting only TCP. You always will see this warning. It will not affect your node though.
2 Likes
I think I found what my issue is. I host my node behind a reverse proxy, Traefik. This reverse proxy doesn’t support QUIC yet (http/3 is in the experimental phase).
I’ll try to use another reverse for the node and keep you guys updated (anyone has suggestions?)!
Mine also says “Misconfigured”, but TCP and UDP port forwarding rules are in place and functioning. I’ve confirmed both are active. Not sure what is going on here.
@Sierra - Thanks for the reply. I looked at the Synology firewall, and it is turned off. Is there something else to do in the Syno? (see pic).
Same here. Enabled the ports in the synology and checked them. They are open. Same in my Fritzbox. And still “Misconfigured”. I even enabled IPv6… Nothing changed.
Do you use QNAP App or pure docker?
If the pure docker - then please, make sure that you specified port mapping like this:
-p 28967:28967/tcp -p 28967:28967/udp
If you use an QNAP App, then - no luck, seems it has hardcoded TCP only.
1 Like
I`m using pure docker on my synology.
This is what my Docker command looks like:
sudo docker run -d --restart unless-stopped -p 28967:28967/tcp -p 28967:28967/udp -p :14002:14002 -e WALLET=“xxxxx” -e EMAIL=“xxxxx " -e ADDRESS=“xxxxx:28967” -e BANDWIDTH=“20TB” -e STORAGE=“7.5TB” --mount type=bind,source=”/volume1/docker/storj",destination=/app/identity - -mount type=bind,source="/volume1/docker/storj/share",destination=/app/config --name storagenode storjlabs/storagenode:latest
then please make sure that your forwarded tcp and udp on your router.
Thanks, this fixed it for me on Unraid. I had to create a second port forward for 28967 but with UDP instead of TCP.
for a bit of a positive spin on this, i updated my nodes and all reported QUIC OK.
sort of knew that already, but i just wanted to tell that it wasn’t exactly impossible, even tho many people seems to have had problems configuring / realizing their UDP traffic was hindered.
Worked perfect but had to dust off my vi editor… LOL
1 Like
Take a look in External Access → router configuration
Check that there is a UDP configuration that is the same. If not, you need to make one
Hi,
I would like to share my experience. I’m running a node since May 2021 (Debian 10). I let the server run and update itself with watchtower.
I have noticed that the Docker command to run a node have changed a bit:
Command used in May 2021:
sudo docker run -d --restart unless-stopped --stop-timeout 300 \
-p 28967:28967 \
-p 14002:14002 \
...
The command I’ve used after stopping the node:
sudo docker run -d --restart unless-stopped --stop-timeout 300 \
-p 28967:28967/tcp \
-p 28967:28967/udp \
-p 14002:14002 \
...
Note that I haven’t used -p 127.0.0.1:14002:14002 as explained in the documentation.
The “Quic” is now OK for my node.
I hope it helps.
Hogion
1 Like
In case someone is a Docker noob, like me: I’m running a docker container under Linux. (My configuration just used -p 28967:28967 from the original installation instructions from a couple years ago.) Just stopping and restarting the container with the added parameters wasn’t enough.
I first had to stop and then remove the container, like sudo docker stop -t 300 storagenode && sudo docker rm storagenode. Then, I could restart it using the new parameters to fix the problem.
Thanks, @lex-1, for pointing me in the right direction!
My problem is that yet again the first place I see about some new requirement as a SNO is a warning message in my node’s dashboard. Proactive communication about changes need to happen.
We tried. Doesn’t work. There is no consensus on how to notify every single SNO.
We decided that showing an obvious warning is a best option 
If serious - the communication is the real problem: how to reach out all SNOs? By email? It will going to SPAM. Here, on the forum? We announced it a while ago, nobody cares.
Emails from registration page where you take an authorization token not necessarily can belongs to SNO, who actually run a node. And also emails in node’s configuration can be empty or fake.
We can only ask to track our documentation - we regularly updates it.
Now on GitHub: https://github.com/storj/docs/tree/gitbook-node-sync
3 Likes
This is SNO problem if he has fake/wrong/not working mail in configuration.
Also configuring Spam folder is SNO responsibilities.
Also wold be good to push notification to mobile all, but it is to those who want it.
2 Likes
Even if it’s a joke, it seems to work to everyone.
1 Like
If someone uses no email (like me) or a fake mail in config, it’s not Storjs fault
1 Like