Quic misconfigured even with ports open and yougetsignal.com tells it works

[Gaggenau]

I have just setup a Storj Storage node in a docker container on a synology NAS, and opened for port 28967 on both TCP and UDP on my firewall, i have a static IP.

It does however say QUIC Misconfigured.
I have checked the firewall on the synology server is turned off.
I have dobule checked the ports on my Unifi router to make sure they where correct.
if i use Yougetsignal.com it says the port is open, if i try to access “MyWANIP:28967” i get the page in the last picture which i think indicates the ports are open and it works.

I’ve read trough a couple of topics on the forum before posting and they wrote that sometimes you should just ignore the QUIC misconfigured if you done everything and double checked that it is correct and it says “online” on status then it will fix itself, but when i look at the satellites they start to go down on the online % which makes me write this post, because something is wong, i just can’t figure out what.

As i am a new member i can’t attach all the photos in this post, i have instead uploaded them to Imggur where you can see them.
Link: Imgur: The magic of the Internet

[Roxor]

I’m not positive… but it feels like Satellites check general-connectivity and QUIC-connectivity at different times? Like I may start a node and it says QUIC=Misconfigured (but Online)… and when I look again in an hour everything is OK.

You should still be able to test QUIC directly here. But I wouldn’t worry too much about it and just check again later.

[arrogantrabbit]

You can ignore QUIC failures, it’s pretty much not being used. You will get more bang for buck enabling TCP fastopen instead.

if you still want to fix it, try this, I’ve heard it also helps synology users: Binding to a specific interface to stabilize QUIC connectivity

[Alexey]

Yes, the QUIC connectivity checked on each check-in, it’s happening every hour by default.
The restart would enforce it though (if the node is not rate-limited due to previous unsuccessful check-in attempts with an offline external address for example).

[Gaggenau]

Okay, that makes me a bit more comfotable, but mine have not changed from “misconfigured” to “OK”, and it have been up for 38 hours.
I tested on the website and it gave me the message: QUIC: couldn’t connect to node: rpc: quic: context deadline exceeded, so does that mean that it does not work?

[Gaggenau]

I don’t care if it works or doesn’t, i just didn’t want to get disqualified, espcially because the online % on the satelittes was going down, even tough the docker have an uptime of 38H and i have not had any drops in my internet connection.
I am not familiar with TCP Fastopen, i might look into it, i just had some free storage laying around and StorJ seems like a good thing to try and use my storage for.

[arrogantrabbit]

@Gaggenau

and opened for port 28967 on both TCP and UDP

And I assume forwarded them both to the machine, right?

@Gaggenau

I don’t care if it works or doesn’t, i just didn’t want to get disqualified, espcially because the online % on the satelittes was going down, even tough the docker have an uptime of 38H and i have not had any drops in my internet connection.

You won’t get disqualified for QUIC, it does not affect online score.

But you do need to disable Synology’s firewall/antiddos/all that bloatware that does not work and only stands in the way. It may be responsible for your low online score. If this will keep falling your nodes will get suspended and then disqualified.

QUIC stop working after SYNOLOGY DSM update

Typical Synology. Their “opensource package not our problem” copout is not even valid, as they do modify those packages and do introduce issues. Not saying this is the case here but it happened in the past. Before they became too popular they had email support straight to engineering and those folks were brilliant at solving problems. Now the support is pretty useless, making the Synology appliances useless. If users wanted to support them - they would buy something else. /rant. I skimmed thoug…

The 100% on saltlake you can ignore – there is no traffic from it right now.

[Gaggenau]

@arrogantrabbit

And I assume forwarded them both to the machine, right?

yes, both a rule for TCP and a rule for UDP, and they are both forwarded to my Synology’s local IP, 192.168.0.25

@arrogantrabbit

You won’t get disqualified for QUIC, it does not affect online score.

But you do need to disable Synology’s firewall/antiddos/all that bloatware that does not work and only stands in the way. It may be responsible for your low online score. If this will keep falling your nodes will get suspended and then disqualified.

i just checked my online scores and when i compare the screenshot i took yesterday when i created the post and the dashboard today, my online score have gone up, so i suppose that is a good thing, and i should just be patient assuming they keep going up.
Both Firewall and Ddos is disabled on Synology, i haver been enabled them.

@arrogantrabbit

The 100% on saltlake you can ignore – there is no traffic from it right now.

Okay good, i will ignore it, thanks

One thing i just checked is my Synology’s DNS was set to my Adguard server, i’ve changed that to google’s DNS, 8.8.8.8, and restarted the docker container, still QUIC misconfigured, but as long as my online % keeps going up, i suppose it will be good and i will just ignore the QUIC warning.

[Alexey]

@Gaggenau

QUIC: couldn’t connect to node: rpc: quic: context deadline exceeded, so does that mean that it does not work?

yes. Did you change -p options to have it mapped?

Step 4. Configure QUIC - Storj Docs

@Gaggenau

i just didn’t want to get disqualified, espcially because the online % on the satelittes was going down, even tough the docker have an uptime of 38H and i have not had any drops in my internet connection.

Your node should be online for the next 30 days to recover. Each downtime requires an additional 30 days to recover.
See

How is the online score calculated? - Storj Docs

Just keep it online. You may also check, when your node was not available for the satellites:

My uptime should be 100% on all satellites i have not gotten any uptime robot notifications of downtime in months

Would you mind to provide dashboard from the uptimerobot? And also, please, provide result of the command: PowerShell foreach ($item in ((Invoke-WebRequest http://localhost:14002/api/sno).Content | ConvertFrom-Json).satellites.id) { ((Invoke-WebRequest http://localhost:14002/api/sno/satellite/$item).Content | ConvertFrom-Json).auditHistory.windows | Where-Object{$_.totalCount -ne $_.onlineCount} | ForEach-Object{Write-Host $item; $_ | Format-Table -AutoSize} } bash for item in `…

[Gaggenau]

@Alexey

yes. Did you change -p options to have it mapped?

I used the one from the StorJ documentation, did have to remove the “127.0.0.1” from port mapping with 14002, if it was as Storj documentation said “-p 127.0.0.1:14002:14002 " i could not connect to the dashboard of my node, haven’t changed anything else, other than of course the necessary things i need to change.
"
sudo docker run -d --restart unless-stopped --stop-timeout 300
-p 28967:28967/tcp
-p 28967:28967/udp
-p 14002:14002
-e WALLET=“0x4CBB2b32F5286e1f47af14BDE2594342D976B523”
-e EMAIL=“MYEMAIL”
-e ADDRESS=“WANIP:28967”
-e STORAGE=“50TB”
–user $(id -u):$(id -g)
–mount type=bind,source=”/volume1/docker/Identity/storagenode",destination=/app/identity
–mount type=bind,source=“/volume1/docker/data”,destination=/app/config
–name storagenode storjlabs/storagenode:latest
"

@Alexey

Your node should be online for the next 30 days to recover. Each downtime requires an additional 30 days to recover.
See

Okay perfect, thanks it is already going up towards 100%, so that makes me more comfotable.
The lower online % must have been from when i tried to fix the problem with not being able to access the dashboard on port 14002 until i found out that i needed to remove “127.0.0.1” from the docker run command.

[Alexey]

You may try the suggestion

@arrogantrabbit

if you still want to fix it, try this, I’ve heard it also helps synology users: Binding to a specific interface to stabilize QUIC connectivity

which is mean to change your -p options like this:

-p 192.168.0.25:28967:28967/tcp \
-p 192.168.0.25:28967:28967/udp \

[Gaggenau]

@Alexey

which is mean to change your -p options like this:

-p 192.168.0.25:28967:28967/tcp \
-p 192.168.0.25:28967:28967/udp \

Now that makes sense, i could’t figure out what he meant in the post.
i have now tried to change the options, but no luck, it did however say “refreshing” on the QUIC status and the shortly after “misconfigured” i have never seen the “refreshing” before.

@Roxor

You should still be able to test QUIC directly here . But I wouldn’t worry too much about it and just check again later.

After chaing the -p in my docker run command i tried to use the website again, but i still get the “QUIC: couldn’t connect to node: rpc: quic: context deadline exceeded”
I then tried to change the -p flag to a IP in the docker bridge network "-p 172.17.0.3:28967:28967/tcp " but it failed and could not bind an IP in the network, so iguess the QUIC just isn’t anything i will use then.
If it isn’t used i am okay with it saying misconfigured.

[Alexey]

@Gaggenau

I then tried to change the -p flag to a IP in the docker bridge network "-p 172.17.0.3:28967:28967/tcp " but it failed and could not bind an IP in the network

You need to use the IP of the host here. If it’s dynamic, you need to update the docker run command every time when it’s changed. Or you may make it static on your router (usually in the DHCP section).

@Gaggenau

If it isn’t used i am okay with it saying misconfigured.

yes, it’s rarely used. So, you may ignore it.

[Gaggenau]

@Alexey

You need to use the IP of the host here. If it’s dynamic, you need to update the docker run command every time when it’s changed. Or you may make it static on your router (usually in the DHCP section).

All my servers use static IP’s
I have another Synology server which is running OpenVPN on port 1194 with UDP and a Unifi cloud key which uses port 3478 also with UDP and those things works like they are supposed to.

@Alexey

yes, it’s rarely used. So, you may ignore it.

I am going to ignore it then, thank you, i am gonna mark you answer as the solution on this thread.