Hello!
Today noticed that QUIC is red Misconfigured, yesterday everything was in the normal state, have nothing changed.
UDP and TCP port 28967 are open, on the router Firewall and Windows firewall, I see on the router that packages are flying through Firewall. And windows netstat shows that connection via the 28967 port is established.
Is that just glitch or do I need to make any steps to negotiate this Misconfigured QUIC?
1 Like
I’ve found this can be an issue on my nodes too, and it usually coincides with high I/O or CPU load. If I leave it for two or three minutes, it goes back to normal, and my scores don’t seem to be affected (indeed, the node exporters show no drop in traffic while it’s marked misconfigured). You probably don’t need to worry too much unless it’s like that for hours on end.
1 Like
You may try to refresh a dashboard after a hour. By default the node is trying to check-in on the satellites every hour and then satellites checks availability on both QUIC and TCP and report it in response on attempt to check-in.
If you node would be still with misconfigured QUIC, then make sure that you actually forwarded UDP 28967 on your router and created an inbound firewall rule for UDP 28967 too.
What device/setup are you using?
I am running my node in a docker container on my Synology NAS. I have found that I get the misconfigured QUIC if the NAS is rebooted without a proper node shutdown.
If I manually shut down the node, reboot the NAS, and manually restart the node after the NAS has fully rebooted, then the misconfigured is cleared.
I think it’s a general problem, 5/20 of my nodes are “Misconfigured”.
1 Like
Ideally the network should be fully ready when you start your node. For Windows you may configure a dependency, like there:
for Linux and service you should configure the service unit to start after the network is ready.
For docker nodes under Windows there is likely no issues, because to start a Docker desktop you need to login to the session and the network is likely fully ready to this time (unless you use Windows Task Scheduler, but in this case you may specify to trigger only when the network also ready).
For docker nodes under Linux (except podman and RHEL-like OSes where you can configure it as a some kind of service still using a docker image: Guide for installing Storage Node without docker (Linux)? - #3 by arrogantrabbit and of course you can configure it to start after the network is ready) you need to configure the docker daemon to start after the network is ready (I believe it’s by default though).
Please note, the node will check-in on the satellites once a hour by default and satellites will check QUIC availability again. So maybe you just need to refresh a dashboard to see the latest status.
However if you see errors related to QUIC/udp in your logs, then you likely has a network configuration issue or some filtering between the satellite and the node.
Service restart solved the problem.
Then it likely the network was not fully ready.
1 Like