RM Programming — Over-Wi-Fi Across Sites/Subnets
Overview
| System | Motorola MOTOTRBO Radio Management (RM) — over-Wi-Fi programming of R7 portables and SLR repeaters |
| RM Server | pbr-radio-kl1 — 10.8.40.10 (RM Server, Job Processor, Device Programmer, Device Monitor on one host) |
| RM Version | 2.157.149.0 |
| Status | Working — cross-site OTAP/Wireless (LAN) programming confirmed across routed VLANs (July 2026) |
| Radio VLAN | VLAN 40 per site, 10.<site>.40.0/24 addressing, pbrb_radio SSID (WPA3-Enterprise / EAP-TLS via SCEPman) |
| Author | Mitch Fraser, documented with Claude — 2 July 2026 |
This page documents how RM device discovery and programming actually works over Wi-Fi, and the four independent fixes that were all required to make programming work across sites/subnets. Out of the box, RM Wi-Fi programming only works when the Device Programmer and the radios share the same L2 segment. Each fix below addresses a different silent failure; removing any one of them breaks cross-site programming again, each with a different symptom (see Troubleshooting table at the bottom).
How RM Wi-Fi Discovery Actually Works
Same-subnet (default behaviour)
The RM Device Programmer (DP) discovers radios using DNS-SD over mDNS. The DP sends periodic multicast queries (~every 20 s) for _otap._tcp.local to 224.0.0.251:5353, and radios respond with PTR/SRV/TXT/A records advertising their hostname (e.g. MOTOTRBO_09e0000542803a00.local), their current IP, and the TCP port to program them on (observed: 8003, also seen 8002 in session traffic). Multicast is link-local by design — it does not route across VLANs — which is why programming historically only worked with the DP on the same Wi-Fi network as the radio. This limitation is confirmed in Motorola's own Wi-Fi FAQ.
Cross-subnet (DNS-SD forwarding)
Since DP 2.21.61.0, the radio codeplug supports a Device Discovery Server Name field (CPS → Network → Wi-Fi, per network profile). When populated, the radio sends its DNS-SD announcement as unicast UDP to that host on port 5353 at the configured DNS-SD Interval (PBR: 90 s), instead of relying on local multicast. The radio also leaves the 224.0.0.251 multicast group (visible as an IGMP leave). This unicast announcement routes normally across VLANs/sites and through the Palo Alto like any other traffic.
After discovery, the actual programming session is a normal TCP connection initiated by the DP to the radio, on the port the radio advertised in its SRV record (8002/8003).
The Four Required Fixes
1. Windows mDNS registry change on the RM server (critical)
Symptom it fixes: Unicast DNS-SD announcements visibly arrive at the RM server in Wireshark, but Device Monitor never shows the radio as connected and jobs sit at Waiting For Device forever. No error is ever logged.
Root cause: Windows' native mDNS responder (inside the Dnscache service, running in svchost) binds UDP 5353 on all interfaces. Unicast UDP is delivered to a single socket — Windows' stack wins the bind and silently consumes every announcement. The Motorola DP never receives a single packet. (Multicast delivery goes to all group members, which is why local discovery still worked.)
Diagnosis:
Get-NetUDPEndpoint -LocalPort 5353 | Select LocalAddress,OwningProcess
Get-Process -Id <PID>
tasklist /svc /fi "PID eq <PID>"
# If svchost/Dnscache owns 5353 instead of the Motorola DP process, this is the fault.Fix — disable Windows native mDNS, then reboot:
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" `
-Name EnableMDNS -Value 0 -PropertyType DWord -Force
# Reboot the server (a Dnscache restart alone is not sufficient — the DP must
# re-attempt its 5353 bind after the port is free).Verify after reboot: re-run Get-NetUDPEndpoint -LocalPort 5353 and confirm the Motorola Device Programmer process now owns the port. Radios should begin showing Connected in Device Monitor within 1–2 DNS-SD intervals (~90–180 s).
Side effect: this disables .local mDNS resolution on the server itself — not relevant for a server role. Note that Apple Bonjour (mDNSResponder) is another known 5353 squatter if ever installed.
2. Device Discovery Server Name in the radio codeplug
Symptom it fixes: Radios on other subnets never discovered at all (multicast can't cross the VLAN boundary).
In CPS/RM, per Wi-Fi network profile: set Device Discovery Server Name to the DP host. PBR value: pbr-radio-kl1 (resolves via the domain suffix; a raw IP 10.8.40.10 also works and removes the DNS dependency). Leave DNS-SD Listening Port at 5353 and DNS-SD Interval at 90 sec.
Important: set this on every network profile the radio may use (e.g. both the MOTOTRBO staging profile and PBRB_Radio) — a profile without it falls back to local multicast only. Confirm the Wi-Fi VLAN's DHCP scope hands out DNS servers that can resolve the internal zone if using a hostname.
3. RM Machine Authorization for the Device Programmer
Symptom it fixes: Device Programmer / Device Monitor fails to connect to the RM Server with the generic error "Failed to connect to the RM server… (5 possible causes)", from any client including localhost, despite the service running, 443 listening, correct domain membership and time sync. Writes queued but never dispatched.
Fix: RM Server Utility → Machine Authorization — the machine running the Device Programmer (including the RM server itself) must be listed and have the Programmer permission ticked. User accounts connecting must also appear under User Authorization. AD authentication succeeding is not sufficient — RM enforces its own authorization list at the application layer after Windows auth.
4. Address all RM components as 10.8.40.10, not localhost
Symptom it fixes: After discovery works, cross-site write jobs fail with Error 450 — "Application has encountered an error. The connection could not be established with the selected connection type" — and packet capture shows no SYN is ever sent toward the radio. Same-subnet writes work.
Fix: In the settings for RM configuration, Job Processor and Device Monitor / Device Programmer, set the RM Server address to 10.8.40.10 (the host's real routable IP) rather than localhost. Components registered via loopback have no valid routable identity to anchor cross-subnet programming sessions from; locally this never matters, so the fault only appears cross-site.
Device Programmer Settings (reference)
| Setting | Value |
|---|---|
| RM Server Address | 10.8.40.10 (not localhost) |
| RM Server Port | 443 |
| Authentication Method | Windows Credentials |
| Communication Method | USB + Wireless (LAN) (+ IP Program for repeaters) |
| DNS-SD Listening Port | 5353 |
| IP Program TCP range | 50000–50100 |
| IP Program local UDP port | 20000 |
Port Matrix
| Port(s) | Proto | Direction | Purpose |
|---|---|---|---|
| 443 | TCP | Clients/DP → RM Server | RM Server / Discovery Server (HTTPS) |
| 5353 | UDP | Radio → DP host | Unicast DNS-SD announcements (Device Discovery Server Name). Also local multicast 224.0.0.251 |
| 8002–8003 | TCP | DP → Radio | Programming session — port advertised in the radio's SRV record. Must be permitted DP→radio VLANs on the Palo Alto |
| 8675 | TCP | Client → DP | RM client to Device Programmer (legacy/documented) |
| 50000–50100 | TCP | DP ↔ device | IP Program (repeaters) session range |
| 20000 | UDP | DP | IP Program local UDP |
| 4005 | UDP | DDMS | Only if DDMS in use |
| 80, 3416, 49202, 49205–49210, 50003, 51020–51030, 56901, 65534 TCP; 50000–50010, 56401 UDP | — | — | Additional ports in the server's Windows Firewall rule set (Motorola KB-derived); retained as configured |
Windows Firewall on the RM server has inbound + outbound rules covering the above (rules "Motorola Test" / "Motorola Test UDP", plus ExecutorService/ExecutorConfigUI.DP app rules). Traffic between the RM server zone and site radio VLANs currently matches intrazone-default (allow) on the Palo Alto — if radio VLANs are ever moved to their own zone, an explicit rule with the ports above is required.
Troubleshooting: Symptom → Cause
| Symptom | Cause / Fix |
|---|---|
| Cross-site radio never appears / job sits at Waiting For Device; mDNS visible in Wireshark on the server | Windows Dnscache owns UDP 5353 — Fix 1 (EnableMDNS=0 + reboot). Verify with Get-NetUDPEndpoint -LocalPort 5353 |
| Cross-site radio never discovered, no unicast 5353 traffic arriving at all | Device Discovery Server Name not set on the Wi-Fi profile in use — Fix 2. Check every profile, not just one |
| DP/Device Monitor can't connect to RM Server (generic 5-cause dialog), even from localhost | RM Machine Authorization missing Programmer permission — Fix 3 |
| Error 450 on cross-site write; capture shows no SYN toward the radio; local writes fine | RM components addressed as localhost — Fix 4 |
| Discovery works, SYN sent to radio on 8002/8003 but no reply | Check Palo Alto policy for those ports, then Aruba client isolation / deny-inter-user-bridging / ClearPass role ACL on pbrb_radio |
| Radio drops offline briefly after a successful write | Expected — Wi-Fi stack restarts to apply config; radio re-announces within ~90 s (DNS-SD interval) |
| Working setup breaks after a Windows update or server rebuild | Re-check the EnableMDNS registry value and 5353 port ownership first — an update or rebuild can restore Windows' mDNS responder |
Useful diagnostics
# Who owns the DNS-SD port
Get-NetUDPEndpoint -LocalPort 5353 | Select LocalAddress,OwningProcess
# Watch for unicast announcements arriving (Wireshark on RM server)
# filter: udp.port == 5353
# Radio announcements every 90 s: PTR/SRV/TXT/A for MOTOTRBO_<id>.local,
# SRV advertises the programming port (8003), A record carries the radio's real IP.
# Watch a job attempt end-to-end
# filter: ip.addr == <radio-ip>
# A healthy write = DP opens TCP to the radio's advertised port, data, clean FIN.Maintenance Notes
- The EnableMDNS registry key is the fragile piece. Any RM server rebuild, OS upgrade, or feature update that re-enables Windows mDNS will silently break cross-site discovery with no error anywhere. Check 5353 ownership first whenever this system misbehaves.
- If the RM server's IP ever changes, update: the Device Discovery Server Name (or DNS record) in radio codeplugs, and the server address configured in Job Processor / Device Monitor / DP settings (Fix 4).
- Remove any test entries from
C:\Windows\System32\drivers\etc\hostson the RM server (a MOTOTRBO_*.local mapping was used during fault-finding). - Consider DHCP reservations on VLAN 40 for repeaters/fixed radios to keep addresses stable for troubleshooting.
- New radios: ensure the Wi-Fi profile template includes Device Discovery Server Name on all profiles before fleet rollout.
- Only one OTAP-configured DP is supported per RM system — the central DP model relies entirely on the unicast DNS-SD forwarding above. If it ever proves unreliable, the fallback is a lightweight per-site Device Programmer (NUC/VM) connecting back to the central RM Server.