Articles in this section

General Connector Troubleshooting

Overview

This article provides comprehensive troubleshooting guidance for JetPatch connector deployment issues. 

It covers common error messages, their causes, and step-by-step solutions for both Linux and Windows environments.

Initial Verification Steps

First, verify the Connector Protocols, Permissions, and Users.

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

  1. Go to platform configuration
  2. Navigate to the servers tab
  3. Search for the endpoint with issues and click on it 
  4. Navigate to the logs tab and see details. 

Common Error Messages and Solutions

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

JetProxy Limitations

Note: You cannot deploy connectors behind JetProxy, because JetProxy is a web proxy (thus, cannot use SSH or SMB). Thus, deploy the connector from the endpoint itself

Alternative Deployment Methods

If you are unable to deploy the connector by itself:

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

Connectivity Testing

Linux Connectivity Tests

On Linux, use

traceroute
nc
nmap
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 Connectivity Tests

Windows uses

tracert
  • Use this to identify where a packet is being dropped in the network hops.

Standard Path Trace:

tracert <JetPatch_IP>
  • (Note: Requires specific environment tools or PowerShell equivalents.)

TCP Specific Trace:

traceroute -T -p 445 <Endpoint_IP>
  • Verifies if the local machine is currently using or listening on port 443.

Check Local Listening Ports:

netstat -ano | findstr :443
  • Also, look at curl:
curl -v -L 192.168.1.1
  • Check the SSL handshake from the client
openssl s_client -connect 192.168.1.1:443

(Windows app, usually built-in in Linux)

Linux-Specific Troubleshooting

  • 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 the connector is failing to deploy from Windows itself, look at
tcping -t <Core-Server-IP/Name> 443
  • Look at the manager logs, specifically the worker.log file in the logs folder

Additional Support

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

 

Related articles

Comments

0 comments

Please sign in to leave a comment.