Jira Asset Discovery - Agent scan getting constantly stuck

Question

Hi all,

We have been trying to roll out Jira Asset Discovery in our org.

The Agentless scan works fine, as it just goes onto the network and discovers with no issues.

We have decided to move to an agent based solution, and this is currently being tested on a single subnet, with a small range of windows devices, some with and some without the agent.

When we run this on a specific IP address, this runs completely fine, however when we run this on a range, and the service discovers a device without agent, the discovery completely stops after the below:

25/09/2026 10:08:45: [Error] Retry read net message 2/10 in 1 seconds...

25/09/2026 10:08:46: [Error] Retry read net message 3/10 in 1 seconds...

25/09/2026 10:08:47: [Error] Retry read net message 4/10 in 1 seconds...

25/09/2026 10:08:48: [Error] Retry read net message 5/10 in 1 seconds...

25/09/2026 10:08:49: [Error] Retry read net message 6/10 in 1 seconds...

25/09/2026 10:08:50: [Error] Retry read net message 7/10 in 1 seconds...

25/09/2026 10:08:52: [Error] Retry read net message 8/10 in 1 seconds...

25/09/2026 10:08:53: [Error] Retry read net message 9/10 in 1 seconds...

25/09/2026 10:08:54: [Error] Retry read net message 10/10 in 1 seconds...

We have checked firewall rules and any other possible blocker, however we cannot explain this behavior.

We have also trying to increase the timeout as well as running the service on a sandbox device on the same subnet, but we got the same outcome.

Sami Shaik · Answer

@Josh , agreed on the split, and one number to fix so @Davide Cioranu does not test the wrong thing: the agent port is 51337, not 5137 (Atlassian's system requirements page: Discovery outgoing TCP 51337, agent inbound TCP 51337, configurable in discovery.cfg). Davide, that is the port for the Test-NetConnection .

Josh · Answer

Hi Davide — +1 to Gabriela and Sami: "Retry read net message" means Discovery already opened something on that IP and is waiting on the agent protocol, so a wide Agent IP Range that includes agentless hosts will stall the whole scan.

Two extra practical tips:

* Keep Agent IP Range = only known agent hosts (or a tight subnet that is 100% agent-installed). Put the broader network on an agentless scan pattern instead of mixing both in one agent pattern.
* If you must scan a mixed range while rolling out agents, split into two patterns: one agent pattern with the small allow-list of agent IPs, one agentless for the rest. That matches what you already see — single IP with agent works; range that hits a non-agent hangs.

After narrowing the range, re-run and confirm the log moves past those IPs without the 10-retry loop. If it still hangs on a host that does have the agent, then look at firewall/port 5137 end-to-end for that one IP.

Sami Shaik · Answer

@Davide Cioranu ,

@Gabriela - LeanZero advice to narrow the Agent IP Range is right and worth doing anyway, but your log tells you more than "there is no agent there", and it points at why the scan hangs instead of skipping.

Read the error literally. "Retry read net message" is the Discovery tool waiting for a reply on a connection it already has. A device with no agent and nothing listening on the agent port (51337 by default) would refuse the TCP connection outright, the tool would log a connect failure and move to the next address in under a second. Ten read retries means the connection was accepted and then went silent. So on the devices without an agent, something is answering on 51337 and not speaking the agent's protocol. In practice that is one of three things:

* A firewall or IPS in the path doing TCP interception (accepting the SYN on behalf of the host and then dropping the session). Common on segmented subnets with inline inspection; the same appliance that lets the single-IP test through can behave differently on a sweep.
* Another service bound to 51337 on the agentless machines (a leftover agent install that is stopped but still has a listener, or an unrelated tool).
* Windows Filtering Platform rules that "stealth" the port (accept and hold rather than reset), which some endpoint security products do by default.

The five-minute test, from the Discovery host, against one agentless device that stalls the scan:

Test-NetConnection <ip> -Port 51337

If TcpTestSucceeded is True, the host (or something in front of it) is accepting the connection and you have found the stall. Then, on that device: netstat -ano | findstr 51337 to see whether a local process owns the port (case 2), or nothing (case 1 or 3, in which case the security team owns the next step). If TcpTestSucceeded is False with an immediate refusal, the theory is wrong and the debug-level log Gabriela mentioned is the next move.

Two settings that limit the damage while you chase it: keep the agent-based scan's range to known agent hosts (Gabriela's point) and let the agentless scan cover the subnet, and if the tool exposes a connect or read timeout separate from the retry count, lower the read timeout so a silent accept costs one second, not ten.

If you post the Test-NetConnection result, I can point at which of the three it is.