Failed when attempting to create a connection with remote QUIC endpoint: invalid DNS name:

[Southside]

I’m trying to connect to my baby-fleming network from another box on my LAN. Just to make it difficult I’m using Win 10 on the laptop and Ubuntu on the machine running the vaults.

What is the correct way to state the authd endpoint on a LAN?
I get these errors:

I can ping the Ubuntu box OK

My plan is to log in from the Win 10 box, upload some files, download some stuff I uploaded earlier and then if that goes OK, start a vault on the Win box and try to get it to connect to the baby-fleming section.

[drehb]

If it isn’t happy with IP addresses, maybe try setting up DNS for your LAN

Alias for IPs in the home LAN network

[Southside]

I just stuck an entry in the hosts file and I can ping it by name OK - as expected. Still can’t connect to authd though…
On the linux box I see this

so authd seems not to like IP addresses at all…
Is this by design?

Does authd only respond to localhost and the --endpoint option is there if another local port other than 33000 was specified for some reason? No - that just doesnt make sense…
I suppose I could look at the source… but it’s much easier to just ask here

[Southside]

Has anyone had any success in running safe authd on any port other than the default https://localhost:33003?

OR another way of putting it… any body used the --endpoint flag successfully? @mav @tfa ?

[bochaco]

I think the CLI is probably not resolving it correctly and it doesn’t like IPs either, so sometihng pending for implementation/fix there.

[Southside]

Thank you @bochaco

btw

@Southside

other than the default https://localhost:33003?

This of course should be https://localhost:33000

port 33003 was one of my failed attempts

[bochaco]

I just tried this and it worked for me:

$ safe auth start --endpoint https://localhost:50000
Starting SAFE Authenticator daemon (safe-authd)...
safe-authd started (PID: 72169)

$ safe auth status --endpoint https://localhost:50000
Sending request to authd to obtain a status report...
+------------------------------------------+--------+
| SAFE Authenticator status                |        |
+------------------------------------------+--------+
| Authenticator daemon version             | 0.0.10 |
+------------------------------------------+--------+
| Logged in to a SAFE account?             | No     |
+------------------------------------------+--------+
| Number of pending authorisation requests | 0      |
+------------------------------------------+--------+
| Number of notifications subscribers      | 0      |
+------------------------------------------+--------+

[Southside]

Thank you. Yes I can confirm that here too.
But can you start a vault (or network of vaults) and then create an account using –endpoint https://localhost:50000? And then can you connect to that account from another machine in your LAN?

I’m busy with other stuff right now but I will look at this again later this afternoon.

[bochaco]

@Southside

But can you start a vault (or network of vaults) and then create an account using –endpoint https://localhost:50000 ? And then can you connect to that account from another machine in your LAN?

I can create an account and login yes:

$ safe auth --endpoint https://localhost:50000 create-acc --test-coins
Passphrase: 
Password: 
Creating a SafeKey with test-coins...
Sending account creation request to authd...
Account was created successfully!
SafeKey created and preloaded with test-coins. Owner key pair generated:
Public Key = 8f0379beeea4c2c22139abd253ac981740f794c26c2c383559f103583855217c086adab86439da99ed8361be02f7161e
Secret Key = 0f16fcd28a44a824c25617f26d826f92f422f43335e2eb222e56f0108946c653

$ safe auth --endpoint https://localhost:50000 login --self-auth
Passphrase: 
Password: 
Sending login action request to authd...
Logged in successfully
Authorising CLI application...
Awaiting for authorising response from authd...
SAFE CLI app was successfully authorised
Credentials were stored in /home/bochaco/.local/share/safe-cli/credentials

I don’t have another laptop now to test from, but that would fail as CLI doesn’t like IPs, it also fails for me with --endpoint https://127.0.0.1:50000.

[Southside]

@bochaco

I don’t have another laptop now to test from, but that would fail as CLI doesn’t like IPs, it also fails for me with --endpoint https://127.0.0.1:50000 .

Yes - that was my experience too