FAQ
This chapter covers frequently asked questions about MSST-Net.
Installation & Startup
After installing the client, the controller cannot detect the core?
Check the following:
- Confirm the client core (
msst-net-client-core) is running - If you configured a system service, check its status:bash
sudo systemctl status msst-net - Check whether the core process started correctly and review the logs for errors
After starting the client, no device ID was generated?
The device ID is generated automatically on first startup and is typically stored in identity.json under the data directory (~/MSST-Net/).
If the file does not exist, the core creates it automatically on startup. If it still isn't generated, check that the core has write permissions to that directory.
Connection Issues
Why can't I connect to the remote device?
Troubleshoot in the following order:
- Confirm both devices are online: Check the remote device's online status in the controller
- Confirm relay is working: Check the connection status in the controller and confirm you're connected to the relay server
- Check firewall rules: Confirm there is an allow rule for the target port, or wait for an Interactive Authorization prompt
Why is direct connection not established and traffic always goes through the relay?
Direct connection requires the following conditions:
- The remote endpoint information has been obtained
- 10 or more consecutive probe responses have been received
- The P2P path latency is no more than 80% of the relay path latency
If the network environment (e.g., strict NAT, symmetric NAT) cannot be traversed, direct connection may never be established and traffic will always go through the relay. This is normal behavior and does not affect normal use.
What should I do about high connection latency?
- Check the current path mode: if it's Direct, high latency may be a network issue
- If you're in relay mode, select a closer relay node in network settings (Preferred Relay)
- Check your local network quality and rule out local ISP or Wi-Fi issues
Firewall & Authorization
Why did an authorization request pop up when connecting to a remote device?
When a device tries to access a port on your device and no matching firewall rule exists, the system triggers an Interactive Authorization request.
This is a normal security mechanism. You can:
- Allow Once: Temporarily allow, expires after 10 minutes
- Always Allow: Permanently allow, automatically creates a rule
- Deny: Deny this request or permanently deny
See: Interactive Authorization
Why didn't an authorization request pop up, and the remote connection just failed?
Interactive Authorization is only triggered for specific sources: it will not fire for unknown devices (devices that are not on your account, have no recent communication history, and are not referenced in any rule). Their connection requests are silently dropped.
To allow an unknown device to connect, manually create a firewall rule, or ensure both devices have been in the same room recently.
No response to ping?
ICMP ping (the ping command) is denied by default.
To allow ping, enable the ICMP Echo Request (Ping) option in the controller's firewall settings.
Identifiers & Hostnames
How do I change my device's display name?
In the controller's Settings page, you can modify:
- Device display name (the name shown in the UI)
- Device mnemonic (used for rule references and ezPlay hostnames)
Changing the mnemonic updates the ezPlay hostname automatically.
Can authenticated users change their user mnemonic?
If you completed access authentication (OIDC), the user mnemonic is derived from your account username and controlled by the coordinator. Local changes will not take effect.
If you have not authenticated (unauthenticated mode), you can freely change the user mnemonic in the controller.
ezPlay hostname resolution fails?
Check the following:
- Confirm the client core is running (ezPlay resolution is done locally)
- Confirm the target device is online and on the same network as you (Network Space or room)
- ezPlay hostnames are only valid within the MSST-Net virtual network and cannot be resolved from the public internet
Room Mode
The game's LAN multiplayer option can't find the room?
- Confirm both devices are in the same MSST-Net room
- LAN discovery is only supported on desktop platforms (Windows / Linux / macOS); Android is not supported
- Confirm the game uses a supported discovery protocol (Minecraft Java LAN broadcast, mDNS, etc.)
- Some games may require manually entering an IP address rather than auto-discovery
After leaving a room, is the virtual IP still valid?
Yes. A device's virtual IP is a fixed address deterministically derived from its device ID — it is always valid regardless of room membership.
Leaving a room only stops the LAN discovery broadcast proxy; it does not affect virtual IP connectivity.
Data & Privacy
Where is device data stored?
Client data is stored by default in the MSST-Net folder in the user's home directory:
- Windows / Linux / macOS:
~/MSST-Net/ - Container deployment:
/var/lib/msst/
This directory contains device identity information, keys, configuration files, and firewall rules.
Can the private key file be migrated?
Yes. Copy ~/MSST-Net/private.key and ~/MSST-Net/identity.json to the same directory on the new device, then restart the core to restore the device identity.
Note: Keep your private key file secure. Never share it. A leaked private key allows others to impersonate your device.