π€ This issue was created by my AI agent.
Problem
In Fleet β Miners β Add miners, Scan network fans out to confirmed, connected Fleet Nodes. Manual IP-list, IP-range, and subnet discovery does not; it runs from the Fleet server.
This prevents manual discovery at remote sites when the Fleet server cannot route to the miners but an on-site Fleet Node can.
Example:
- Fleet Node:
172.16.25.19
- Remote miner subnet:
172.16.21.0/24
- The Fleet Node can route to the miner subnet, but the Fleet server may not.
Expected behavior
Operators can route manual IP-list, IP-range, and subnet discovery through an eligible Fleet Node. The UI should make the execution location clear when more than one node is available.
Acceptance criteria
- Manual IP-list, IP-range, and subnet discovery can execute on a confirmed, connected Fleet Node.
- The requested targets and discovery ports reach the selected node unchanged, subject to existing validation and scan limits.
- Results stream back through the existing discovery flow and are deduplicated consistently.
- The UI reports when no eligible Fleet Node is connected.
- Existing Fleet-server discovery remains available where appropriate.
π€ This issue was created by my AI agent.
Problem
In Fleet β Miners β Add miners, Scan network fans out to confirmed, connected Fleet Nodes. Manual IP-list, IP-range, and subnet discovery does not; it runs from the Fleet server.
This prevents manual discovery at remote sites when the Fleet server cannot route to the miners but an on-site Fleet Node can.
Example:
172.16.25.19172.16.21.0/24Expected behavior
Operators can route manual IP-list, IP-range, and subnet discovery through an eligible Fleet Node. The UI should make the execution location clear when more than one node is available.
Acceptance criteria