abe Posted July 19, 2004 Report Share Posted July 19, 2004 A number of us have noticed that Retrospect 6.5.350 does not restrict itself to port 497 when accessing clients. In addition to 497 here, my Trend Micro firewall reports access on a number of upper level ports. Here it has been anywhere from 1064 up to 5000, but the behavior is inconsistent and therefore even more problematic. This morning I noticed the following: I use a Plextor PX-708UF external USB2 DVD burner. I occasionally forget to turn it on before my script executes, and Retrospect, sadly, fails if the drive is not present. A more user-friendly behavior would be to prompt the user to install (i.e., turn on in my case) a backup device rather than failing and quitting. The user should be able to install the device, then prompt Retrospect to continue, at which point it should detect the device and continue the script. Anyhow, I noticed that after I turned on the burner and restarted Retrospect, it failed to find my client with an error -530 (client not found). The cause, upon checking my firewall logs, was that Retrospect had decided to change the upper-level ports it wanted to use following the "backup device not detected" script failure. Whereas previously I had been able to set a firewall exception to allow access on ports 1100-2000 and back up successfully, *after* the device not present error it tried port 2175, then ports 1064 and 1067. When I changed my exception to allow 1000-2200, the client was again detected and backup proceeded normally. My current hypothesis is that the missing device prompted Retrospect to change its port access, but this doesn't exactly lead to a workaround. I already turn the burner on before Retrospect starts as a general rule. This issue *really* must be addressed. It is a security risk to allow a range of ports just to accommodate Retrospect's penchant for random port access, and would become an administrative nightmare with increased numbers of clients. I would be quite happy to work with a Dantz engineer if it would help get to the bottom of the issue and lead to a fix. Abe Hendin AtYourSpeed Consulting Link to comment Share on other sites More sharing options...
awnews Posted July 19, 2004 Report Share Posted July 19, 2004 Quote: A more user-friendly behavior would be to prompt the user to install (i.e., turn on in my case) a backup device rather than failing and quitting. The user should be able to install the device, then prompt Retrospect to continue, at which point it should detect the device and continue the script. Abe Hendin AtYourSpeed Consulting I know this wasn't the main point of your post, but I wanted to offer a counter comment. Retrospect has enough issues *now* with not always "flagging the error and moving on" so that even though the *current* (errored) script has a problem, subsequent scritps that would work fine are blocked. I do *not* want a script failing for a missing backup device to throw up a dialog and wait forever rather than just failing the script and moving on to other scripts and backup devices. Link to comment Share on other sites More sharing options...
abe Posted July 19, 2004 Author Report Share Posted July 19, 2004 Quote: I do *not* want a script failing for a missing backup device to throw up a dialog and wait forever rather than just failing the script and moving on to other scripts and backup devices. Hi, GoAWest. You're absolutely right about this: such a problem should be avoided by coding a "no device" prompt similar to the media request timeout: if a device isn't installed within a user-specified number of minutes, Retrospect would move on to the next script. Those who don't have other devices could set the timeout to "never" just as they can with the media request timeout, and those who have other devices could set an appropriate timeout. Link to comment Share on other sites More sharing options...
abe Posted July 21, 2004 Author Report Share Posted July 21, 2004 Confound it!! It just wanted port 2999 this morning and failed, so I had to change my port exceptions YET AGAIN, this time to 497,1000-4000. And then, when I restarted Retrospect to run the script I prepared to do just the client after such a failure occurred, it said it couldn't gain access to the burner! Closing Retrospect, then power cycling the burner, then trying again, worked. This is truly infuriating behavior. Abe the Annoyed Link to comment Share on other sites More sharing options...
natew Posted July 22, 2004 Report Share Posted July 22, 2004 Hi As I understand it there is no way to control which port the client connects to when it connects back to the Retrospect server. The initial UDP communication between client and server takes place on port 497 but after that the OS bumps it to another open TCP port to acutally copy data. I have heard the reason for this but I'm having a hard time digging it up now... The CD issue happens because the device needs to be present when Retrospect starts so it can load a driver for said device. Turning on the device and then running a device scan in the configure->devices window might help but it is unlikely. Retrospect uses custom drivers rather than windows drivers for CD/DVD and Tape. As a result you don't get the same "plug in and go" functionality you would with Windows. Thanks Nate Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.