> For the complete documentation index, see [llms.txt](https://docs.remote.it/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.remote.it/software/device-package/usage.md). # Device Package Usage ### 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](https://app.remote.it), 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. {% hint style="info" %} For details on making and managing connections, see the documentation for [Desktop](https://support.remote.it/hc/en-us/articles/360048935411-Connections), the [Web Portal](https://support.remote.it/hc/en-us/articles/360048707812-The-Devices-Page), or the API. {% endhint %} ## 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. {% hint style="info" %} 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. {% endhint %} {% hint style="warning" %} If you run antivirus or endpoint protection on the device, you may need to allow `connectd` to run. {% endhint %} #### 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... [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. ``` {% hint style="info" %} **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. {% endhint %} #### 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 ``` {% hint style="info" %} **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. {% endhint %} #### Connectivity check — `connectd -nc ` Use `connectd -nc ` 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 ``` {% hint style="info" %} `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. {% endhint %} ### 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.remote.it/software/device-package/usage.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.