WinDiscovery discovers devices but cannot configure or update them

Symptoms

• Devices appear in WinDiscovery but configuration changes fail
• Firmware update or programming operations fail, time out, or do not start
• Discovery works, but device control functions do not

Possible causes

• Firewall or endpoint rules block WinDiscovery traffic or responses on UDP port 6163.
• VLAN, routing, or network-security policies prevent reliable communication between the management PC and device.
• Device discovery completes, but subsequent communication is interrupted.

Troubleshooting steps

1. Confirm whether the failure is discovery-only or control-only.
   If discovery works but control fails, check whether WinDiscovery communication remains reliable after discovery completes.
2. Test from a PC on the same subnet as the device.
   If control works on-subnet but fails across VLANs, your network is likely blocking control or programming traffic between segments.
3. Ask IT to allow the required control and programming traffic.
   WinDiscovery relies on UDP port 6163. Ask IT to check rules for the management PC, device, and return traffic. Use the shared port and network reference when reviewing network policy.
4. Use direct device management where applicable.
   If policy prevents remote programming, manage the device through approved methods on the local subnet.

Firmware compatibility and legacy hardware

Firmware must match the product and hardware platform. Older Rabbit or ZiLog processor designs have code-space and resource limits that prevent use of firmware built for the newer Kinetis platform. A unit running 3.x firmware may therefore lack newer features, including SNMP, and generally cannot move to current-generation firmware.

Firmware in the 4.8.x or 5.x generation is a useful clue that a device may belong to the newer platform, but its version or manufacture date alone does not establish an upgrade path. Compatibility varied by product and hardware revision, and there is no complete historical matrix covering every unit.

1. Record the exact model, serial number, hardware revision if available, and installed firmware version.
2. Check the Masterclock firmware resources and the update instructions for that model.
3. Confirm the supported target version and any required intermediate steps with Masterclock Support when the platform is uncertain. A firmware number offered for another model is not evidence of compatibility.

Configuration or NTP client changes after an update

A normal firmware update is expected to preserve configuration, including whether the NTP client is enabled. An update procedure that requires or causes a factory reset can restore defaults, and not every product enables its NTP client by default after a reset.

1. Before updating, record the current configuration, NTP client enable state, server addresses and active reference.
2. After updating, compare those settings and verify synchronization/reference status and the required outputs.
3. If the NTP client is disabled, determine whether a factory reset was part of the procedure. Restore the intended client configuration and verify it synchronizes.
4. If settings changed without a factory reset, treat that as abnormal. Record the previous and new firmware versions, changed settings and update steps, then provide them to Masterclock Support for investigation.

Related articles

• Network ports and protocols for WinDiscovery and Masterclock applications
• WinDiscovery status is intermittent or garbled