Our approved controller network has one laptop that sometimes pings but times out reading identity; another has worked, with incomplete notes. What comparison would isolate endpoint, route and service without speculative controller changes?
What target does each actual launch use, and which interface and source address carry the request? Capture those with the loaded configuration and SDK version, then have the network owner verify the intended endpoint before interpreting ping as controller identity.
Targets and request versions match; network owner confirms the endpoint, but the workshop laptop selects an old static route through its wireless interface instead of the approved bench path
That sounds like a specific laptop-side difference to investigate. Does a request trace confirm the chosen path, Louis, rather than only a route-table entry that might not be the one used by this launch?
Yes, the trace confirms it; administrator has identified the obsolete route as part of an earlier bench setup and is removing it through the approved change process
Repeat the documented identity request afterwards and record the returned controller identity. A corrected route and a successful ping would still leave the actual service response unverified.
The corrected route now carries the request over the approved connection, and the documented read returns the expected controller identity; no controller settings changed
Thanks for the actual response result. Has a fresh launch reproduced it, and will the next person find the current bench notes instead of reinstating that old route from memory?
Fresh launches after reopening return the same expected identity; administrator replaced the obsolete bench note and recorded the route change. That resolves this laptop's timeout, not a claim that ping alone proved the service all along
Keep the before-and-after observations with those notes. They distinguish the proven obsolete-route fault from the other causes you considered but did not find.