Upcoming ice-server changes for named domain reachability


#1

We’re working through a PR right now that secures the domain-server/ice-server heartbeat process.

Once merged, in order for your named domain to send heartbeats to the ice-server (which is crucial for full automatic networking) it will generate a keypair and upload the public key to the Metaverse server.

If you have place names pointing at your domain and you use automatic networking for reachability, please ensure your domain-server has an access token.

Visit your domain-server settings at http://localhost:40100/settings and verify that you have a connected account. If you have a connected account the top of your domain-server settings page should look like this.

If you instead have a “Connect High Fidelity Account” button, please click that and complete the process to ensure your domain-server is connected with an access token.

If you have any issues connecting your domain or you have any questions about the changed heartbeat process, feel free to reach out to me here.


#2

One important note for temporary place names. Those do not require a High Fidelity account and as such do not require an access token to be present in your domain-server.

This means temporary place names do not have secured heartbeats and can be impersonated should an attacker know the domain ID of the temporary name. Temporary place names are meant to only be shared with users you know to invite them to your domain while you are getting it setup without the requirement of immediately purchasing a place name.


#3

This change is going out now. Please make sure to update your client and Server Console. Any previous versions of the domain-server will be unable to talk to the ice-server once the new ice-server is deployed.


#4

Downloaded latest, and now I get this 3x/sec:

[02/25 15:56:37] [WARNING] [4452] [assignment-client] Could not attach to shared memory at key “domain-server.local-port”
[02/25 15:56:37] [WARNING] [4452] [assignment-client] Failed to read local assignment server port from shared memory - will send assignment request to previous assignment server socket.

I tried going to settings: http://localhost:40100/settings no longer works.

Yes, I have an oauth token set up. I will try again in an hour or so, to see if the problem clears up on its own.

Latest = 4283, entire console stack onto Win10Pro

I stoped then started he server. Logs show this:

Time zone: Pacific Standard Time
[02/25 16:09:57] [DEBUG] Asynchronously looking up IP address for hostname “stun.highfidelity.io” - lookup ID is 1
[02/25 16:09:57] [DEBUG] Changed socket “send” buffer size from 65536 to 65536 bytes
[02/25 16:09:57] [DEBUG] Changed socket “receive” buffer size from 65536 to 1048576 bytes
[02/25 16:09:57] [DEBUG] NodeList socket is listening on 62098
[02/25 16:09:57] [DEBUG] Local socket is 192.168.254.141:62098
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 2 (DomainList)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 3 (Ping)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 4 (PingReply)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 39 (ICEPing)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 21 (DomainServerAddedNode)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 46 (DomainServerConnectionToken)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 16 (DomainConnectionDenied)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 48 (DomainSettings)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 22 (ICEServerPeerInformation)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 32 (DomainServerRequireDTLS)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 40 (ICEPingReply)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 20 (DomainServerPathResponse)
[02/25 16:09:57] [DEBUG] Registering a packet listener for packet list type 56 (DomainServerRemovedNode)
[02/25 16:09:57] [DEBUG] [12132] [assignment-client] Synchronously looking up IP address for hostname “localhost”
[02/25 16:09:57] [DEBUG] [12132] [assignment-client] QHostInfo lookup result for “localhost” with lookup ID -1 is “127.0.0.1”
[02/25 16:09:57] [DEBUG] [12132] [assignment-client] Assignment server socket is 127.0.0.1:40102
[02/25 16:09:57] [DEBUG] [12132] [assignment-client] Waiting for assignment - UUID: {00000000-0000-0000-0000-000000000000}, Type: 7
[02/25 16:09:57] [DEBUG] [12132] [assignment-client] Assignment-client monitor socket is 127.0.0.1:49571
[02/25 16:09:57] [DEBUG] [12132] [assignment-client] Registering a packet listener for packet list type 15 (CreateAssignment)
[02/25 16:09:57] [DEBUG] [12132] [assignment-client] Registering a packet listener for packet list type 35 (StopNode)
[02/25 16:09:57] [DEBUG] [12132] [assignment-client] QHostInfo lookup result for “stun.highfidelity.io” with lookup ID 1 is “54.67.22.242”
[02/25 16:09:57] [DEBUG] [12132] [assignment-client] Sending intial stun request to stun.highfide[02/25 16[02/25 16:09:58] [DEBUG] [12132] [assignment-client] New public socket received from STUN server is 162.251.185.1[02/25 16:[02/25 16:09:58] [WARNING] [12132] [assignment-client] Could not attach to shared memory at key “domain-server.local-port”

and that last warning just keeps repeating.


#5

Can you get me your domain-server log? That will tell us what’s going on.

Looks like it isn’t running at all. Perhaps something appears to be listening on 40100 and the domain-server is refusing to start.


#6

Okay, I’m reproducing this locally now, should have a fix shortly.


#7

I think this has broken all my localhost bookmarks and teleport URLS.

Long story but:

Two computers running domains at same IP here.

Tiny one stays on all the time and hosts the Capitola place name with a manually set fixed port which happens to be the default port setting, because I set this one up long time ago before there was auto networking in HiFi.

Other one is localhost on my desktop set to auto networking.

Before this afternoon, all worked. Now when I try to use the bookmarks and teleport URLs (and I suspect entity hyperlinks as well). I leave the domain I am at and end up in space with “Not connected” in the title bar.

The domain is active because if I use “localhost/xxx,xxx,xxx”, I get connected.

One thing I should mention is that my localhost domain at one point was connected to a HiFi place name and it still shows up in the title bar even when I get there by using localhost as the URL.

It may be that I can fix this by using the numeric URL and port instead of localhost but that would require that the auto networking system returns the same settings each time, which I don’t know will be the case.


#8

No domain server logs, I checked appdata/local and /roaming paths in case logs were moved.
Launched netstat and it shows no listeners to port 401xx.
I’ll wait for a fix to arrive.


#9

The domain-server is crashing when it attempts to generate the keypair. Happens on release locally and in the installer build. I’m reverting that pull request for now until we can find the fix.

Once the update from the revert is out you should be back to normal.


#10

I believe this is related to the same issue that @Balpien_Hammere is running into.


#11

Maybe so, but I can connect and my logs are a bit different:

[02/25 17:11:27] [WARNING] Cannot send an ice-server heartbeat without a private key for signature.
[02/25 17:11:27] [WARNING] Waiting for keypair generation to complete before sending ICE heartbeat.
[02/25 17:11:27] [DEBUG] Clearing current private key in DataServerAccountInfo
[02/25 17:11:27] [DEBUG] Starting worker thread to generate 2048-bit RSA keypair.
[02/25 17:11:27] [DEBUG] Generated 2048-bit RSA keypair. Uploading public key now.
[02/25 17:11:27] [WARNING] Public key upload failed from AccountManager “Error downloading https://metaverse.highfidelity.com/api/v1/domains/4f6628d8-668e-4f32-93d3-34c94198dfc9/public_key - server replied: Not Found”
[02/25 17:11:29] [WARNING] Cannot send an ice-server heartbeat without a private key for signature.
[02/25 17:11:29] [WARNING] Waiting for keypair generation to complete before sending ICE heartbeat.
[02/25 17:11:29] [DEBUG] Clearing current private key in DataServerAccountInfo
[02/25 17:11:29] [DEBUG] Starting worker thread to generate 2048-bit RSA keypair.
[02/25 17:11:29] [DEBUG] Generated 2048-bit RSA keypair. Uploading public key now.
[02/25 17:11:29] [WARNING] Public key upload failed from AccountManager “Error downloading https://metaverse.highfidelity.com/api/v1/domains/4f6628d8-668e-4f32-93d3-34c94198dfc9/public_key - server replied: Not Found”

etc., etc.


#12

Okay, yep - you have a different issue. Are you on Windows 10? I think we’ve isolated the OpenSSL issue to Windows 8.

For the localhost fully automatically networked domain do you have a connected High Fidelity account? That is required to upload that public key.


#13

Win 7 sp1. And no, at one point it was but I disconnected it awhile ago.


#14

This work has been reverted so it will not be an issue for now.

Next week when merged again you will need to connect an account to be able to upload the public key from the generated keypair. This will be required for automatic networking.


#15

Is this really true? A new user will get a temp place name and be able to use auto networking. But then at some later time, if they don’t buy a place name their domain will cease to function?


#16

Temporary names can have their public key updated without authentication. This means that they are only secured through obscurity and could be impersonated at the ice-server.

They no longer expire, so you can keep them as long as you like, but they will have the above limitations.


#17

So for temporary names you can use them as long as you want, as long as someone else doesn’t start one up using the same name when yours happens to be offline?

And don’t get me wrong, I just renewed a bunch of place names here and understand that HiFi must make $ to make all this happen.

But just so I can understand what this means, let’s say I pay for a place name and then I decide to not renew it. To keep it reachable by others I would have to switch it to manual networking and then tell all my friends the new URL and change all references in bookmarks, teleports and hyperlinks? Would that work?


#18

You cannot pick the temporary name you get for your temporary domain, so it isn’t a matter of somebody simply deciding to use up the same name. They would need to know your temporary domain ID. The temporary names are meant to help you get set up initially which is why they don’t have all of the same affordances as a purchased place name.

If you are using a place name you own for bookmarks, teleports, and hyperlinks, and you decide not to renew that name you should expect those links not to point to your domain-server anymore. This works like owning domain names on the web.

You will always be able to have a High Fidelity domain without a High Fidelity account and without a place name if that’s how you want to set it up. You can have people connect to you directly with your IP and port combination, or via a domain name you own by pointing it to the IP of your domain-server.


#19

Thanks for the reply. It was unclear to me what you meant by impersonating.


#20

Verified, domain controller is up again. And yes, it is very important to prevent unintended impersonation, so looking forward to that change once the root bug is fixed.