SecureDoc Client uses additional port 3333 internally
SecureDoc client installation uses hard-code port 3333 to communicate status from SDService, as at version 5.2SRx and previous.
This was fairly recently uncovered (2012 Q1) when a customer that uses the Juniper Networks Compass PVN product noticed that it failed to work when the SecureDoc client was installed.
Here's the gist of that problem:
Just a heads up that the Juniper Compass issue is due to SDService using port 3333 locally on the laptop. More information about the cause: - Juniper Compass binds itself with port 3333 when it is installed (and will not bind to any other ports afterwards; regardless of whether the port is being used by another program). NOTE: However, if the Juniper VPN Client sofware is uninstalled, then upon automatic re-installation it will see that port 3333 is in use (by SecureDoc), and will choose a different port number.... this is the work-around that was done by Rob's customer.
- SecureDoc (SDService) is then installed and connects using port 3333 automatically (and doesn't check if this port is being used by another program).
- Compass is then started by end-user (but cannot connect to port 3333 and won't try connecting to another free port). The Compass client just hangs and does nothing.
Go-Forward position: Rob DeCarle spoke with Sergey about this and it appears we can improve the design of the port selection (e.g. to not hard code 3333). However, Juniper could also improve their software by using another port should 3333 already be in use. I will know more about this later, but nothing is confirmed.
UPDATE: This issue was fixed in V5.3SR1, so if a customer has this problem AND is unwilling to uninstall the Juniper Compass VPN client software and then re-install it, then the alternative is for the customer to upgrade to V5.3SR1 or later. |
Custom Fields - Version: Affects all versions of SD
|