I’m now seeing the IDG error on my cloud node which has a fixed IP! Is this a bug?
[sn_node] INFO 2021-06-18T18:20:03.834330310+02:00 [src/bin/sn_node.rs:124] The network is not accepting nodes right now. Retrying after 3 minutes
[sn_node] ERROR 2021-06-18T18:23:14.200216544+02:00 [src/bin/sn_node.rs:138] Unfortunately we are unable to establish a connection to your machine (95.216.206.201:35323) either through a public IP address, or via IGD on your router. Please ensure that IGD is enabled on your router - if it is and you are still unable to add your node to the testnet, then skip adding a node for this testnet iteration. You can still use the testnet as a client, uploading and downloading content, etc. https://forum.autonomi.community/
True, it’s like shooting yourself in the head and also having a cold Timeouts will cause undefined behaviour in a decentralised network. From there it’s hard to know what happened because of it.
I expect huge delays here and likely all testnets. You see folk get money for nothing and upload data like mad and it all happens in a rush. So it’s where we will see extremely busy networks and if they are so busy they slow down then that is good. I suspect we also need to make sure nodes reconnect on disconnect if they are waiting on some data. We may have a place where we don’t with all the feedback though we will get those things.
Just uploaded the usual run of 35 simple sites
via script took roughly two hours for ~[179 items, totalling 57.1 MB]
and roughly 40mins to do the NRS create after the basic upload.
List of those below that I’ve not checked but option to check stability and download speeds against:
safe://hello
One oddity I didn’t make sense of was user error NRS create for three sites and only the third complained I should use add… unclear why the second didn’t.
1 - safe://play.chess
2 - safe://savant.chess
3 - safe://voyeur.chess
I imagine that without additional configuration, the IGD request should go through and naturally fail but the node would still be contactable (since public IP) and so the simple safe node join should do the trick now that I think of it more
The above seems to have the quotes in the wrong place (see below) and following it my ‘corrected’ version which fails for a different reason:
$ ~/.safe/node/sn_node --root-dir node_data -h "["\188.166.156.250:44267"\]" --skip-igd -vvvv
error: Invalid value for '--hard-coded-contacts <hard-coded-contacts>': invalid type: floating point `188.166`, expected socket address at line 1 column 8
$ ~/.safe/node/sn_node --root-dir node_data -h "[\"188.166.156.250:44267\"]" --skip-igd -vvvv
[sn_node] INFO 2021-06-18T18:40:54.727111654+02:00 [src/bin/sn_node.rs:112]
Running sn_node v0.49.8
=======================
Cannot start node due to error: Io(Os { code: 13, kind: PermissionDenied, message: "Permission denied" }). If this is the first node on the network pass the local address to be used using --first. Exiting
[sn_node] ERROR 2021-06-18T18:40:54.727379423+02:00 [src/bin/sn_node.rs:149] Cannot start node due to error: Io(Os { code: 13, kind: PermissionDenied, message: "Permission denied" }). If this is the first node on the network pass the local address to be used using --first. Exitin
So if node shows sometimes Retrying after 3 minutes and sometimes Unfortunately we are unable to establish a connection, then connectivity test have a bug, right?
sascha@Knut:~$ time safe files put Safe_Put_Cat/Safe_Nugget.png
FilesContainer created at: “safe://hyryyrbqseoe149jo5qxaom8yzr639ehhjtr8ufohc171grwaa3gkbhf97enra”
The download inconsistency + timeout is something we haven’t come across yet, so will be interesting to see what’s afoot there.
I’m wondering if the nodes being hammered for uploads (and all that GetHistory ) is slowing everything down there (and so we’re hitting the client timeout at the mo )
Timeouts will cause undefined behaviour in a decentralised network. From there it’s hard to know what happened because of it.
)