as this:
New-NetFirewallRule -DisplayName “Storj v3 UDP” -Direction outbound -Protocol UDP -LocalPort 28967 -Action allow
OK. Weird. Was told before one should allow any outgoing connections. Not just specific port. Unblock all outgoing traffic and check again. Also what do logs tell about this alert?
1 Like
How about your router?
I don’t get the part with the downgrade. To answer your question you can downgrade but that will not open the UDP port and more important in a few weeks it will stop working. You can delay an upgrade for a few days maybe weeks but in the end, you are forced to upgrade.
3 Likes
If you have configured node according to recommended setup from storj guides, then you also have an active watchtower which checks for updates and apply updates to nodes automatically within some time frame. It is ok that some operators already got updates and some didn’t. I am also still at 1.46.
1 Like
QUIC status being displayed on the storagenode dashboard is a new feature, your node will still be functioning like it has for the last year, and since its a new feature there could be a problem with it.
if your node seems to be functioning correctly i wouldn’t read to much into it and wait and see if there are others that seem to have the same issue.
don’t think it’s been a year since QUIC was implemented, so if you haven’t opened the UDP part of your NAT / Router port routing, then QUIC wouldn’t function.
no need to downgrade, it wouldn’t change anything except whats displayed at the web dashboard.
@littleskunk would windows not begin a new log after each update… seems like it would be a good practice, a 9GB log is borderline useless and at worst dangerous to the operation of the system.
2 Likes
@moudar please, remove this rule. You will block the traffic from your node, because the source port for outgoing connections is random.
Normally you should not have any outbound rules in your firewall. So, please, remove or disable them all (only outbound!).
To have UDP working you also need to port forward UDP 28967 on your router. Some routers allows you to specify TCP/UDP altogether in the rule, but some requires a separate rule for each protocol.
And you do not need to downgrade, @littleskunk is right - you will just postpone the update, this will not fix the issue with port forwarding rule on your router.
4 Likes
I can confirm that QUIC is working properly since one year ago. Now is just displayed also on the Dashboard. You can check on storjnet.info, if Dial and Ping is working for QUIC test.
I’ll advise you to stick with the official Storj Docs guide, and not adding other firewall rules.
I forwarded in router both ports TCP and UDP, and added the rules in firewall with the official guide lines.
New-NetFirewallRule -DisplayName "Storj v3 TCP" -Direction Inbound –Protocol TCP –LocalPort 28967 -Action allow
New-NetFirewallRule -DisplayName "Storj v3 UDP" -Direction Inbound –Protocol UDP –LocalPort 28967 -Action allow
I’m also on the last version of storagenode and the autoupdate must stay on.
The QUIC message on Dashboard shows corectly for Windows and NAS Docker nodes.
I also added a new rule in firewall for monithoring the dashboard from other computers in my LAN, but is not necessary for you:
New-NetFirewallRule -DisplayName "Storj v3 Dashboard TCP" -Direction Inbound –Protocol TCP –LocalPort 14002 -Action allow
than edit the firewall rule: Scope > Remote IP addresses > Local subnet.
I don’t know if Local subnet is my local home network, though… there are also Local intranet and some others; I don’t know the difference.
One dumb question 
…
What is QUIC for? What does it do? Is it a must for a storagenode to work properly?
Storj uses it to work on improving latency in the connection between customer and storagenodes. It isn’t currently vital to the running of a node, but based on how they are talking about it and now reporting it on the dashboard, I do expect that it will be in the future. It’s possible they will always use TCP as a fallback, hard to predict the future. But it wouldn’t surprise me if at some point in the future, new uploads only happen to QUIC supported nodes for example or that it becomes a setting for customers to do so, so that future uploads and downloads of that data can benefit of the QUIC speed upgrades.
Either way, your node is going to miss out on something eventually if you don’t set this up right. But to me the size impact of that isn’t yet clear.
1 Like
Same issue with " QUIC: Miconfigured" v1.47.3
Nothing has changed, I’ve always had both TCP/UDP enabled so I have no clue why it’s reporting a problem. Could there be a bug in 1.47.3?
1 Like
Additional investigation on a second node provides some interesting data:
- The second node does not indicate it is misconfigured.
- The second node is also on v1.47.3
- The second node is configured for TCP only not TCP/UDP
Is it possible that the warning regarding misconfigured is backward?
I’m going to add UDP to node 2 and see if it will then start generating the error.
Try to restart this node. I would also suggest to remove duplicated rules from the Windows firewall.
On Storagenode 2 I enabled UDP as per my prior post and restarted the node. It too now indicates that it is Misconfigured. Going to see if that’s coincidence by disabling UDP and restarting.
It was indeed a coincidence. My steps to resolve were as follows:
- Fix my router config to allow TCP/UDP on 28967
- Find the storagenode.exe Rule in the built in Windows Firewall under advanced Inbound Rules
- Copy this Rule and make sure 1 of them is set up for TCP and the other set up for UDP on 28967
- restart-service storagenode in powershell
2 Likes
I think the storagenode.exe rule is made by Windows when you install the storagenode for the first time and the firewall window pops up.
Check to see if there are duplicates for the same port with different names.
You ca delete the storagenode.exe rule and use the rules from the Storj docs. The difference is in the name of the rule, but looks more cool and clear 
I also had that rule among with the ones from the docs and get rid of it.
If you run multiple nodes on one machine, use different TCP and UDP ports for each and add rules for all.
About logs…
If the log is too big, you can open it with Notepad++ or other coding editor.
Available log levels are: debug , info , warn , error , none .
You can open/edit the config.yaml with Notepad++ or Visual Studio Code or some other coding editor and change the log level. The error level makes the smallest log, but with the fewest info. The debug is the richest in info and makes a huge log.
You cand delete the storagenode.log and storagenode-updater.log anytime, after you stop both services in the Control Panel >… > Services. After deletion, restart the services and they will make new log files.
You can also use log rotate in Windows to automanage your logs. Search the forum for instructions…
For Windows you can configure logrotate for Windows:
https://sourceforge.net/p/logrotatewin/wiki/LogRotate/
or use scripts like:
or
or use Vadim’s Windows Toolbox:
This was provided to me by Alexey… I think.
1 Like
Hello, I had the same problem a few hours ago, I solved it by stopping the service and starting it again.
Use the following commands:
Stop-Service storagenode
Start-Service storagenode
Hope this can help you.
3 Likes
Had exactly the same probleme. everything ok for 2 years and suddenly “QUIC Misconfigured”.
Port opening OK
I solved the problem, it was the antivirus (eset internet security) for no reason eset firewall blocked it, and had to add a rule. QUIC is OK now.
You can check easily if the probleme is the firewall, juste disable it and see if its better
2 Likes