RM Programming — Over-Wi-Fi Across Sites/Subnets
Overview
Programming MOTOTRBO R7 radios and repeaters over Wi-Fi with Radio Management (RM), —across over-Wi-Fi programming of R7 portablessites and SLRsubnets. repeaters
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 Programmerradio 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 DPare on the same Wi-Fisubnet, networkbecause asdiscovery theuses radio.mDNS This limitation is confirmed in Motorola's own Wi-Fi FAQ.
Cross-subnetmulticast (DNS-SD224.0.0.251:5353) forwarding)
which Sincedoesn't DProute. 2.21.61.0,Four thechanges radiowere 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 UDPneeded to thatmake hostit 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 normallywork across VLANs/sites and— throughall thefour Paloare 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).required.
The Four Required Fixes
1. Disable Windows mDNS registry change on the RM server (critical)registry — most important)
SymptomWindows' itDnscache fixes:service Unicastbinds DNS-SDUDP 5353 and silently consumes the radios' incoming discovery announcements visibly arrive at— the RM server in Wireshark, butMotorola Device MonitorProgrammer never showsreceives thethem. radioRadios as connected and jobs sit atshow Waiting For Device forever.forever Nowith errorno 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:error.
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters" `
-Name EnableMDNS -Value 0 -PropertyType DWord -Force
# RebootThen REBOOT the serverVerify Dnscacheafter restart alone is not sufficientreboot — the Motorola DP process (not svchost) must # re-attempt its 5353 bind afterown the portport:
Verify after reboot: re-run
Get-NetUDPEndpoint -LocalPort 5353 | Select LocalAddress,OwningProcessand confirm theMotorola Device Programmer processnow 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. Set Device Discovery Server Name in the radio codeplug
SymptomCPS it fixes: Radios on other subnets never discovered at all (multicast can't cross the VLAN boundary).
In CPS/RM, per→ Wi-Fi → per network profile:profile: set Device Discovery Server Name to the DP host. PBR value: pbr-radio-kl1 (resolvesor via10.8.40.10). This makes the domainradio suffix;send aits rawdiscovery IPannouncement 10.8.40.10also works and removesto the DNSserver dependency).(routable) Leaveinstead DNS-SDof Listeninglocal Portmulticast. atSet 5353 and DNS-SD Interval at 90 sec.
Important: set thisit on every networkWi-Fi profile the radio mayuses. useDNS-SD (e.g.port both5353, theinterval MOTOTRBO90 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.sec.
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 —Authorization: the machine running the Device Programmer (including the RM server itself) must be listed and havewith the Programmer permission ticked.ticked. UserWithout accountsit, connectingconnections mustfail alsowith appearthe undergeneric User"Failed Authorization.to ADconnect authenticationto succeeding is not sufficient —the RM enforcesserver" itsdialog ownand authorizationjobs listnever at the application layer after Windows auth.dispatch.
4. Address all RM components asUse 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,config, Job Processor and Device MonitorMonitor/DP / Device Programmer,settings, set the RM Server address to 10.8.40.10 (the— host'snot reallocalhost. routableWith IP) rather than localhost. Components registered via loopback have no valid routable identity to anchorlocalhost, cross-subnetsite programmingwrites sessionsfail from;with locallyError this450 never("connection matters,could sonot be established with the faultselected onlyconnection appearstype") cross-site.while local writes still work.
DeviceQuick Programmer Settings (reference)
Port Matrix
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 → CauseTroubleshooting
| Symptom | |
|---|---|
| |
| Cross-site radio never | Fix 2 — Device Discovery Server Name |
| Error 450 on cross-site | |
Ports
UDP to5353 (radio on→ 8002/server, discovery) · TCP 443 (RM server/clients) · TCP 8002-8003 but(DP no→ reply
Notes
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
C:\Windows\System32\drivers\etc\hosts