Installing Safe_Vault

Hi,

I finally got it compiled and passing all of its tests. That is:

  1. Compiled libsodium, passes all of its tests, then installed it.

  2. Compiled sodiumoxide, passes all of its tests. This provides the Rust bindings for libsodium.

  3. Compiled safe_vault (which requires libsodium), and “cargo test” passes all tests!

At this point I believe I have good files so I tried to run them (rather than building a Windows installer just yet).

The conditions are: Two Windows 7 machines on the same LAN and with Windows firewall turned off. Start the launcher (0.4.1) and then run safe_vault.exe.

Following are the errors from two alternative scenarios (same errors on both computers):

  1. With each file (safe_vault.exe and safe_vault.crust.config) in its correct directory:

thread ‘’ panicked at ‘Unable to start crust::Service FileHandler(JsonDecoderError(MissingFieldError(“tcp_acceptors”)))’, C:\Users\user.cargo\registry\src\github.com-88ac128001ac3a9a\routing-0.15.0\src\core.rs:283

  1. With both files in my home directory:

WARN 00:55:52.567833500 [w_result lib.rs:288] Failed to find an IGD gateway on n
etwork interface {DC76EA0D-6BBB-4EB3-AD1E-B54D0E619D42} 192.168.10.11. igd::sear
ch_gateway_from_timeout returned an error: IO error: A connection attempt failed
because the connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to respond. (os
error 10060)
ERROR 00:55:53.685897400 [crust::service service.rs:284] Failed to start listeni
ng for peers.
ERROR 00:55:53.713899000 [routing::core core.rs:1224] Running listener.

Any ideas, anyone?

@bluebird, I think you could definitely wait up for the docker image for vaults; IDK when but I’m sure it’s being worked on, and should be a no hassle for you to install.

I’m not interested in that. I’m a student developer in this space.

YOU wait and download the docker image.

And by the way, you reply is off topic.

Surely someone out there has some relevant input? I know plenty of people saw my post.

1 Like

You might need a vault config file, but that’s a wild guess. If so, search the forum for clues as to where to find it - I’m on Linux, but many months ago I solved a problem by copying a config file from tmp (generated by an early MaidSafe demo I guess).

You could try the config that came with the launcher, but it may well not work on a local network. I think you can copy it next to the .exe

I don’t remember more than that though - so sorry it doesn’t get you very far.

EDIT: sorry, re reading I see you have a config. It’s late, I better sleep!

2 Likes

Thank you, I’ll try that, tomorrow since it’s approaching 2am. I am working on how-to notes that I’ll publish here.

2 Likes

They just recently released a config file. Thought I had the link but unfortunately no longer.

Thanks! You must mean this? https://github.com/maidsafe/safe_vault/commit/0a7f44fb9cbe3560bb7fcf2f172ed7c8d143c5ca

That went into the master repo yesterday, which I built from earlier today, with similar errors.

Something I don’t understand is why the error refers to a path into my .cargo\registry. What would a safe_vault binary by doing trying to look there?

Don’t mind my two cents here but the second scenario makes me think they error because they aren’t finding anybody to talk with, they need to know to talk to each other i’m guessing to build a routing table. Before compiling is there anything about IP addresses hardcoded some where?

I just did a fresh build, since I wasn’t sure what I might have done early this morning, and using the resulting safe_vault.exe and the safe_vault.crusts.config file referred to above.

Now I get a more sensible error on both computers, so obviously I made some mistake on my previous iteration.

This is a sampling of what they do now (it repeats):

WARN 19:23:08.440897100 [crust::bootstrap bootstrap.rs:117] Error connecting to
bootstrap peer: No connection could be made because the target machine actively
refused it. (os error 10061)
WARN 19:23:29.442098300 [crust::connection connection.rs:160] TCP direct connect
failed: A connection attempt failed because the connected party did not properl
y respond after a period of time, or established connection failed because conne
cted host has failed to respond. (os error 10060)
WARN 19:23:50.693313800 [crust::bootstrap bootstrap.rs:117] Error connecting to
bootstrap peer: A connection attempt failed because the connected party did not
properly respond after a period of time, or established connection failed becaus
e connected host has failed to respond. (os error 10060)
WARN 19:23:52.185399100 [crust::connection connection.rs:160] TCP direct connect
failed: No connection could be made because the target machine actively refused
it. (os error 10061)
WARN 19:24:13.435614500 [crust::bootstrap bootstrap.rs:117] Error connecting to
bootstrap peer: No connection could be made because the target machine actively
refused it. (os error 10061)
WARN 19:24:15.073708200 [crust::connection connection.rs:160] TCP direct connect
failed: No connection could be made because the target machine actively refused
it. (os error 10061)
WARN 19:24:36.325923800 [crust::bootstrap bootstrap.rs:117] Error connecting to
bootstrap peer: No connection could be made because the target machine actively
refused it. (os error 10061)
ERROR 19:24:36.325923800 [crust::service service.rs:284] Failed to start listeni
ng for peers.

1 Like

The software is behaving correctly on startup, insofar as it creates a safe_vault.bootstrap.cache and a safe_vault.vault.config, alongside the safe_vault.crust.config in c:\programdata\safe_vault.

But it seems that neither machine can find another machine, despite the fact that the safe_vault.crust.config has the IP addresses of half a dozen nodes on the SAFE network.

The only “routing table” it should need (?) is what it starts with, safe_vault.crust.config, and the safe_vault.bootstrap.cache, which starts empty but presumably accumulates the addresses of nodes that it finds.

Question is, is the message that connection is “actively refused” genuine? Is it actually finding a machine but failing to authenticate to it?

Thought I’d scan one of the ip addresses in the config file:

Still plenty of ip addresses to check.

Good idea… if they’re closed then a new instance of safe_vault won’t connect to them.

Except that i still had “connection refused” when I put the private network IP address of each of my machines into the config file of the other, like so:

{
  “hard_coded_contacts”: [
    {
      “tcp_acceptors”: [
        “192.168.10.10:5483”
      ],
      “utp_custom_listeners”: [
        “192.168.10.10:5483”
      ],
      “tcp_mapper_servers”: [],
      “udp_mapper_servers”: []
    },

EDIT: I put the private IPs back into this comment. Somehow while wrestling with this forum’s markdown notation I had overwritten the private IP with the SAFE network one, and hadn’t noticed the “regression.”

I wonder if it fails because of only having 2 machines. Makes me wonder if there is a minimum number of nodes it has to connect to?

Right a script to port scan one of the machines when you start the vault and log the errors. Then see after if anything was logged showing it answered on the port.

I’ve run similar tests, but using multiple terminals on a single (Linux) computer… some time ago. I don’t recall details but think it is different if you try to do this on a local network - presumably because if the need to locate the other machines IP. I never tried that.

So maybe try multiple vaults on the same PC.

Backtracking a little, here’s another question:

The Powershell script to build the installer expects safe_vault.exe to be found in target\release\ but safe_vault.exe is actually created by the compiler in \target\debug. Why? Does it mean the file needs debugging, i.e., that there’s a problem?

EDIT: I just answered this question: “cargo build” creates safe_vault.exe in target\debug and “cargo install” creates it in target\release along with some other items (as well as copying it to .cargo\bin). It seems redundant that it recompiles it with each of: cargo build, cargo test and cargo install.

https://www.youtube.com/watch?v=k1MBNFOqyZ8

Thanks, but I knew about that. I’ve also had it running on Linux.

My purpose in compiling, and on Windows, is to become familiar with developing and modifying this software, and on Windows in particular because that’s where most of the users are. My goal isn’t to run vaults per se.

EDIT: The download in the video (https://github.com/maidsafe/safe_examples/releases/tag/0.0.1) is from September 2015, ancient history. It is 7MB compared to my build (after the “strip” operation in the build script) of 9MB. I guess there’s been a whole lot of routing machinery put into it since then.

Just now I reproduced what I had done weeks ago, of the same steps as the video, using the downloaded safe_vault_win.exe, and indeed it runs a vault if you have two or more instances running on the same machine (no launcher). They find each other as in the video. If instead I use my safe_vault.exe build then, no matter now many instance are running on the same machine, they give the errors below.

Same result if I have it on separate machines.

This is regardless of how I tweak the safe_vault.crust.config; e.g., with only the other machine’s LAN IP under “hard_coded_contacts”.

I am a bit purturbed by that environment variable, which is indeed required for (my) safe_vault.exe to run without exiting with a panic error, which is an undocumented “secret sauce” that I have not been able to find in any md file at github, and only ad hoc mentions of it on this forum.

What other undocumented requirements are there, such as environment variables, that are only found on the developer’s computer?

Something else: Not only does the installer produced by the Powershell script not set that environment variable, it also doesn’t adjust the security settings of the installed files/directories properly. To get this far I had to manually grant the user full access to the c:\programdata\safe_vault\ directory, otherwise it exits with a panic error.

INFO 17:43:53.763490700 [safe_vault safe_vault.rs:105]

Running safe_vault v0.5.0

WARN 17:43:55.307893400 [w_result lib.rs:288] Failed to find an IGD gateway on n
etwork interface {34BA2F5E-B975-4CFC-8AEB-F4DE3CF94ABD} 192.168.10.11. igd::sear
ch_gateway_from_timeout returned an error: IO error: A connection attempt failed
because the connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to respond. (os
error 10060)
WARN 17:43:57.320297000 [crust::connection connection.rs:160] TCP direct connect
failed: No connection could be made because the target machine actively refused
it. (os error 10061)
WARN 17:44:20.114737400 [crust::bootstrap bootstrap.rs:117] Error connecting to
bootstrap peer: No connection could be made because the target machine actively
refused it. (os error 10061)
WARN 17:44:21.144339200 [crust::connection connection.rs:160] TCP direct connect
failed: No connection could be made because the target machine actively refused
it. (os error 10061)
INFO 17:44:23.421943200 [routing::core core.rs:1226] Running listener.
INFO 17:44:23.437543200 [routing::core core.rs:422] | Node(f572…) PeerId(a391…
) - Routing Table size: 1 |

EDIT1: OK, I suppose I’ll have to trawl through the source code to find out what environment it might be expecting. That’s what I signed up for…

1 Like

I indirectly took @upstate 's advice and looked at open ports: not scanning exactly, but netstat.

Doing “netsat -an > out.txt” before and after running an instance of safe_vault, on both machines and with a reboot along the way, and comparing those results, gave me the following insights:

safe_vault listens on two TCP ports and on two UDP ports that change in an unpredictable pattern when it is restarted. It also listens on UDP port 5484, that doesn’t change.

The safe_vault.crust.config file has a list of “hard_coded_contacts” which appear to be other instances of safe_vault, along with the port they are listening on (5483 in every case) and both TCP and uTP transport protocols.

As I understand it, since uTP is a layering on UDP, then it is uTP that is being listened for on those open UDP ports that I found.

But how can I use this?

If all those “hard_coded_contacts” are listening on uTP/UDP port 5483, as if it were a default port, then why are my machines listening on 5484, as if it were a default port?

In each machine’s safe_vault.crust.config file I added an entry under hard_coded_contacts for the other machine. On machine A I used netstat to determine its current listening ports. Leaving that machine running safe_vault, on machine B I changed the entry in its safe_vault.crust.config for machine A to various of machine A’s listening ports. I restarted B after each change.

What I found was a different type of error (than connection “refused”), when some kind of handshake seemed to have occurred:

ERROR 23:11:00.544586400 [crust::sender_receiver sender_receiver.rs:71] Deserial
isation error: Deserialise(IoError(Error { repr: Custom(Custom { kind: Unexpecte
dEof, error: StringError(“failed to fill whole buffer”) }) }))
WARN 23:11:00.544586400 [crust::connection connection.rs:160] TCP direct connect
failed: Deserialisation failure
WARN 23:11:21.854223900 [crust::bootstrap bootstrap.rs:117] Error connecting to
bootstrap peer: Deserialisation failure
INFO 23:11:22.821425600 [routing::core core.rs:1226] Running listener.

Ideas, anyone?

I get the same error as you in sender_receiver.rs at line 71: “failed to fill whole buffer”

As this happens on a program that was perfectly working previously, I suppose a regression in a maidsafe crate has been recently added.

I am on Windows, I will test on Ubuntu to see if a I get the same error.