General Connector Troubleshooting

If there is still an issue, then please verify which error message you are seeing when deploying the connector:

Error message	When the issue appears	Solution
N/A	Status stays as pending for a very long-time (no error message generated)	If Linux, verify the account is able to run passwordless sudo commands
Invalid credentials		Check this article Invalid Credentials Errors
No IP Found	Windows endpoints behind a NAT	Verify the WSUS endpoint configuration is pointing to the private IP of the WSUS server
Insufficient permissions (!requiretty)	when trying to deploy the connector on your Linux endpoints	See this article.
Intigua currently disconnected	Deploying the connector	Verify that port 443 is open from endpoint to JetPatch server Check worker.log via manager logs Check connector log of endpoint connected on machine itself If this is a new deployment and your forgot to set a static IP address, then likely the IP address of the endpoint is using the old IP (see instructions to help modify to hostname)
SMB Operation Failed	Deploying the connector on windows	Check SMB2/445 Connection Check if the account has read/write/execute permissions on Windows/Temp or configure it to a different folder Check worker.log via manager logs and look for access denied ADMIN$. See this article for a fix.
Intigua deployment failed, ip:	Deploying the connector	Likely /usr/share/intigua/certs permission issue. You can verify by looking at worker.log via manager logs
Task progress could not be tracked	On a connector restart	Increase throttling CPU & Memory values

Compare traceroute output from the machine experiencing issues and another machine from the same VLAN/network.

On Linux, use traceroute (with TCP flags), nc (Netcat), or nmap to verify that specific ports are open and reachable.

Method	Command	Description
TCP Traceroute (Port 22)	`traceroute -T -p 22 <Endpoint_IP>`	Traces the path using TCP SYN packets on port 22.
TCP Traceroute (Port 443)	`traceroute -T -p 443 <JetPatch_IP>`	Traces the path to the Manager/Repo on HTTPS port.
Alternative Traceroute	`tcptraceroute` `<JetPatch_IP>` `443`	A specialized tool for bypassing firewalls that block ICMP.
Netcat (Simple Scan)	`nc -zv` `<JetPatch_IP>` `443`	Quickly checks if port 443 is listening (zero-I/O, verbose).
Netcat (Source Port)	`nc -zv -p 1234` `<JetPatch_IP>` `443`	Checks connectivity while specifying a local source port (1234).
Nmap Scan	`nmap -p 443` `<JetPatch_IP>`	Checks the status of port 443 and identifies the service.

Windows uses tracert for path analysis, but requires specific arguments or alternative commands for port-specific testing.
Standard Path Trace: tracert <JetPatch_IP> Use this to identify where a packet is being dropped in the network hops.
TCP Specific Trace: traceroute -T -p 445 <Endpoint_IP> (Note: Requires specific environment tools or PowerShell equivalents like Test-NetConnection).
Check Local Listening Ports: netstat -ano | findstr :443 Verifies if the local machine is currently using or listening on port 443.
Also, look at curl:

curl -v -L 192.168.1.1

openssl s_client -connect 192.168.1.1:443 (Windows app, usually built-in in Linux)

Linux Only:

Check the post_install_log file in /tmp
Verify the account has appropriate permissions (likely to be an issue if the activity is not timing out after a few minutes)
Check SElinux configuration (it may limit the connection). More information can be found here.
Deploy the connector from the endpoint itself
- If connector is failing to deploy from windows itself, look at tcping -t <Core-Server-IP/Name> 443
Look at manager logs, specifically the worker.log file in the logs folder

For any other issue, please contact the JetPatch support team with the logs attached.