Hello everyone, I’m new, a greeting to the whole forum.
Before posting I searched the forum but I didn’t find a solution.
I put my first node online yesterday on Windows Server platform with GUI Ver. 1.26.3.
As soon as it was started, the node did not go online due to problems with the public IP that my provider has solved in a few hours.
Solved the public IP problem I went online and the us1.storj.io:7777 satellite disqualified me immediately, even though it’s all 100%
In the logs there are only the initial connection errors to all the satellites before solving the problem with the public IP. No “GET_AUDIT” error.
The node seems to work with the other satellites, I have read some posts that say leave them alone.
Disqualification doesn’t happen for no reason, especially so quickly. If the node is brand new then the best option is to uninstall, delete the identity and StorJ folders. Then start again with a new identity now that port forwarding is working.
Hmmmm… odd. A simple port forwarding error shouldn’t have disqualified you, as you’d only have appeared to be offline for as long as it took to fix the problem.
Someone else has reported a similar problem, albeit with a different satellite. I wonder if there is some sort of unexpected behaviour going on with the Audits.
The satellites don’t do audits at the same time, so disqualification from one doesn’t necessarily imply that the others will see the same conditions and do the same thing.
However, I don’t think we expect it to be possible to be disqualified in that short space of time from being offline. Maybe if the node was online and returning incorrect data to audits, though. That seems unlikely.
I believe we added some additional logging for audit failures on the satellite side recently. Hopefully that’s made it to production by now. If so, we can see what the satellite thought was happening. I’ll check sometime tomorrow, if no one else gets to it before me.
If you keep a copy of the node ID in case StorJ support want to check the satellite audit logs, then it should be fine to reinstall with a new identity.
Hi, I reinstalled the node as you suggested, now everything is working.
Do you wont me to write here the ID of the old node for any support checks?
Thank you
Luca
@Luca I think you’ve uncovered an unfortunate bug in how we disqualify nodes that haven’t been seen in too long. If the satellite has never been able to connect to your node, but it knows about your node because your node has connected to it, your node has a chance of being insta-disqualified. The satellite thinks, “I haven’t seen this node since the dawn of time, and that’s more than 30 days. Bam.”
We’ll be disabling stray node disqualifications for a short time until that check is fixed. In the meantime, we will need to try and find other people who were bit by this who shouldn’t have been, and see how many of them need fixing. Un-disqualification may actually be an option in this case because nodes with this problem never received any pieces to store.
Thanks @thepaul. I believe this has occurred once or twice to some other forum posters. Would it be quicker to ‘un-disqualify’ or create a new identity?
Making a new identity will certainly be faster, but I’m worried that in some cases people might have continued to run their nodes for other satellites and built up some reputation there. I suppose at the very most it would only be a few weeks’ worth of reputation, so maybe it’s not worth worrying about.
Yes, it is fixed as far as we know. It doesn’t look like you’re having the same problem, because as @kevink said, you’re not disqualified. But I’m curious why your node would show as online to all the satellites except for that one.
If you’re still having the problem (it looks like that satellite is talking to your node successfully now) I recommend starting a new thread to investigate.
