QUIC Misconfigured on Synology

Node Operators troubleshooting
,
41

Yes, I know it impuves a lot, but we, Synology users, are cut out, because Synology plays by its own rules, and what it is working for the majority, dosen’t seem to work for Syno. My canceled uploads and downloads are through the roof ever since tcp_fastopen has been implemented and addopted by majority.

42

Hello, I know this is an old topic but I have just started again with Storagenodes and I am facing this exactly issue.

I’ve been reading accross all the thread and my problem still persist.

I have applied the workaround of sysctl -w net.core.rmem_max=2500000 on the synology boot as it was mentioned here → Nothing changed.

Then I have applied the workaround sysctl -w net.core.rmem_max=7500000 as it can be found in Linux Configuration for UDP - Storj Docs → Nothing changed

I made all the network test to ensure that the UDP packets are correctly forwarded to the container hosted in Synology. I have a Fortigate as external firewall (because I am network engineer), so it is giving me more information than just a household router and I can confirm that the UDP packets are arriving to the container:

Synology IP: 192.168.28.10
Storagenode IP inside of container: 172.17.0.5
Public IP of storagenode:77.33.50.2
Public IP of test client: 78.11.18.114

Source of the test:
→ Linux box in 78.11.18.114 public ip
command: echo -n "ping" | nc -u 77.33.50.2 28967

TCPDumps in Destination

  • TCPDUMP in Fortigate (this is the firewall facing to internet and Synology’s gateway)
    command: diagnose sniffer packet any 'host 192.168.28.10 and port 28967' 4 0 1
    result:
    114.534667 servers out 78.11.18.114.53646 -> 192.168.28.10.28967: udp 4

  • TCPDUMP in Synology
    command: tcpdump -i any port 28967
    result:
    13:18:08.596143 IP 78.11.18.114.53646 > 192.168.28.10.28967: UDP, length 4
    13:18:08.596314 IP 78.11.18.114.53646 > 192.168.28.10.28967: UDP, length 4
    13:18:08.596569 IP 172.17.0.1.41677 > 172.17.0.5.28967: UDP, length 4
    13:18:08.596579 IP 172.17.0.1.41677 > 172.17.0.5.28967: UDP, length 4

As you can see, the packets arrived succesfully to the container, so something else is failing here.

I also made this test found in another post of this thread:

> - started
> - 
> - from: St.Petersburg, Russia
> - TCP: dialed node in 228ms
> - TCP: pinged node in 70ms
> - TCP: total: 298ms
> - QUIC: dialed node in 230ms
> - QUIC: pinged node in 73ms
> - QUIC: total: 302ms
> - 
> - from: OVH, France
> - TCP: dialed node in 148ms
> - TCP: pinged node in 36ms
> - TCP: total: 183ms
> - QUIC: dialed node in 158ms
> - QUIC: pinged node in 36ms
> - QUIC: total: 194ms
> - 
> - done.

Anyone had any similar issue or have solved it by doing something that I am missing?

Regards

43

https://forum.storj.io/t/changes-to-the-udp-buffer-size-for-quic-needed/30362/13?u=snorkel

What Syno model do you have? What RAM?

44
  • Set buffer size to 64MB
  • Bind to an interface address explicitly, not 0.0.0.0
  • Don’t change port number throughout forwards.

If that does not help, official storj guidance is to ignore it

Changes to the UDP buffer size for QUIC needed!
45

Hello,

My setup is Synology 415+ (INTEL Atom C2538) 4GB of RAM.

I have ran SN in the past in same box with no issues.

What do you mean by bind it to an interface address explicitly, not 0.0.0.0? You mean to attach directly to the host interface (192.168.28.10) of Synology instead to the bridged one? (the internal subnet with 172.17.0.0/16)

Regards.

46

Confirm you implemented all three recommendations and still see issues.

1 Like
47

Ok, let me see this new link i will try to implement it. Posting soon.

Thx!

48

Hello,

I have to post again because without applying any change, it got fixed automatically. I think that maybe QUIC was not working while the node was in vetting process…

The only thing that I made to try to solve the initial issue was apply first this: sysctl -w net.core.rmem_max=2500000 and after not observing any effect I increased to sysctl -w net.core.rmem_max=7500000, but nothing happened as well. After some days QUIC changed to “OK”, so I changed it again to sysctl -w net.core.rmem_max=2500000 and it also worked and this is how it is right now. So it seems to work with 2500000 and 7500000.

I have serious doubts if this parameter is doing or having any real effect…

Honestly I don’t know what happened and would be nice to know some explanation from any expert on the topic.

Regards.

49

Same here. For the first time in weeks none of my nodes showing QUIC errors. I guess storj changed something at satellites.

50

Didn’t you guys update the StorageNode software?

I updated it to v1.131.7 and automatically got fixed.

I haven’t tweaked the router or Synology. Is there something changed in GO language?

51

Storagenode picks up GitHub - quic-go/quic-go: A QUIC implementation in pure Go. They change shit around all the time. Unless you stabilize the environment (ports and interfaces) the behaviour is not deterministic, and therefore it may start or stop working randomly. There is no “automatically got fixed” becuase nobody is working on this and the fact that it randomly works for you now is no different from the previous fact that it randomly stopped working for you.

For me it never stopped working after I made the environment as unambiguous as possible, packets simply can’t go anywhere else.

Official storj guidance is to stop stressing over quic. It’s irrelevant. So let’s.

2 Likes