With the testnet tool, you should be able to run ./scripts/logs to download all logs from all nodes you have created
To get more folk joining faster, you may want the intial nodes to be built w/ less storage space, or perhaps even the node bins built with always-joinable flag
Iām not using AWS so when I try that it does not work. (I suspect thatās why?)
I do have an aws s3 bucket set up but that is a convo and help Iāll need in the other thread I guess.
Just ran in to restart, I am busy remodeling my workspace/shed/office but am more than happy to continue working out the kinks. 
Ahh, yeh thatās fair.
Probs those scripts could/should be updated to run without the need for syncing to/from s3. Opt out at the very least. 
Keep up the good work (on sheds+testnets!)
large files are probably still problematic.
At the moment the blob cache is removed so we can more readily see underlying issues, and weāre working on those and without this, it only takes one chunk fail to break your large file retrievalā¦
eg, at the mo thereās still more AE retries for PUTs than youād wantā¦ Which means a chunk can sometimes fail to be put during the span of our tests.
And right now we still dont verify PUT data as part of the CLI funcs, so until youāre able to retrieve the file, you cannot really assume that itās all stored properly Iām afraid.
That shouldnāt be much to verify + retry for missing chunks eg. But itās another thing on the list basically! So until thatās it, you should retry your PUTs if your GETs fail.
I did not measured, but between cat activity stopped and error appeared, about 1 hour of time passed.
Retries under these circumstances may be problematic.
these (not so helpful errors; which i think will be refactored out of qp2p in the not too distant future), are just saying that some connection timed out.
That can happen if eg, a client or node disconnected in a less than graceful fashion (ie the process was force quit).
So not something to worry about per se. (Though if they can be tied to a specific instance of a node/client and buggy behaviour there, itās good to knowā¦ but thatāll likely be hard on an open testnet)
Solved if I SSH in yes but not if I use their browser console. 
seems odd so Iāll put that down to user error too.
Iām getting timeouts now - using the exact same command as worked previously
May not be related to large files then.
me too 12345char
I canāt connect. Am using the updated command from the OP:
RUST_LOG=info $HOME/.safe/node/sn_node --hard-coded-contacts '["178.62.57.96:12000"]' --genesis-key 8a551b912e8f08ce6a6440b324d1b0e42e304957cd01642ba628138c63e89242a03412460639774ac5c6cbcad0c08edb --local-addr 165.227.228.183:0 --skip-igd
Starting logging to stdout
Oct 06 19:23:53.322 INFO sn_node:
Running safe_network v0.32.0
============================
Oct 06 19:23:53.325 INFO safe_network::routing::routing_api: 3219b9.. Bootstrapping a new node.
Error:
0: Cannot start node. If this is the first node on the network pass the local address to be used using --first
1: Routing error:: Cannot connect to the endpoint: Failed to bind UDP socket
2: Cannot connect to the endpoint: Failed to bind UDP socket
3: Failed to bind UDP socket
4: Address not available (os error 99)
Location:
src/bin/sn_node.rs:201
I didnāt mean to imply large files == timeouts before.
Just that you shouldnāt expect large files to work atm (or at least: i donāt 
)
Unclear the state atm but 1.3MB upload fell over with some error I canāt parse:
Error:
0: e[91mNetDataError: Failed to get current version: NetDataError: Failed to read current value from Register data: NoResponsee[0m
Location:
e[35m/rustc/c8dfcfe046a7680554bf4eb612bad840e7631c4b/library/core/src/result.rse[0m:e[35m1897e[0m
Backtrace omitted.
Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.
I am going to restart 1 more time with reduced max_capacity as suggested by @joshuef but mostly so that anyone who has not had time to play and would like to, can.
If you can keep your node logs to debug any of this timeout lark thatād be suuuper 
ok, I grabbed them, let me know where to put/send them.
(Three nodes had no logs)
Take 3 is up!
upload and dog are fast
but cat is stalling and giving nothingā¦
There should be the 1.3MB safe gif at
safe://hygoynyybecgepgc4d1rbz1qa9r3hhr5hozhdg47uguqo5a53iptdntbukx5y
safe dog safe://hygoynyybecgepgc4d1rbz1qa9r3hhr5hozhdg47uguqo5a53iptdntbukx5y
== URL resolution step 1 ==
Resolved from: safe://hygoynyybecgepgc4d1rbz1qa9r3hhr5hozhdg47uguqo5a53iptdntbukx5y
= File =
XOR-URL: safe://hygoynyybecgepgc4d1rbz1qa9r3hhr5hozhdg47uguqo5a53iptdntbukx5y
XOR name: 0x430c86999a1c881bc9d8f933ce137c85f8336bb334dd0de379ab6231443353f6
Native data type: PublicBlob
Media type: image/gif
yes I canāt cat it either.
I can cat my test file though.
safe cat safe://hygoygyybtrdgdisz1u9my5wpthjg8ziuw4sc7xatmnt85yn7yj5m7gkc5mgy > 12345.jpeg
Test is overā¦ for now.
Blast! Missed the fun. Iāll be waiting in the wings.
I went through the logs for the second iteration, below is all that I can find.
root@alpha-safe-node-2:~/logs# cat sn_node.log.2021-10-06-15
ātimestampā:āOct 06 15:27:16.923ā,ālevelā:āERRORā,āfieldsā:{āmessageā:āError encountered when handling command: UntrustedProofChain("provided proof_chain doesnāt cover the SAPās key we currently know: SectionAuthorityProvider { prefix: Prefix(), public_key_set: PublicKeySet { public_key: PublicKey(1082ā¦b98a), threshold: 1 }, elders: {497347(01001001)ā¦: 159.65.48.36:12000, d3587d(11010011)ā¦: 178.62.57.96:12000} }")ā},ātargetā:āsafe_network::routing::routing_api::dispatcherā,āthreadNameā:ātokio-runtime-workerā}ātimestampā:āOct 06 15:36:57.265ā,ālevelā:āERRORā,āfieldsā:{āmessageā:āSending message (msg_id: MessageId(7639ā¦1831)) to 47.202.65.195:38087 (name 949436(10010100)ā¦) failed with Some(ConnectionLost(TimedOut))ā},ātargetā:āsafe_network::routing::core::commā,āthreadNameā:ātokio-runtime-workerā}