# RM Programming — Over-Wi-Fi Across Sites/Subnets

## Overview

Programming MOTOTRBO R7 radios and repeaters over Wi-Fi with Radio Management (RM), across sites and subnets. RM Server / Device Programmer runs on **pbr-radio-kl1 (10.8.40.10)**, RM version 2.157.149.0.

Out of the box, RM Wi-Fi programming only works when the radio and the Device Programmer are on the same subnet, because discovery uses mDNS multicast (224.0.0.251:5353) which doesn't route. Four changes were needed to make it work across sites — all four are required.

---

## The Four Fixes

### 1. Disable Windows mDNS on the RM server (registry — most important)

Windows' Dnscache service binds UDP 5353 and silently consumes the radios' incoming discovery announcements — the Motorola Device Programmer never receives them. Radios show *Waiting For Device* forever with no error.

```powershell
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" `
  -Name EnableMDNS -Value 0 -PropertyType DWord -Force
# Then REBOOT the server
```

Verify after reboot — the Motorola DP process (not svchost) must own the port:

```powershell
Get-NetUDPEndpoint -LocalPort 5353 | Select LocalAddress,OwningProcess
```

### 2. Set Device Discovery Server Name in the radio codeplug

CPS → Wi-Fi → per network profile: set **Device Discovery Server Name** to `pbr-radio-kl1` (or 10.8.40.10). This makes the radio send its discovery announcement unicast to the server (routable) instead of local multicast. Set it on **every** Wi-Fi profile the radio uses. DNS-SD port 5353, interval 90 sec.

### 3. RM Machine Authorization

RM Server Utility → Machine Authorization: the machine running the Device Programmer (including the RM server itself) must be listed with the **Programmer** permission ticked. Without it, connections fail with the generic "Failed to connect to the RM server" dialog and jobs never dispatch.

### 4. Use 10.8.40.10, not localhost

In the RM config, Job Processor and Device Monitor/DP settings, set the RM Server address to `10.8.40.10` — not localhost. With localhost, cross-site writes fail with **Error 450** ("connection could not be established with the selected connection type") while local writes still work.

---

## Quick Troubleshooting

<table id="bkmrk-symptomcheck-waiting"><thead><tr><th>Symptom</th><th>Check</th></tr></thead><tbody><tr><td>Waiting For Device forever, cross-site</td><td>Fix 1 — who owns UDP 5353? Windows updates/rebuilds can re-enable mDNS</td></tr><tr><td>Cross-site radio never discovered at all</td><td>Fix 2 — Device Discovery Server Name missing on the active Wi-Fi profile</td></tr><tr><td>"Failed to connect to RM server" dialog</td><td>Fix 3 — Machine Authorization</td></tr><tr><td>Error 450 on cross-site writes only</td><td>Fix 4 — localhost addressing</td></tr></tbody></table>

## Ports

**UDP 5353** (radio → server, discovery) · **TCP 443** (RM server/clients) · **TCP 8002-8003** (DP → radio, programming session) · **TCP 50000-50100 / UDP 20000** (IP Program, repeaters). Traffic currently rides the Palo Alto intrazone-default allow — add explicit rules if radio VLANs move to their own zone.

## Notes

- If this breaks after a Windows update or server rebuild, check the EnableMDNS registry value first.
- If the server IP changes, update it in both the radio codeplugs (Fix 2) and RM component settings (Fix 4).