Crust Test v2 (concluded)


#61

Things are chugging along nicely now but i did get this on second attempt after I remembered to update my IP.

!!!
! unwrap! called on Result::Err !
!!!
examples/client.rs:1153,9 in client

Err(RendezvousFailed)

', /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/unwrap-1.2.1/src/lib.rs:67:25
note: Run with RUST_BACKTRACE=1 for a backtrace.
thread ‘main’ panicked at ’

!!!
! unwrap! called on Result::Err !
!!!
examples/client.rs:1149,5 in client

Err(Disconnected)

', INFO 18:51:26.102629000 [client client.rs:975] Attempting to connect with Hunter-Oakland-CA-USA (9092fe…)…
/Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/unwrap-1.2.1/src/lib.rs:67:25
thread ‘main’ panicked at ’

!!!
! unwrap! called on Result::Err !
!!!
examples/common/event_loop.rs:157,9 in client::common::event_loop

Err(Any)

', /Users/travis/.cargo/registry/src/github.com-1ecc6299db9ec823/unwrap-1.2.1/src/lib.rs:67:25
stack backtrace:
0: 0x10a25725f - std::sys::unix::backtrace::tracing::imp::unwind_backtrace::h6860ca4858977c58
1: 0x10a24237d - std::sys_common::backtrace::print::hfce447bb77721cd1
2: 0x10a25a3d3 - std::panicking::default_hook::{{closure}}::hdd7beb2b33ee8274
3: 0x10a25a15c - std::panicking::default_hook::h52d496fea38543eb
4: 0x10a25ab07 - std::panicking::rust_panic_with_hook::h4cb31c29ed859698
5: 0x10a25a66c - std::panicking::continue_panic_fmt::hdc9c02c39882ac1b
6: 0x10a25a5c0 - std::panicking::begin_panic_fmt::h6f0a654c9f833339
7: 0x109ece197 - <core::result::Result<T, E> as unwrap::VerboseUnwrap>::verbose_unwrap::h071232edf29381b9
8: 0x109f11745 - <client::common::event_loop::El as core::ops::drop::Drop>::drop::h7c294cbcb87c71d0
9: 0x109eaf813 - core::ptr::drop_in_place::h61e88d5aea73c2c1
10: 0x109ec107f - client::main::h00c99b1cab910277
11: 0x109ed5f25 - std::rt::lang_start::{{closure}}::hf502dd4a85aa71f5
12: 0x10a25a4d7 - std::panicking::try::do_call::hdc4508fe181791f6
13: 0x10a26649e - __rust_maybe_catch_panic
14: 0x10a24bf1c - std::rt::lang_start_internal::h6d6c64041629047f
15: 0x109ec130b - main
thread panicked while panicking. aborting.
Illegal instruction: 4
logout
Saving session…
…copying shared history…
…saving history…truncating history files…
…completed.

[Process completed]

Mac OS Mojave


#62

Wow, 100% success rate (41 connections, 7 TCP HP, 12 TCP HP, 41 Direct Connections): “All available peers have been attempted to be reached”.

The setup was very simple :+1:.


#63

Client is repeatedly crashing after running couple of minutes.

thread 'main' panicked at 'Aborting due to the previous error', examples/client.rs:309:17
ERROR 23:56:29.488693782 [client client.rs:308] 
Failed to get our connection info: 
Rendezvous with server failed for both Tcp and Udp - could not obtain our external address
note: Run with `RUST_BACKTRACE=1` for a backtrace.

#64

Been running on my Mac Mini for a couple of hours, had to restart, but now I am getting this error, after multiple attempts.


#65

Thanks for implementing the filter option for user ids! After a quick test I noticed two things that might be interesting for you:

  1. The program panics after some attempts with the following error msg:

ERROR 23:57:04.670313800 [client client.rs:308] Failed to get our connection info: Rendezvous with server failed for both Tcp and Udp - could not obtain our external address
thread ‘main’ panicked at ‘Aborting due to the previous error’, examples/client.rs:309:17
note: Run with RUST_BACKTRACE=1 for a backtrace.

  1. My logs state that I have successfully connected to “savage”, but I can’t see this in the dashboard when filtering for my ID (“e3d9f4…”):
    Successfully connected with savage (6d878d…)

Here you can see the full log file for further info / debugging. Hope this helps:
https://pastebin.com/70DxKkee


#66

Yesss. 96% connection after 3 min. Way more people participating. Well done safe!


#67

In with 100% connection rate. Vast majority of which are direct.

Glad I’m able to participate in this one. Great job guys!

The dashboard is much more usable this time around, I really like the UX improvements you guys have made.


#68

Getting the same error on my Macs. One High Sierra (10.13) Mac worked for a bit but when I restarted the client it would no longer work and gives the same out put you have. On my Mojave (10.14) Mac I only get the error.

“thread panicked while panicking. aborting.” <- Best error I’ve ever seen though. Sounds like me on a bad day,


#69

74% from 4,833 connection attempts. 100% in home country. Not bad for a computer illiterate haha! Certainly a lot more than last time and a lot faster it seemed too. Well done Maidsafe team!


#70

Have to agree with others that connections are fast, almost immediate in fact. TCP & UDP HP seem faster than last time too. The UI/UX is just right, excellent improvements!


#72

Works on my VPN but not great results.

My VPN implements a NAT at the exit point and direct is the only way it gets about a 50-50 result.

And tons of warnings

WARN 14:57:56.860766526 [client client.rs:300] Changed NAT type: NatInfo { nat_type_for_tcp: EDM(-1), nat_type_for_udp: EIM }

And after 10 or so minutes this came up (running linux with VPN)

INFO 15:07:21.485350509 [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!
WARN 15:07:21.807742464 [client client.rs:300] Changed NAT type: NatInfo { nat_type_for_tcp: EDMRandomPort([56839, 56837, 56838]), nat_type_for_udp: EIM }
ERROR 15:07:40.122430458 [client client.rs:308] Failed to get our connection info: Rendezvous with server failed for both Tcp and Udp - could not obtain our external address
thread 'main' panicked at 'Aborting due to the previous error', examples/client.rs:309:17
note: Run with `RUST_BACKTRACE=1` for a backtrace.

#73

Woo, running it. Missed the first one. But I’m finally in the mood to understand most of it (not truly familiar with any of what TCP/NAT/everything-else means on a fundamental level, just that it’s important mumbo jumbo for Maidsafe to analyse). Good.

(Just wondering if there’s a way to add some newfangled function to this whole plan, namely: for trusted users, who participate, to have the ability of sending 1-2++[?] invites for people, whom said trusted users blab to about SAFEnet all the time, to participate in the CRUST test. Random idea, not sure if feasible, but would extend that much more analysis, dunno.)


#74

@DGeddes

Dashboard Feature request: A way to refresh without losing selections made.


#75

I’m seeing 21 out of 40 connections successful (53% success rate) via my Symmetric NAT with non-uniformly changing port map. :slight_smile:


#76

I left the Crust client running over night. When I woke up the client had stopped and I was greeted by this, which I haven’t seen before:

All available peers have been attempted to be reached. Checking for new peers every 10 seconds.
WARN 04:02:08.317768277 [client client.rs:300] Changed NAT type: NatInfo { nat_type_for_tcp: EIM, nat_type_for_udp: Unknown }
WARN 04:02:18.781068963 [client client.rs:300] Changed NAT type: NatInfo { nat_type_for_tcp: EIM, nat_type_for_udp: EIM }
WARN 04:05:53.363565586 [client client.rs:300] Changed NAT type: NatInfo { nat_type_for_tcp: EIM, nat_type_for_udp: Unknown }
WARN 04:06:03.784893349 [client client.rs:300] Changed NAT type: NatInfo { nat_type_for_tcp: EIM, nat_type_for_udp: EIM }
ERROR 04:21:13.394400583 [client client.rs:308] Failed to get our connection info: Rendezvous with server failed for both Tcp and Udp - could not obtain our external address
thread ‘main’ panicked at ‘Aborting due to the previous error’, examples/client.rs:309:17
note: Run with RUST_BACKTRACE=1 for a backtrace.

Restarted and it’s running fine again now. Connection success tethering over an old phone and PiaVPN over 60%. I notice no difference with and without VPN.

EDIT: The others reporting this error all seem to get the same “examples/client.rs:309:17”.

EDIT 2: $ cat *.log | egrep ‘309:17’
doesn’t give any result. Is this not being logged?


#77

I’m not involved in the test due to my lack of tech knowledge but I’m excited with all the positive excitement. I’ll still be able to say I was around at the time Crust was tested and read every post by the live testers. Well done devs


#78

Success rate about 60% and only 50% within the same country…

What is the first way the Crust is going to try to connect ?

  1. TCP Hole Punching

  2. UDP Hole Punching

  3. Direct connection


#79

So first attempt at running and only 33% (one out of three total) connected … then I realized I had a local http proxy (using tinyproxy in localhost) set in my .bashrc file … not sure if it makes a diff, but when I commented it out and reloaded bash and started the test again I now have 75% (three out of four total) connected.

You can see the results by filtering for tylerjordan and tylerjordan-2.

Does use of a local http proxy cause any problems? Or is my experience a fluke?


#80

For fun, I put my hardcore firewall up midstream, test client crashed and so I attempted restart but failed with message … whole output here:

===============================================
thread ‘main’ panicked at ‘Aborting due to the previous error’, examples/client.rs:309:17
note: Run with RUST_BACKTRACE=1 for a backtrace.
ERROR 18:54:49.790256309 [client client.rs:308] Failed to get our connection info: Rendezvous with server failed for both Tcp and Udp - could not obtain our external address
anon@Devuan:~$ /home/anon/Downloads/crust_test-v0.2.0-linux-x64/client
Please enter your name (or press Enter to keep it blank): tylerjordan-3
INFO 18:55:46.399335742 [client client.rs:1202] Our public ID: dcfd73…
INFO 18:55:46.399444770 [client client.rs:1204] Attempting bootstrap…
ERROR 18:55:56.399991906 [client client.rs:1216]

Could not connect with the proxy.

This probably means that your IP address is not registered. Please follow this link for registration: https://crusttest.maidsafe.net/auth.html
If you have registered your IP address and still getting this error it could mean the proxy is down or not reachable. Please contact us and provide the log file.


#81

I don’t know what this means, but hmmm…