yes, but with some kind of throttle grey-list - it’s likely be expected.
So I would check these options on the router or firewall or antivirus.
By the way, there is no point to check the node’s activity - all data is encrypted anyway and your node stores only 1/80 piece of the segment (!) of the file. Just waste of CPU cycles on checking its activity.
Oddly, it’s been up for 9 hours now and QUIC is ok. No idea at this point.
after it went misconfigred last night I restarted. Now it’s been green for 17 hours. I genuinely don’t think it’s an issue on my end.
mixed bag today. I’ve tried a few things but can not pin down a root cause.
I’ve been checking the firewall and port forwarding, the OS that the docker container is on and Storj. Nothing is standing out and I’m still fighting this issue.
Does it online? If it’s offline, you need to fix the offline issue first:
It should connect in seconds. There are a few things you should check.
Start with checking the port. On
https://www.yougetsignal.com/tools/open-ports/?port=28967 you can fill in the domain or IP you are using in the run command. Then check the port.
If it’s closed, it could still be several things.
Make sure the WAN IP you see in your router settings matches the IP shown on the above page.
Make sure your port forward is set up correctly. That means no filter on incoming IPs, forwarding to th…
28967 is open, port forwarding is set up correctly as far as I can see.
Does it showed as online on the node’s dashboard?
Do you have other nodes in your network?
Just the one node, nothing else.
When QUIC is misconfigured and I check the logs, I see active up/downloads scrolling past. That seems strange…
Not at all. QUIC just a preferred protocol, but if it doesn’t work the usual TCP (slower) connections will be used.
Is there a way to ping 28967 on my home IP and do something like a tracert to see where it’s getting filtered?
Yes, you may use a
nc utility in Linux to check the connection to a specific port and protocol.
nc -zvu your.external.address 28967
Download the Free Nmap Security Scanner for Linux/Mac/Windows
But it’s not a
tracert of course.
In Linux you may use a
traceroute command, it uses UDP by default
traceroute your.external.address -p 28967
UDP traceroute utility – Chris Lloyd
28967 is open on the WAN side but when I scanned my router 28967 is closed internally.
This is mean that something other listening this port.
Do you have two routers?
I do not know why you scanned your router internally instead of your node though.
Could you please show how you did that?
my public IP scan shows 28967 open
scanning my node internally shows 28967 open
scanning my router internally shows 28967 closed
of course, because your node is listening the port, not the router.
cool cool. Anyway I’m still not able to identify the issue. It seems to me that 28967 is open from WAN to the node yet QUIC still goes down regularly…