Device Package Usage

Connect to the services on a device running the remote.it Device Package, and use the built-in connectd network diagnostics to verify the target device's connectivity.

Connecting to Services

Once remote.it is installed on the target device and its services are configured, you can connect to those services from any remote.it client: the Desktop app, CLI, Web Portal, mobile apps, or the API.

remote.it supports two connection types — direct peer-to-peer and proxy — and not every client supports both:

Client	Peer-to-peer	Proxy
Desktop	✓	✓
CLI	✓	✓
Web Portal		✓
API		✓

The mobile apps can also connect to your device's services.

For details on making and managing connections, see the documentation for Desktop, the Web Portal, or the API.

Checking the Target Network

The Device Package ships only the connectd command, and it is not added to the system PATH. Run these diagnostics on the target device itself — they confirm the device can reach remote.it's servers and any other targets on your LAN.

Because connectd isn't on the PATH, call it with its full path — for example /usr/share/remoteit/connectd -n on Linux — or cd into the install directory first. The examples below use connectd for brevity.

If you run antivirus or endpoint protection on the device, you may need to allow connectd to run.

Network diagnostics — connectd -n

Run connectd -n to confirm the network is configured to allow a remote.it connection. It checks DNS resolution, TCP and UDP connectivity to remote.it, how your router handles NAT and ports, and runs internal cryptography self-tests.

connectd -n

Running Network Diagnostics
---------------------------------
Checking if DNS works ... .[OK]
Checking TCP connectivity to remote.it...<oip=10.0.0.106> [OK]
Checking UDP connectivity to remote.it...
Send to 69.64.90.20:5959 [] [mip=##.##.###.###] [oport=59450 mport=59450] [preserve port] 
Send to 69.64.90.20:5960 [] [mip=##.##.###.###] [oport=59450 mport=59450] [no remap] [preserve port] 
Send to 69.64.90.128:5961 [] [mip=##.##.###.###] [oport=59450 mport=59450] [no remap] [preserve port different IP] [OK]
Checking if NAT-PMP Router is found...[NOT FOUND]

This router preserves ports, this is optimal.
This router doesn't remap new connections to new ports.
Endian : Little
SHA1 test:
  passed.
RC4 test:
  passed
XXTEA test:
  passed.
Looks compatible.

What to look for: every check should report [OK], and the run should end with Looks compatible. A router that preserves ports and doesn't remap connections (as shown above) gives the best chance of a direct peer-to-peer connection.

NAT timeout check — connectd -nat

For extra confidence that connectivity is stable — and that the device won't report inaccurate offline events — run connectd -nat. It measures how long your NAT keeps a UDP mapping open. A calculated time of around 30 seconds or more is desirable.

connectd -nat

Running Nat UDP Reply Timeout Checker
-------------------------------------
Checking 1 seconds on port 64968 (54.245.28.114)[good reply at 1 seconds] 
Checking 2 seconds on port 62130 (54.245.28.114)[good reply at 2 seconds] 
Checking 4 seconds on port 63878 (54.245.28.114)[good reply at 4 seconds] 
Checking 8 seconds on port 59889 (54.245.28.114)[good reply at 8 seconds] 
Checking 16 seconds on port 64141 (54.245.28.114)[good reply at 16 seconds] 
Checking 32 seconds on port 64688 (54.245.28.114)[Failed at 32 seconds] 
Checking 24 seconds on port 51136 (54.245.28.114)[good reply at 24 seconds] 
Checking 28 seconds on port 50498 (54.245.28.114)[good reply at 28 seconds] 
Checking 30 seconds on port 60809 (54.245.28.114)[good reply at 30 seconds] 
Checking 31 seconds on port 52161 (54.245.28.114)[Failed at 31 seconds] 
Calculated NAT map time is 30 seconds exiting.

Running UDP Nat MAP Timeout Checker
---------------------------------
Setting up NAT mapping
[mip=##.##.###.###] [oport=55156 mport=55156] Trying for 120 seconds
testing mapping (54.245.28.114)..[mapping invalid was 55156 now 55156] [new timeout to try 60]
Trying for 60 seconds
testing mapping (54.245.28.114)..[mip=24.13.204.189] [oport=55156 mport=55156] [mapping still at 55156] [increase timeout to 90 ]
Trying for 90 seconds
testing mapping (54.245.28.114)..[mapping invalid was 55156 now 55156] [new timeout to try 75]
Trying for 75 seconds
testing mapping (54.245.28.114)..[mapping invalid was 55156 now 55156] [new timeout to try 67]
Trying for 67 seconds
testing mapping (54.245.28.114)..[mapping invalid was 55156 now 55156] [new timeout to try 63]
Trying for 63 seconds
testing mapping (54.245.28.114)..[mapping invalid was 55156 now 55156] [new timeout to try 61]
Trying for 61 seconds
testing mapping (54.245.28.114)..search completed NAT timeout calculated to ~60 seconds, exit

What to look for: a calculated NAT map time of roughly 30 seconds or more. Very short mapping times can cause remote.it to see the device as intermittently offline.

Connectivity check — connectd -nc <server:port>

Use connectd -nc <server:port> to test whether the device can open a TCP connection to a specific address. This is useful for confirming a LAN target or jump destination is reachable before you add it as a service.

connectd -nc google.com:80

Connectivity Check
SUCCESS Connect to google.com:80

SUCCESS confirms the device can reach that host and port. If it fails, check that the target is running and reachable from the device's network.

Troubleshooting Connectivity

If a diagnostic check doesn't pass:

• Confirm the device has working internet access and DNS resolution.

• Make sure the device can reach remote.it's servers over the required outbound ports — no inbound port forwarding is needed. See remote.it's firewall and port requirements for the specific ports.

• Allow connectd through any local antivirus or endpoint protection.

• Re-run connectd -n after each change.

Remember that the Desktop and CLI can use faster peer-to-peer connections, while the Web Portal and API always connect through a proxy.