Crust Test - NAT Traversal (concluded)



Is it useful to keep it running overnight… do you want it running for days … or once it’s fairly connected with everything available, is there no added value??


Don’t forget to give the NEW article on Medium about the test being live some claps!


We should keep it running as much as we can, after it connected with all available nodes it will still try to connect with new ones joining later on, that’s what the script means when it prints “Checking for new peers every 10 seconds.”


Is it possible to register an IP address from commandline?.. just wondering if there’s any benefit in testing from a virtual server.


I also get the GLIBC_2.25 error.
I guess best to wait then. I also don’t know how to compile ‘client’ from the source code.
Unzip, current Rust version with rustup, cargo build, cargo install: nothing to install.
I’ll probably do something wrong here.


Great work! I am connected to a lot of you :yum:


Awesome! Glad to finally be able to contribute something meaningful!


hmmmmmm - i may have sabotaged the results :roll_eyes: i at first started the test in a VM that was connected through NAT …


Listed as failed and successful…?

Also, would it be possible to increase the number of peers listed on the crusttest.maidsafe page? It’s kinda tedious to click through several pages to see the scale of this swarm :yum:
It would be nice to be able to just scroll down the list to show off to friends. Like BAM! look at just one of the component of this beast and the diversity of the participants! :star_struck:


eeeeeh - is that kip drordy in the list of peers? :thinking:


UDP punching is shining. The test is averaging well. Bravo for now! :clap: :sunglasses:


MacOX 10.14

I tested the client with my firewall (little snitch) blocking incoming connections and allowing incoming connection at an application level.

blocking incoming connections:
It’s about a 70% failure rate.

allowing incoming connection:
90% success rate.

Not sure if this is helpful, would you be able to improve the results for misconfigured firewalls?


The third time oetyng is listed…thats in the “attempted connections”, which seems to be Successfull connections plus Failed connections.


Its listed as failed and attempted, there are three lists, succesfull, failed and attempted.

edit: ninja’d by 5am


Wow just wow just wow just wow


Connections from china are failing utterly. No bueno. :sob:


is that a result of your test? or just the dashboard-result?

(the test connections are random-port - aren’t they? Oo)


oetyng is showing as successful atm on mine as d1845e… so, perhaps that snapshot caught as it transitioned from success to the list of “failed” that seems more an archive of old instances. I have my second instance that was successful and shutdown listed in the fail of first instance still.

I wonder it’s the successful connections and the sustaining of those that’s most interesting … the “failed” perhaps is just old instances … those which never did connect, perhaps are not visible??.. unless there is some fake bridging to help those be listed… some “I’m going to try to connect” would be needed to know what is failing??

(btw: I don’t know what confusion is caused by having more than one per IP)


I’m also getting the GLIBC_2.25 error on Debian 9
ldd --version
ldd (Debian GLIBC 2.24-11+deb9u3) 2.24

Probably out of luck. Will try on Windows


We’ve succeeded with vaults in China in the past I wonder why now. Need more people to try. On the dashboard I see a lot of US failures. Still things are looking damn good.