Can I connect to a LAN vault already? If so, how?

Setup

Desktop

  • Hardware: Asrock J5005
  • OS: Manjaro
    • Arch: AMD64
    • DE: XFCE
  • safe-cli 0.15.0
  • safe-authd 0.0.11
  • SAFE Browser 0.18.beta.1

Server

  • Hardware: RPi 4
  • OS: Manjaro
    • Arch: Arm
    • DE: Minimal
  • safe-cli 0.15.0
  • safe-vault 0.25.1
  • safe-authd 0.0.11

I’ve been able to connect to a local vault.
Now I want to go a little further and started a vault on a raspberry Pi
for my desktop computer to connect to.

So I created this on my desktop:

cat /home/folaht/.config/safe-cli/networks/lan_vault_connection_info.config
"192.168.178.21:12000"

And switched to the lan network.
I’m unable to login though:

[2020-09-20T00:01:47Z ERROR safe] safe-cli error: [Error] AuthdError - [Error] AuthError - Failed to log in: Core error: Unexpected: Connection timed out when bootstrapping to the network
4 Likes

I don’t know but wonder that current code is likely looking to use “the IGD protocol to forward the internal port number on your computer to an external port on the router. This will allow the other nodes to seamlessly communicate with your running vault.”

So, in many cases the router might not be able to work to that.

Oh, I have to open up the port number?

If it is that, there might not be a fix… the test was set for a certain type of route that has that IGD… if it’s there it works and if it isn’t there’s not a fix… the option for other routers swtiched off for the test afaiu. Others here might know more…

No, that’s a moment of confusion on my part.
Of course the ports are open in a LAN.

1 Like

There was an igd bug where igd fired even for local networks and then reported the external address. So make sure igd is off when you do LAN and then all should be well. This is fixed in recent code (last week, may not be merged).

4 Likes

Fixed in safe vault or fixed in safe client?

Vault is the culprit, client should never use igd

7 Likes

I can’t build the git version of safe-vault.

error: failed to get `bls_signature_aggregator` as a dependency of package `sn_routing v0.37.0 (https://github.com/bochaco/sn_routing.git?branch=async-quic-p2p-api#a9a4b501)`
    ... which is depended on by `safe_vault v0.24.0 (/home/folaht/safe/safe-vault)`

Caused by:
  failed to load source for dependency `bls_signature_aggregator`

Caused by:
  Unable to update https://github.com/madadam/bls_signature_aggregator.git?branch=repetition#70a7bea3

Caused by:
  object not found - no match for id (70a7bea36ad07fe0a408d596404157ed0a7eb63d); class=Odb (9); code=NotFound (-3)
3 Likes

They’re in the middle of big changes so I’m not surprised. You could check out an earlier version and build that though.

2 Likes

Looking at the commits in this branch

https://github.com/madadam/bls_signature_aggregator/commits/repetition

There is no commit 70a7bea3 as required by the dependencies listed in Cargo.toml

Maybe try using the latest hash 6ea5a50 but it might take some messing with the Cargo.toml dependency chain, eg

sn_routing = { path = "/your/path/to/sn_routing" }

and then modify in routing Cargo.toml the dependency for bls_signature_aggregator to use a different commit.

But I think it’s not worth doing this, the code is not in a stable state, and building the latest has very little confidence of what features work or don’t. Fun to try but it’s what I’d classify as a ‘high risk’ pursuit, very good chance of no reward at the end of the fiddling.

FWIW I also tried connecting to a LAN vault but could not, got timeout error from authd.

6 Likes

Ah, so not just me today :laughing: Yea, as mentioned, the code’s going through some big changes, so if you’re building from source, you’ll need to pick and choose which commits you use until things settle down.

Especially with the crate renaming/reorganization happening now, the dependency graph breaks down occasionally. More often than not, if you wait a few days and try again, it’ll be fixed sooner rather than later. Alternatively, you can play with the cargo.toml as @mav mentioned, and it’s usually straightforward to figure out what broke/how to fix it for your local build.

4 Likes

Unfortunately, this isn’t always what I observed in the past, and incompatible master branches between repos can even last for months.

The problem is that Maidsafe team doesn’t use a workflow like: Gitflow Workflow | Atlassian Git Tutorial.
In summary: developers should deliver their features in develop branch instead of master and master should be checked out only from a release (or merged from a hotfix)

Using this workflow:

  • master branches are stable and compatible between repos
  • current branches with latest developments are still available (but named develop)
2 Likes

Yes, normally we would, however there are trade offs. So we had master with parsec and a load more stuff we did not want and did not work, but we had it all compiling and building, so “feels good”, but building the wrong stuff.

We even have come a cropper ourselves trying to build on master, keep tests passing while having other branches (like async) which we actually are doing all e2e tests from and represent the design much better, albeit unfinished.

Therefore we decided master is not a working system, even though it builds and passes local tests, it fails in creating a network that actually works. So it was a false sense of something, but not Safe Network.

Drive right now is get everything in master that meets design principles (some stuff still to get killed though, even there) and work on that. e2e tests first, get the network going, then unit tests etc. We are ignoring mock for now and focus more on CRDT types and quick checking (quickcheck/proptest) the blazes out of them.

When we have again master that creates a network that works, we move to develop branches. so this right now is full steam ahead, all in focus on, build from master brances to get the network up. If we cannot build we fix locally test and push to master.

tl;dr master building from a few weeks ago was not the Safe Network or close to it, now it is much more close, but we need to get it building and e2e tests passing. Then back to normal and use feature branches, but also limit PR’s to a couple hundred lines.

9 Likes

I’ve been able to build it by download the git source code of some of the packages.
Now to see if it actually works.

[update]

It didn’t, but someone fixed the bls issue half an hour ago.
Let’s see if this new version also fixed the other issue.

[update]

I guess I’ll have to wait a bit.

[folaht@Resosur-uq release]$ RUST_LOG=info,quinn=error safe vault run-baby-fleming -t
Storing vaults' generated data at /home/folaht/.safe/vault/baby-fleming-vaults
Launching local SAFE network...
Launching with vault executable from: /home/folaht/.safe/vault/safe_vault
Network size: 8 vaults
Launching genesis vault (#1)...
Genesis vault contact info: ["127.0.0.1:12000"]
Launching vault #2...
Launching vault #3...
Launching vault #4...
Launching vault #5...
Launching vault #6...
Launching vault #7...
Launching vault #8...
Done!
Setting up authenticator against local SAFE network...
Stopping SAFE Authenticator daemon (safe-authd)...
No running safe-authd process (with PID 22007) was found
Starting SAFE Authenticator daemon (safe-authd)...
safe-authd started (PID: 22824)
[2020-09-22T15:41:30Z INFO  safe::operations::auth_daemon] Using passphrase from provided ENV var: SAFE_AUTH_PASSPHRASE
[2020-09-22T15:41:30Z INFO  safe::operations::auth_daemon] Using password from provided ENV var: SAFE_AUTH_PASSWORD
Creating a SafeKey with test-coins...
[2020-09-22T15:41:30Z INFO  safe_api::api::app::safe_client] Creating test SafeKey with 1000.110000000 test coins
[folaht@Resosur-uq release]$ [2020-09-22T15:41:35Z INFO  safe::operations::auth_daemon] Using passphrase from provided ENV var: SAFE_AUTH_PASSPHRASE
[2020-09-22T15:41:35Z INFO  safe::operations::auth_daemon] Using password from provided ENV var: SAFE_AUTH_PASSWORD
Sending login action request to authd...
[2020-09-22T15:41:35Z INFO  safe_api::api::common] Sending 'login' request to SAFE Authenticator on https://localhost:33000 ...
[2020-09-22T15:43:00Z ERROR safe] safe-cli error: [Error] NetDataError - Failed to allocate test coins: Unexpected: Connection timed out when bootstrapping to the network - CoreError::Unexpected::{"Connection timed out when bootstrapping to the network"}
[2020-09-22T15:43:05Z ERROR safe] safe-cli error: [Error] AuthdError - [Error] AuthError - Failed to log in: Core error: Unexpected: Connection timed out when bootstrapping to the network
1 Like

If your goal is test the section running on the Pi perhaps your best option is to build the vault from the corresponding tag, and use the CLI and authd binaries from latest release, well, or also build CLI from the corresponding tag.

3 Likes

My goal is to have a network running as quickly as possible so people can post their websites on it, even if the network consists of just one server.

Safe vault 0.25.1 does not work beyond local level and the first reply I got is that it’s due to a bug that has been resolved last week.

6 Likes

Almost two weeks later and none of them build.

sn_cli]$ cargo build --release
    Updating crates.io index
error: no matching package named `sn_client` found
location searched: registry `https://github.com/rust-lang/crates.io-index`
required by package `sn_api v0.15.0 (/home/folaht/safe/sn_api/sn_api)`

Or

error: failed to select a version for `sn_client`.
    ... required by package `sn_ffi v0.15.0 (/home/folaht/safe/sn_api/sn_ffi)`
versions that meet the requirements `*` are: 0.42.1

the package `sn_ffi` depends on `sn_client`, with features: `mock-network` but `sn_client` does not have these features.
1 Like

You are confusing recent dev code with release code.
You will need to go back in time to a prior testnet (maybe “baby-Fleming”) or wait for Fleming. (Imo just wait for Fleming) Patience…

3 Likes

Be patient and prepare for more waiting. As I said above incompatible master branches can last for months.