Crust Test v2 (concluded)


#1

Following the success of the first Crust Test a couple of weeks ago we can now continue along the path toward the SAFE-FLEMING milestone, with the second iteration of the crust p2p test. This incorporate the following improvements to the networking libraries:

  • Enable direct connections
  • Improve dashboard performance
  • Enhance dashboard filtering to include:
    • AND/OR between the connection types: Direct, TCP HP, UTP HP
    • Filter by user (Public Key & option ‘name’)

After your fantastic support during the last test, we would like to get your involvement once again - by running this new test you can play your part in making history!

This tutorial will guide you through the following:

As results arrive and issues are logged new versions of the apps will be released to continue to improve these findings. We’ll let you know and ask you to run again.

If you’d like to hear more about the Crust test and a lot more @fergish from SAFE Crossroads has been speaking to @nbaksalyar about the Crust Test in
SAFE Crossroads #45, Approaches to SAFE-Fleming (Alpha-3).


Before running the test

There are a few steps that you have to follow before being able to connect to the test network.

  1. If you don’t already have one then you’ll need a SAFE Network Forum account.
  2. Once you have registered the account you’ll need to have reached Basic Trust Level 1.
  3. You’ll need to then register your IP address to get an invite to the test.
    Note: if you were registered for the 1st test you’ll still need to do this step as we’re starting afresh
  4. Now we’re ready to download the test.

That’s it!


Running the test

The test is a simple application that lets you connect to other peers running the test. To run it all you need to do is:

  • Run the client executable. (MacOS users Read this first).

  • Enter a name - this can be real or made-up (optional) and will be visible to others on the dashboard. I’ve entered “DGeddes”. Pressing the Enter key will allow the client to start looking for peers to connect to.

  • … that’s it - you are connecting to peers and participating in the test!

  • Leave the client running for as long as you are comfortable with. The longer it runs the more peers it will find and connect to.

The application then collects your NAT (router) type, operating system, confirms what protocols are supported and then starts to look for other available peers to connect to.

If others are participating in the test at the same time, you will see connection attempts being made, whether these are successful and the type of connection made e.g. TCP-HP, UDP-HP or direct.

The app will notify you when all known peers are connected to, and then will check for new peers every 10 seconds.

When the test is concluded the client app will say so.


The Crust Dashboard

The Crust Dashboard shows you the results of the test so far and displays the peer-to-peer connections that have taken place. You’ll see the number of connections and their success rate.

There are 3 main sections to the dashboard:

  • Filter - controls what results are displayed on the chart and the table, options are:
    • NAT Type
    • Operating System
    • Country
    • User (inc. yourself)
  • Chart - shows the percentage of successful connection attempts for each protocol
  • Table - shows connection attempts in more detail based on the filter
Crust NAT Traversal Dashboard

Please note the dashboard is designed to be viewed on desktop computers and viewing on lower resolutions (tablet/mobile) may result in a less than perfect experience.

What’s shown on the table?

The table on the dashboard shows the following content for each attempted connection:

# TCP HP UDP HP NAT Type Operating System Country
Unique identifer Connection attempt result Connection attempt result EDM / EIM Linux / MacOS / Windows Geographic location (derived from IP Address)

What do these terms mean?

Term Description
TCP HP Hole punching via Transmission Control Protocol (TCP)
UDP HP Hole punching via User Datagram Protocol (UDP)
NAT Type Network Address Translation enables a device to connect to the internet (through your router). Types available are: EDM & EIM.
EDM Endpoint-Dependent Mapping (EDM) involves our external address changing depending on the remote endpoint we are talking to. Most routers have a fixed offset they use when changing the address so can be predicted.
EIM Endpoint-Independent Mapping (EIM) allows the device to accept incoming traffic to a mapped public port from ANY external endpoint on the public network.

Showing MY results only

Using the “Filter By User” option we can narrow the dashboard results down to our own connections only. When text is entered into the include filter box we’ll see a dropdown of available IDs appear and we can select ourselves.
Filter By User

Note the Public ID is displayed in brackets after the public name - this is the same as displayed in the test client.


Showing results for multiple specified users

It’s possible to specify more than one user to view the results of. All we have to do is add them, one at a time, into the “Include” box. Here I’ve shown the results of myself and 3 other lucky souls.

Duplicate results

If multiple clients are run from the exact same environments (same IP Address, Operating System, NAT Type, TCP HP Result, UDP HP Result & Direct Result) then the results will be considered a duplicate and the results will be ignored (i.e. not recorded). This is also true if the peer_requester and peer_responder have been swapped.
If the clients have any differences in their environments (e.g. NAT Types) then the results will not be considered duplicates and will be recorded on the dashboard.


Privacy Policy

For the test we record the currently active IP address of your login in order to avoid spamming attempts.
When running the test application client you’ll see your end-point info (IP address and port number) and the end-point info of any peers you are directly connected to.
The dashboard also uses the IP address to determine the country the client is connecting from via the geolocation service ipapi.co who store the IP address for 6 months from the start of the programme.
If you would like to learn more then please see maidsafe.net’s Privacy Policy.

Cookie Policy

The invite server (crusttest.maidsafe.net) creates a single cookie once the user has been authenticated using their Forum account. The cookie contains the following information:
Session ID
If you would like to learn more then please see maidsafe.net’s Cookie Policy.


Giving Feedback

As always, we’re keen to hear from you so if you have any feedback on the client application, dashboard or overall test process please just reply to this post. Also, if anything isn’t as clear to follow as you’d like it to be, or you have run into a problem, then let us know below.


Frequently Asked Questions

How long is the test scheduled to run for?

This is another exciting bit… we don’t really know! The test will be running for only as long as it takes to get the results we need in order to see the effectiveness of using different methods across protocols. This is where you can really make a difference by getting involved - imagine being able to say:

“I was part of the test programme that shaped the future of the internet!”

Don’t wait around - get involved while you can and run the test.

What is the Client Application?

An executable which users download and enables two peers to connect to each other, via the proxy node. The proxy node is the hard-coded contact which all peers bootstrap to, and it also receives the connection attempt results from the peers in the test.

What operating systems are supported?

The client application is supported on the following operating systems:

  • MacOS 10.13 (or higher)
  • Windows 10 x64
  • Most up to date Linux distributions

Why is there a warning downloading the zip using Chrome browser?

If you are using Google’s Chrome browser you might see a warning message when downloading the zip. The message states that the zip “is not commonly downloaded and may be dangerous” and you’ll be given the option to Discard or to Keep. Just click Keep to allow the download to complete.

We’ve seen this on Windows and on MacOs and are looking into it to see if we can avoid this in future.

Why do I see ‘“Client” can’t be opened because the identity of the developer cannot be confirmed"’ on MacOS

On MacOS you can expect to see a pop up that warns that the client executable “can’t be opened because the identity of the developer cannot be confirmed”.
mac
The software has in fact been signed but because the client is a Unix executable rather than a packaged Mac app it is flagged by the system. To resolve this:

  • In the Finder, go to where you downloaded and unzipped the client.
  • Control-click the client icon
  • Choose Open from the shortcut menu.
    The app is now saved as an exception to your security settings, and you can open it in the future by double-clicking it just as you can any registered app.

To confirm the executable has been signed by MaidSafe you can open a terminal and in the same folder as the executable run:
$ codesign -dvvv client

We provide the checksum for all our zip files so users can be assured that they are approved by MaidSafe.

We’ll be looking to see if we can improve on this as we move forward.

What data is captured by the Client application?

  • IP address and port number
  • NAT type
  • Operating System
  • Protocol method
  • Time to successful connection
  • UPnP support check

NAT type, OS, protocol method along with connection attempt results are sent to the dashboard for display. More granular data, such as successful connection time and UPnP check, is logged for detailed debugging, but is not publicly accessible.

How long should I leave the client running?

The longer the client is running the more peers it can connect with but it’s completely up to you how long you want to run the test for. MaidSafe will have peers running for the duration of the test.

Why do I need an Invite?

By registering your IP address at the start of the process, your IP address is recorded by the hard coded contact (the proxy node). Then when you run the client application, your IP address is matched with that on the proxy and you are authorised to the test. This is how we prevent spamming attempts.

What is the Crust Dashboard?

The Crust Dashboard allows anyone to view the crust connection results in a meaningful way. It does not display all data received link to ‘what data is captured by the client application’

What database is used?

A MongoDB database is used to store the connection results received from the test.

What’s in the ZIP File?

There are 4 files included in the downloaded ZIP file:

  • client: This is the client application that the user runs to connect to others in the test.
  • client.crust.config: This is the main configuration file which defines some essential parameters for the client application including the hard-coded contact.
  • log.toml: This file configures the output content and format of the log file.
  • p2p-config: Additional configuration file which lists some hard coded contacts and hole-punching and rendezvous options.
    An additional 2 files are created when the client runs.
  • client-##########.log: This is the log file which collects all connection activity (such as attempted, successful and failed results).
  • client.bootstrap.cache: This is for future use when we connect with multiple proxies (currently there is only one proxy).

What is my end-point info?

When your node connects directly to another node you can see their end-point info within the console app. The end-point info is:

  • IP Address
  • Port number

Conclusion of Crust Test (v2)
SAFE Network Dev Update - November 1, 2018
Pre-Dev-Update Thread! Yay! :D
What’s up today?
#2

Was just about to spoil the surprise with this https://github.com/maidsafe/crust/releases/tag/crust-test-0.2.0 in the pre dev update thread. Ah shucks. Will be joining tonight!


#3

No spoilers @Nigel - it’s like the unwritten Breaking Bad rule!


#4

I’m successfully connected to everyone! Very exciting!


#5

19 connection attempts, 100% so far!


#6

I’m at 22/22 so far:) Shout out to anyone currently connected to kip(a15db6)


#7

Connected :slight_smile:


#8

Second time the test works fine on Windows 7 SP1 x64.
Why this platform it is not listed as supported?


#9

It seems like the test is making connections superfast this time!! :tada::sparkler:


#10

Very exciting to see so many different countries that is connected, even having good connecting with China 97%, only Hong Kong seems problematic with 0% at this moment.


#11

If you see Jeremy thats meee :smiley: . Will leave it up and running this was just the first 2 mins.

Edit: So after running 2 hours I see 60%, not terrible but I wonder why some people reach 100% and others run into so many connection roadblocks.


#12

Hey @Vort, as I understand it, the test can work on older versions of Windows - but we’re not supporting it as such


#13

Thanks. I hope final release will support Windows 7 officially, since it still have a lot of users (40% or so).


#14

So far 50/50 results using MAC OS on first try, then crash. Restarted and now its 99/1 for successful connections! amazing to see this happening so successfully already.


#15

Hello guys, i got a problem. It reports me this error:

Rendezvous with server failed for both Tcp and Udp - could not obtain our external address

Could you help me please?


#16

And we’re testing again :slight_smile:
NAT Type = EDM not used until now, or something incorrect in the filtering?
And ‘EDM random’ is mentioned in OP, but not in the filter options on the crusttest page.
Is see that Successfully_is_spelled_with_2_c_characters isn’t needed anymore :wink:


#17

Up and running again.


#18

Same as last time, but that was to be expected

nullINFO 19:00:03.492672093 [client client.rs:1202] Our public ID: 1d6607..
INFO 19:00:03.492697628 [client client.rs:1204] Attempting bootstrap...
INFO 19:00:03.541477633 [client client.rs:1225] Connected to 8f6155.. (104.248.175.190:8000)
INFO 19:00:03.590031270 [client client.rs:776] Detecting NAT type...
INFO 19:00:03.647327259 [p2p::tcp::hole_punch mod.rs:222] Symmetric NAT with non-uniformly     changing port mapping detected. No logic for Tcp external address prediction for these circumstances!
DEBUG 19:00:03.647344671 [p2p::tcp::hole_punch mod.rs:188] Terminating due to: TcpRendezvousFailed
WARN 19:00:03.679621154 [p2p::udp::hole_punch::rendezvous_client rendezvous_client.rs:163] Symmetric NAT with non-uniformly changing port mapping detected. No logic for Udp external address prediction for these circumstances!
WARN 19:00:03.681062223 [p2p::udp::hole_punch::rendezvous_client rendezvous_client.rs:163]     Symmetric NAT with non-uniformly changing port mapping detected. No logic for Udp external address prediction for these circumstances!
WARN 19:00:03.682990297 [p2p::udp::hole_punch::rendezvous_client rendezvous_client.rs:163] Symmetric NAT with non-uniformly changing port mapping detected. No logic for Udp external address prediction for these circumstances!
DEBUG 19:00:03.683003001 [p2p::hole_punch hole_punch.rs:401] Terminating due to: RendezvousFailed
DEBUG 19:00:03.683009534 [p2p::udp::hole_punch mod.rs:166] Terminating due to: UdpRendezvousFailed
INFO 19:00:03.683040099 [client client.rs:786] Detected NAT type for TCP EDMRandomPort([46419, 46417, 46418])
INFO 19:00:03.683049077 [client client.rs:787] Detected NAT type for UDP EDMRandomPort([55251, 55248, 55250])
INFO 19:00:03.683054817 [client client.rs:790] Detected OS type: Linux
INFO 19:00:03.683060143 [client client.rs:792] IGD failed
TRACE 19:00:03.683063550 [client client.rs:851] Sending UpdateDetails
ERROR 19:00:03.683112322 [client client.rs:1024] 

Failed to collect our connection information. Error description: Rendezvous with server failed for both Tcp and Udp - could not obtain our external address
Please try again later and if the error persists please contact us and send the log file.

Press Enter to continue...

#19

I had similar problems last test. For me it was because of the ISP solving the shortage of ipv4 adresses, they seems to use the same ip for more than one customer. So it was not an ip direct to the internet from my router, it was sent through the ISP which has like it’s own router giving it another ip adress. So the test thinks it is trying to hole punch your router but it is kind of like it is trying to hole punch the ISP’s router (cg carrier nat, aka, cgc/nat). For me the problem got solved when I asked the ISP for a public ipv4 adress. Disclaimer I’am not an expert and may be corrected by others. :slight_smile:


#20

Thank you for the answer @tobbetj
How to ask for a public ipv4 address? That’s so disappointing that i can’t connect…