yes sorry, if that is not important
The Linux binary might be incompatible with some older/stability-inclined distributions, so e.g. it might run on Ubuntu 18.04 or Fedora 28 but not on Ubuntu 16.04 or Debian 8.
I’ll see what we can do, thanks!
Yes, just spotted “Ubuntu 18.04 x64 (or higher)”… using an older 17.3 so perhaps time to update unless there’s a shortcut to try… just doing the update of what exists to try again.
Not a worry, this is a pure NAT traversal test, we have not even used all methods here, just hole punch. It is looking great so far. I suspect anything north of a 60% pass rate here will be amazing and excellent. Then if we add in uPnp and port forward, plus direct connections we should be well over the limit where we do not need tunnels (I imagine if we get over 80% in total connections we will be solid, but it has yet to be proven).
Sounds Great Thanks @dirvine
We’ll need to take it on a case-by-case basis to see what router you have etc. In general, if your router tries very hard to not allow NAT Traversal then it’ll fail. UPnP is one of the options after that. We are also trying to find out how many ppl have UPnP enabled routers so that should give us a good indication of how many failures would actually have succeeded in a full blown test (which include IGD port-forwarding, but not in this test as we want to see what’s the worst case we are looking at).
If you can give me you log file though (if you didn’t run multiple times there should be just one else you can give the most relevant one, whichever run you think was most relevant and check the timestamp of the log file) I could go over that tomo and get some info about what’s happening.
Btw the dash is global - it does not identify the viewer only - it’s like everything from everybody
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.
Here is the log file https://www.dropbox.com/s/bd1yarouewugstu/client-1539792845.log?dl=0
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!