Support Forums

I am unable to connect to remote computers in my Windows 2003 TCP/IP environment.

I am able to push a servlet to a remote computer using port 6518 and port 80.

When I try to connect, it times out.

I can ping the remote machine and the firewall has been set to open port 6518.

I am using a WinXP Pro computer and trying to connect to a W2K computer sitting in the office 20 feet away from me.

Any ideas would be appreciated.

Scott,

Looks like this could be one of a couple of issues.

1. you have a firewall on your computer preventing the connection back to your system. ProDiscover requires the same port to be open in both directions. So, if you have pushed the remote agent out on port 6518, then the user preferences under the file menu for PDServer needs to also be set to 6518. Likewise of you change the push settings to port 80, the user preferences also need to be set to port 80.  

2. Another common issue is that most users will make sure the remote firewall settings are set to allow the port in use, but forget to turn off or set a rule on the local console firewall.

We have also seen several instances where a firewall has been turned off, but in fact is still enforcing rules.

I've attached a white paper with some checklists that you may find helpful.

Regards,

Thanks for taking the time to post to the forums. ProDiscover uses MS file and print sharing to deploy the remote agent to the target machine. The actual connection happens on TCP port 6518 by default. From what you've described above it seems that packet filtering somewhere between the two computers is at fault.

Port 6518 needs to open both inbound and outbound on both machines and at any point inbetween the 2 systems.

Also, the Windows Firewall service is notorious for reporting that it is stopped but the service remains running. You may want to check there as well.

Lastly, please review the forums postings below for more detailed information. Feel free to contact me directly at: support AT techpathways DOT COM

http://toorcon.techpathways.com/cs/forums/thread/184.aspx

http://toorcon.techpathways.com/cs/forums/thread/8.aspx

Scott,

The remote agent push uses standard MS ports for file transfer as well as remote registry services and network commands to start the remote service. The remote agent port setting is strictly used after the push for agent to console communications.  

I’ve found the windows firewall logs helpful in determining if it blocked a connection even when off. By turning on the firewall and ensuring the firewall logging is turned on and checking the log for blocked port connection attempts. Luckily even if the service is off after logging has been turned on blocked entries are still made.

Another problem that comes to mind when people are testing is that they will try and run two remote agents on the same port at the same time, or run the console and the agent on the same system with the same port settings. This can easily happen while testing and the side effect is that only one instance/application will be able to bind to the selected port (normally the first), or that the confusion will kill that port on the IP stack of the systems being affected.

I’ve attached the whitepaper.

Chris,

Thank you for your help. It seems the firewall admin "neglected" to give me both inbound and outbound access on port 6518. His boss gave me the correct access.

But I also discovered that the pdserver.exe is not executing. I am using psexec to remotely execute pdser.exe.

Did I miss a step?

Scott,

Glad to hear of the progress. Normally when the remote agent is not starting it's because of one of two things:

1. Remote registry services are not running on the remote system preventing us from reading the remote sytem vars needed to set the path info in the DFTSrv.ini. You can usually confirm this by reading the dftsrv.ini located in the system32 dir of the remote system. You'll see of the full path information is missing.

2. Another problem could be something preventing the application from running on the remote system. This could be anything from Permissions settings, or MS Data Execution Prevention, to local IA tools like AntiVirus.