QUIC Misconfigured in v1.67.1

1.67.1. It auto-updates. But I don’t use docker. Hence, question about potential race between docker network up and quic check.

I’m currently not running watchtower. So, docker updated itself. Usually my 2 newest nodes update first. But, this is my oldest node that updated first. And is also having the QUIC misconfigured issue. I’ll plan some maintenance soon and reboot it to see if it resolves. It’s still operating fine, and getting plenty of data.

Same problem here. I got 14 nodes, so far three of them has updated to 1.67.1 and all three got ‘Quic Misconfigured’. Doing a stop / rm / start solved the issue.
Now I’m keeping an eye on the other 11 nodes waiting for the ‘Quic Misconfigured’ …

1 Like

I did some maintenance today and mine resolved after restarting as well. Up 5+ hours so far.

One of my Windows GUI nodes just updated to v1.67.1 and is now receiving the QUIC misconfigured message. A node restart did not fix the problem. Was running fine on 1.66.1. Nothing changed on my side.

1 Like

MacOS Monterey v12.6.1 + Docker v4.14.1 (91661) - Same trouble as mentioned at top of this discussion. I’m having a red “Misconfigured” alert for QUIC status since v1.67.1 auto-upgrade of my StorJ Node. Nothing has changed in my network configuration. Reboot of Router, Docker and/or Stop/Start StorJ Node didn’t help. Thanks for giving a patch or a new StorJ version to solve this issue.

1 Like

My Node Status:

One was auto-upgraded to v1.67.1 another still v1.66.1

Ubuntu, docker

Both work fine.

If problem still affects many node operators, should Storj temporarily pause the auto-upgrade? Is that possible? @Alexey

At least until we know the exact cause and have a fix?

Same issue for one of my two nodes, which got upgraded to v1.67.1. The other node shows that QUIC configured correctly, but the one which got upgraded started to show this error. No changes were made to router or node config (otherwise node which did not upgrade yet would also show same error).
I also went to RDP to server and checked if corresponding ports are opened via site, and site reports that they are opened.
Tried to restart node and now it shows QUIC as correctly configured, but judged by other replies it may report error again later.

EDIT
5h in after restart of node - error did not appear again.

Same problem, I changed nothing and verified the port forwarding, QUIC was showing OK on all nodes until upgraded by Storj to 1.67.1

A post was merged into an existing topic: Current Month Earnings in Node V1.67.1

Mine is still up after 46hr, my restart was a stop -t 300. And, a full server update and reboot.

If after upgrading to 1.67.1 QUIC Misconfigured appears, it is enough to press the F5 key to “fix” it :rofl: The Reload key inside the page does not help, but F5 solves all problems except for the wrong Current Month Earnings, and for that we will wait for a newer version…

4 Likes

Wow, it works, QUIC is green again :rofl:

1 Like

On a NAS with Docker, I run 2 nodes on 2 disks. The watchtower is set to update both nodes. How can one be at 1.67.3 and the other at 1.66.1? Dosen’t it update the storagenode:latest image for both in the same time? I don’t know how linux works…

There should be some kind of mechanism in the node software/network that make sure the rollout of every new version is gradual.

And for a good reason: in case the new one has a bug, it doesn’t affect the whole system at the same time.

My updated node is also showing QUIC Misconfigured. Is this also a visual bug?

1 Like

I have this as well but after SYNOLOGY DSM update. Running under Docker.

To answer my own question, I’d say yes. A refresh of the page fixes QUIC.

EDIT: I mean a refresh of the browser page fixed QUIC. Refreshing the dashboard using the top left button did not fix QUIC. Just saying…

2 Likes

and the version with a fix is in rollout:

See https://version.storj.io/

Please note that we already are doing the rollouts of each new release in small batches, not all at once for all nodes for the exact reason you just stated.