Slowly connecting to more and more clients, there’s something oddly satisfying about looking at that, I’ll keep it up on a second screen for a couple more hours.
Enjoy the data!
Slowly connecting to more and more clients, there’s something oddly satisfying about looking at that, I’ll keep it up on a second screen for a couple more hours.
Enjoy the data!
Please update post to make it clear that Dashboard results are not specific to current user’s runs.
Thanks @ustulation
Here is the log file Dropbox - client-1539792845.log - Simplify your life
Sent you the log file in a private message, don’t know the correct procedure where to post it yet.
Looks like I’ve managed to connect sometimes, but most the time failed
Ah it’s not because you are private (mostly all of us are behind NAT so private, and that’s why the NAT Traversal library we coded) - it’s this:
Symmetric NAT with non-uniformly changing port mapping detected. No logic for Udp external address prediction for these circumstances!
That’s a very adamant router trying to defeat Holepunching and currently we don’t have a logic to beat that so IGD (if the test provided) would be the only option here.
It’s basically allocating random ports so that a prediction algorithm (like in the p2p crate) is defeated.
also from the logs there’s a wild variation:
Detected NAT type for UDP EDMRandomPort([46029, 12499, 19723])
So the code is unable to work out (predict) what could come next. So it’s giving up.
Okies heading home now - will give it a look tomo thanks a lot though and we expect to collect many more logs to analyse the pattern - so it’s going to be very helpful.
Currently staying in a hotel in Spain, connected to their WIFI and it worked.
Quick feedback: I tried to find my connection / peer? ID in the dashboard and wasn’t able to. I used this id here “Our public ID: faa802…” . Ofc it’s not the point of this test but would maybe helpful to search the dashboard for IDs to get infos about related connection attempts.
Excellent! Will give it a go later when I’m home!
Ok, so it is not because the ISP given me private adress because when I did setup a raspberry pie web-server a while back ago I had to ask for a public IP adress to get the DNS to find the Rasp pie.
This is what the router tells me, I just leave this here, don’t know it helps.
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
Awesome! Glad to finally be able to contribute something meaningful!
hmmmmmm - i may have sabotaged the results 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
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!