QUIC Misconfigured on Synology

This is what I have received as final answer from SYNOLOGY support:

Dear Customer,

Thank you for the patience in waiting.

From my discursion with the developers, I am sorry, there is little we can do about the situation. I was informed that, the Synology does not officially (currently) supports QUIC. Docker being an open source package, I have checked through the documentation without being able to find any information relating to the Network settings.

I will suggest that you contact Storj for more information on why the issue occurred and how to prevent such in future.

Do not hesitate to contact me, if you have any further questions.

Best Regards,

O. Medahunsi
Technical Support Engineer

Yes WM Win10 from the same Synology is fine. I have tried reinstalled docker and after recreate all nodes but with no luck. Question is if I can downgrade it…going to try :face_with_monocle:

Correct me if i am wrong, but afaik quic is only nice to have and no must have.
So its no Problem, if its not working :wink:

Yes so far so good…still online but strange that my Win10 machines works without issue but SYNOLOGY-DOCKER nodes are misconfigured. Hopefully STORJ will not force this as mandatory to be marked as online and reliable STORJ NODE :slight_smile:

I found that rebooting my Synology NAS fixed this issue.

Hi Holocronology,

This has been done many times same as recreation of nodes, reinstall docker, restart nodes, recreate router port forwarding rules, reboot router etc, etc…

Wigo

Sure. It would be great if there was a better solution.

I would like to add that I tried PING tool on https://storjnet.info/ and get results for one of my Nodes which has QUIC Misconfiguration issue:

First PING:

And second is DIAL:

image

But still Misconfigured :frowning:

I guess someone with docker and/or sinology needs to try a simple experiment of delaying the storage node start in the container for a few seconds, to rule out the possibility of the race condition between docker network up and the service start. (Restarting container won’t help, the storage node service as it is started in the container needs to be delayed for testing, and subsequently made dependent on the network interface readiness)

1 Like

Hi arrogantrabbit,

Well exist there any configuration hint how to achieve this delay after recreation/restart of the node under docker?

Thank you

Wigo

Container is using supervisord to launch the storage node:

You may want to try to add delay via the technique described here: python - How to add a delay to supervised process in supervisor - linux - Stack Overflow (adding another program, that will launch storage node with delay, and disable storage node autostart). This can be done by running a shell in the running container and editing the embedded script in the overlay.

Ideally, there should be a way to specify dependencies, but there does not seem to be any.

Actually, the script, instead of a delay, could be trying to establish a connection to, say, 1.1.1.1. until it succeeds, thus implementing dependency on a network being up.

Hmm not experienced in LINUX stuff but it would be nice if someone can re-write this to DSM - Docker like “format”. :innocent:

But anyway is funny that other people does not have this issue on SYNOLOGY and DSM.

Thank you

Wigo

I start to believe that update on your Synology did not goes well…

1 Like

Yes looks like I have to try reset network as first step and than as second step reinstall DSM on SYNOLOGY.