IPv6 node no longer working

So, I configure an IPv6 node and previously would just fine. The was practically no data stored but it was always online. After recent updates it simply refused to get back te the online state.

tempts": 8, “error”: “ping satellite error: rpccompat: dial tcp 78.94.240.189:7777: connect: connection refused”, “errorVerbose”: “ping satellite error: rpccompat: dial tcp 78.94.240.189:7777: connect: connection refused\n\tstorj.io/common/rpc.Dialer.dialTransport:211\n\tstorj.io/common/rpc.Dialer.dial:188\n\tstorj.io/common/rpc.Dialer.DialNodeURL:148\n\tstorj.io/storj/storagenode/contact.(*Service).pingSatelliteOnce:124\n\tstorj.io/storj/storagenode/contact.(*Service).pingSatellite:95\n\tstorj.io/storj/storagenode/contact.(*Chore).updateCycles.func1:87\n\tstorj.io/common/sync2.(*Cycle).Run:152\n\tstorj.io/common/sync2.(*Cycle).Start.func1:71\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57”}
2020-10-09T12:06:20.619930620Z 2020-10-09T12:06:20.619Z ERROR contact:service ping satellite failed {“Satellite ID”: “118UWpMCHzs6CvSgWd9BfFVjw5K9pZbJjkfZJexMtSkmKxvvAW”, “attempts”: 9, “error”: “ping satellite error: rpccompat: dial tcp 78.94.240.189:7777: connect: connection refused”, “errorVerbose”: “ping satellite error: rpccompat: dial tcp 78.94.240.189:7777: connect: connection refused\n\tstorj.io/common/rpc.Dialer.dialTransport:211\n\tstorj.io/common/rpc.Dialer.dial:188\n\tstorj.io/common/rpc.Dialer.DialNodeURL:148\n\tstorj.io/storj/storagenode/contact.(*Service).pingSatelliteOnce:124\n\tstorj.io/storj/storagenode/contact.(*Service).pingSatellite:95\n\tstorj.io/storj/storagenode/contact.(*Chore).updateCycles.func1:87\n\tstorj.io/common/sync2.(*Cycle).Run:152\n\tstorj.io/common/sync2.(*Cycle).Start.func1:71\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57”}

I would not have expected an IPv6 node to rely on IPv4 satellites but this is what appears to be happening.

Any ideas?

1 Like

The stefanbenten satellite used to be the only satellite to support IPv6, that has since been shut down. At this point you can only get data over IPv4.

The storagenode still can get traffic via IPv6, if the client use a dual-stack connection, since data transfer is performed between client and storagenode directly.
But the storagenode should have a dual-stack too to communicate with remained satellites

It does not need to.
At some point IPv6 needs to take over as we run out of IPv4 addresses.

Also the DDNS address has to advertise both IPv4 and IPv6, which most providers do not.

Thx, guess I’ll need to allocate some time to figure out why my IPv6 node suddenly stopped working. I kinda did not expect an IPv6 node to refer to IPv4 satellites. I can’t come up with any valid reasons for such a design. Can you guys share any insight on this?

I don’t quite understand your question.
My satellite was indeed the only Satellite at this stage being capable of speaking IPv6.

As this satellite is shutdown now, you are correct in assumption, that your node is unlikely to be able to participate in the network currently. The biggest problem here are audit and uptime checks failing for the IPv4 only satellites.

I already brought this issue up
Internally months ago and reiterated on it Friday to find a way forward.

1 Like

I did not realize that your node was the only one speaking IPv6 currently.
Sorry for the noise and thanks again.