QUIC Misconfigured after upgrade to v1.90.2
FW still shows active sessions and traffic on both TCP and UDP ports
What’s your OS/platform?
Synology
DSM7.1 - wrong, real one is DSM 6.2.4-25556 Update 7
Docker 20.10.3-0554
Before Storj node upgrade all works OK
2 Likes
Synologys… only the multinode manisfests this. The one node NAS-es are OK. I will set the IP in the server address and report back.
1 Like
The official recommendation is to ignore this.
2 Likes
@Alexey
I lost track of recommendations about ports and IPs… 
Does this looks OK? I just added the LAN IP to server.address.
docker run -d --restart unless-stopped --stop-timeout 300 \
--network host \
-e WALLET="..." \
-e EMAIL="..." \
-e ADDRESS="WAN IP:28972" \
-e STORAGE="7TB" \
--mount type=bind,source="/volume2/Storj2/Identity/storagenode/",destination=/app/identity \
--mount type=bind,source="/volume2/Storj2/",destination=/app/config \
--name storagenode2 storjlabs/storagenode:latest \
--server.address="LAN IP:28972" \
--console.address=":14012" \
--server.private-address="127.0.0.1:14022" \
--debug.addr=":6002" \
--log.level=fatal \
--storage2.piece-scan-on-startup=false
The nodes seem to start in 3 minutes, with the new command. The docker ps -a shows they start instantly, but the dashboard responds only after 3 minutes and when it loads, it shows 0min online. So I suppose the container starts instantly, but it takes 3 min to fully function properly and contact sats and show dashboard. I can’t explain what’s with this delay. Previously the nodes where starting and dashboard was responding in the first 5-10 seconds. No updates at start. Was 1.90.2 before and after restart.
And… Quick is still missconfigured 
. The other node on this machine uses unique ports, different from those listed above.
Yup, QUIC is that unimportant that the team have spent many hours implementing it and indeed adding it to the status page to tell if it is working.
In reality they recently broke it (twice) on FreeBSD which is a minority platform and nobody can be bothered to proritise investigating it, never mind fixing it.
Feel the love…
2 Likes
Yes
If you remember, the image contains only downloader and supervisor, so it downloads storagenode-updater, start it, the storagenode-updater service downloads storagenode and start it. I guess both downloads took 3 minutes in your case.
Then I guess it’s broken in this version. The weird thing that not for everyone.
The interesting bit is that the breakage is seemingly in the dependencies, not storj code itself.
But I can see why regressing this would be low priority — even when it works, usage is still small. (I vaguely remember reading somewhere that some isps and corp firewalls block quic?) That assuming they updated dependencies for the reason, not just for the heck of it. In the latter case the fix is obvious — roll those back.
TCP FastOpen should have been the move towards the same goal of reducing latency as why quic was added, so perhaps quic could be even dropped going forward.
Now that is also broke on Linux — it’s either going to get fixed or abandoned.
1 Like
The weird thing that’s broken on not all Linux, only on Synology so far.
My Windows Docker nodes doesn’t have this issue. As you may know, on Windows docker is running in the Linux VM (Ubuntu 20.04 in my case), and QUIC is working after update to this version.
We will see when all nodes will be updated.
I reported in the other thread the quick missconfig only on multinodes, but I want to add more specs, maybe something give devs a hint of what’s wrong:
- synology 1GB RAM, 2 nodes on 1 machine, both with quick misconfig.
- synology 10 and 18GB RAM, 1 node on each machine, quick ok.
All are running DSM 7 and Docker up-to-date.
Both nodes on the first machine have all unique ports each, different from default ones.
So, QUICK misconfigured happens on last storage version 1.90.2, only on multinode machines, with small RAM. Maybe it’s the small RAM, maybe it’s the multinode… Can’t tell for sure what causes the problem with the new storage version.
Me too. I have 4 tiny boxes running Armbian OS. 3 out of 4 suddenly have this QUIC Misconfigured problem upon v1.90.2
I restarted router, switch, node, still the same. I used to have this problem in the past, simply restarted node would bring QUIC back. But I have no luck this time.
I have 2 fixed IP4 lines. 2 Armbian on 1 IP, 1 box QUIC misconfigured. There are another 2 Armbian + 1 WIN10 on my second IP4, WIN10 works well, 2 Armbian both have problem.
Update: I rollback to v1.89.5, QUIC is working well now. I’m using arm version.
https://github.com/storj/storj/releases/download/v1.89.5/storagenode_linux_arm.zip
2 Likes
Same problem here. All was running just fine.
Node 1: TrueNAS Server 1 - running great
Node 2: TrueNAS Server 2 - running great
Node 3: Synology - QUIC Misconfigured. It didn’t use to be
I have checked the FW - TCP & UDP both forwarded correctly - but then I didn’t believe it would change
Single node 4GB RAM/ Monitor shows 70% RAM free
So I believe it’s a low RAM issue with QUICK on last storagenode version.
Nothing is free; it’s all used by cache and buffers. The 10GB RAM node dosen’t manifest this problem for me, and stores 10TB of data out of 14TB allocated.
1GB RAM on my Armbian. Running single node.
I also have 1 Armbian working well with 1GB RAM after upgrade to v1.90.2.
This is very confusing…
1 Like