My firewall table rules do allow existing connections, but I guess this test client closes connections and reopens only when needed, so it was stymied and panicked.
maidsafe team – what is a good ip-tables rule or ruleset to use to allow this test and maybe the future network? Or will we in the future just set a general rule like I do for Tor? e.g. :
-A OUTPUT -m owner --uid-owner debian-tor -j ACCEPT
I wonder about this as I’ve never been able to get any torrent client to work with a decent firewall and I suspect the safe network will be more akin to a torrent client than Tor or I2P networks.
I’ve been running the test on a third Mac with 10.13.6 installed (different to the two I tried yesterday) and it worked first time and I’ve left it running for a couple of hours so far, will keep it on. Results seem in line with the average but UDP HP is far more successful that the other methods for me:
Hey @Vort
100% success means you have been succesful in connecting with every other person you have attempted to connect with. If you filter by your name and scroll down to the table you will see more detail for each connection
That is strange, because I was expecting that incoming connections will have 100% success rate, not outgoing (not my PC trying to connect, but others).
I must be goin blind. Where did that orange refresh button come from?
I know the browser was not wide enough and it wasn’t showing one the screen. Damn these wide web pages
Feature request: Put orange refresh button on left hand side for those of us who do not have their browser full screen, since they actually use their computers for computing rather than browsing
Successful connections: [“NSA (3bcaba…)”, “jpl-win-vpn (5d090b…)”,… I see US national agencies are big on Crust testing We should contact JPL guys to help launch SAFE Network mainstream once it’s ready
The filters are correct, it’s just that we haven’t seen any EDM NATs so far (which is a bit surprising to me personally – I expected to see more of them!)
We keep track of this data but it’s not displayed on the dashboard because there’s not much to display really – with random ports/IP addresses it’s virtually impossible to predict a next port number and thus connections with hole-punching are not possible. However, if IGD succeeds, the client will proceed with direct connections only.
Ah no, it does not. We don’t use HTTP for this test: all communications are going through TCP/UDP sockets, so unless your HTTP proxy also provides a system-wide SOCKS5 proxy, it should be all fine.
It’s possible if Symmetric NAT with randomised IPs/ports has been detected. You can confirm that by looking into the log file with a name like client-123xxxxxxx.log, if closer to the end of the file it says something along the lines of RendezvousFailed, then that’s the case.