Jump to content

error 530 on just one client since upgrading to Retro 11 (Win 10)


x509

Recommended Posts

My home LAN consists of my my desktop, which was just upgraded to Retrospect 11 (latest release), and still running Win 7 Pro 64.  I also back up two clients, both running Win 10 Pro 64 and the Retro 11 client.

No issues with client "A", but with client "C" I frequently get error 530 - client not found.  I have been using the Multicast access method to access clients for years and years now without problems. Until now.

 

Any suggestions for workarounds?  Should I report this to Retrospect management?

Link to comment
Share on other sites

It would probably be a good idea to start out by trying the workaround I reported in the OP of this thread in the "Retrospect 9 or higher for Macintosh" forum.  I enthusiastically reported that workaround, which came from A. of Retrospect Support, because it initially solved my -530 problems.  However, as you will see from my later posts in the same thread, the workaround stopped working for me after a week or so; the same thing happened other times I tried it later.

 

My setup is somewhat similar to yours, except that—besides the fact that I am running Macintoshes instead of Windows machines—my "desktop" tower machine is only used for running a Retrospect "backup server" (and is shut down when it is not time to run the scheduled script of the day), and my main machine is a laptop that is one of my two clients.  It is the laptop that now almost always gets a -530 error when I back it up daily, while my other client—which is an old tower running a Retrospect legacy client—never gets an error when I back it up weekly as part of a Recycle Media Set backup of all my HDDs.

 

I have been running Retrospect Mac 12.5 since last September (and Retrospect 12.0 since the July before that—I had previously been running Retrospect from at least 1995 to 2010), but I only started getting -530 errors in February.  I have not bothered to pay to upgrade to Retrospect Mac 13, the equivalent of Retrospect Windows 11, because my Internet upload speed is too slow for cloud backup and the other bug fixes were not compelling.  My laptop and my "backup server" machine have both been running Mac OS X 10.10.5 since last September; I have not updated them to OS X 10.11 because it is reported to have a number of new bugs.

 

By all means "contact our technical support group at support@retrospect.com or online at http://www.retrospect.com/support" as Mayoff says—but you won't find any other contact at www.retrospect.com/support except a phone number (where A. will tell you the same workaround) and I think you already know everything in the Knowledge Base article that Lennart links to below.  I have created a three-post thread on the "Retrospect bug reports" sub-forum  of "Retrospect 9 or higher for Macintosh" forum, pointing to the thread I have linked to above.  There is no indication that Retrospect Inc. has looked at either of the threads.  However, based on what A. told me back in February, the Retrospect Inc. engineers are aware of the -530 problem but it appears that they are having trouble reproducing it.  In my last post in the three-post thread, I offered to try to give the engineers a portable HDD copy of my laptop client's HDD—since that machine gets -530 errors so reliably.  It's been several days since I made the offer, but I haven't heard back from Retrospect Inc..

 

I hope the workaround works more permanently for you than it did for me.

Link to comment
Share on other sites

Lennart,

 

I did a search on this error and found that same KB article.  The main Retrospect system, the "server" and both clients are in the same room.  The client "A," which is backed up fine, is on the other side of the room.  Client "C," which has the problems, is a laptop sitting on the same desk as the monitor/keyboard and mouse so I can monitor both at the same time.

 

Quoting that article;

 

  1. Make sure the client computer is connected to the network and turned on and that it is not powered off by energy saving software. Retrospect can not wake up a sleeping client computer in most cases. Try a simple restart of the client computer. - BY INSPECTION IT IS ON.

  2. If it is a mobile computer make sure it has not been "suspended" or put into "sleep" mode. (Restart a suspended Windows computer to let Retrospect see it.) - BY INSPECTION IT IS NOT IN SLEEP MODE

  3. Make sure the client has the most recent version of the Retrospect client software and that the client software loads at startup. Open the Retrospect Client Control Panel. It should display a status of "Ready" or "Waiting for first access".-CHECK

  4. Test the connection between the backup computer and the client. Go to Configure > Clients (or Sources). Select the Client and click Properties, then click Refresh. Macintosh users can go to Sources, select the client and click Refresh. This will force a connection to the client. If it can connect with the client, Retrospect displays the measured transfer rate in kilobytes per second. Also try pinging the client from the command line. - I CAN ping THE CLIENT BUT IN THE CLIENT PROPERTIES WINDOW, I STILL GET A "NOT CONNECTED" MESSAGE EVEN AFTER I CLICK THE REFRESH BUTTON SEVERAL TIMES.

  5. Turn off any firewall software on the client and backup computer and attempt the connection test again in step 4. Your Firewall must be open to port 497 to allow UDP and TCP traffic. - SAME PROBLEM EVEN AFTER THE FIREWALL IS TURNED OFF.  NOTE THAT CLIENT "A" WORKS FINE, SO THE FIREWALL CAN'T BE THE CULPRIT.

Link to comment
Share on other sites

I forgot one thing that I learned from A. last June, when I first started running Retrospect again after 5 years.  At that point the only show-stopper problem I had was in getting the Retrospect "engine" to "see" my two client machines consistently on startup (I could get it to do so by manually doing a Recognize from the Sources item on the "console" and then running my desired script). 

 

You must give each of your clients a reserved fixed DHCP address that won't conflict with DHCP addresses that the Internet-connected router might assign.    Years ago this was not necessary, but now it is.  This is not documented anywhere in the User's Guide.  (A. also told me to open up port 497 on my Internet-connected router for both TCP and UDP—I don't run an internal firewall, but after fierce objections from other posters 7 months later on my Ars Technica Retrospect thread about my thus creating a supposed security hole I closed port 497 on my Internet-connected router—with no resultant problem.  This is documented properly in the User's Guide—as applicable to internal firewalls.)

 

How you do this depends on what brand and model of Internet-connected router you have.  On my Verizon-provided Actiontec GT784WNV "router"—which also includes the functionality of what used to be called a "modem", I type 192.168.1.1 as a URL into my browser, then enter the name (defaults to "admin") and password (I changed it; if you haven't, see the ISP's documentation or phone their Tech Support).  I then click the Advanced Setup tab, and go to DHCP Reservation under IP Addressing on the sidebar.  There I manually enter the MAC address (has nothing to do with Macintoshes—look it up on Wikipedia) for each client machine—which must include embedded colons on the Actiontec.  For that client machine I then enter an associated IP address (I chose 192.168.1.202 and 192.168.1.203 for my clients; 192.168.1.200 is the reserved DHCP address for my printer), and then click the Apply button.

Link to comment
Share on other sites

Just for test purposes, move "Client C" to the position of "Client A". Move "Client A" to the position of "Client C". Just move the computer (and power supply). Do not move any network cables or anything else.

 

Now, did the problem stay with the client computer or did it stay with the position of the computer?

Link to comment
Share on other sites

 

Is 'Client A' network connection wired or wireless? Is it laptop/notebook or desktop?
 
Is 'Client C' network connection wired or wireless? Is it laptop/notebook or desktop?

 

 

Replying to Lennart, it's not really practical to move the desktop.

 

Scillionian,

 

Client A is a wired desktop.

 

Client C is a laptop that I connect to my home LAN with an Ethernet cable.  It normally runs DHCP rather than having a fixed IP address. Really dumb question, based on David Hertzberg's post.  Is it even reasonable in an era when lots of office workers have laptops connected by DHCP-based WiFI to require fixed IP addresses.

 

So my workaround was to temporarily change the IP address to the IP shown under the Access tab for the Properties window for Client C.  When I was running Retrospect 7.7, I never noticed an IP address before.  Maybe that's consistent with David's observation.  However, that workaround did not work.

 

So I clicked the CHANGE button in the lower right corner of the Access tab.  The resulting window "Clients by Piton Name Service using multicast" did NOT show Client C, even though it showed Client A.

 

So I threw in the towel completely, and deleted Client C from the Client list.  That was pretty dumb, since when I tried to ADD a client, Retrospect could not find Client C.  (Why didn't I think of that before I deleted Client C? :blink: )

 

So I tried to locate Client C using Configure Subnet Broadcast.  I entered subnet 192.168.1.0 and mask 255.255.255.0.  Still no luck. Then I noticed on Client C when I opened Retrospect Client Control Panel that the Client name is correct, but the IP address is 192.168.144.128.  Whiskey-Tango-Foxtrot!  That turned out to be the IP address of an Ethernet Adapter associated with VMWare Workstation. so I disabled that adapter.

 

So then I deleted the Retrospect client software from Client C, and then reinstalled it. I use Revo Uninstaller Pro 3, which does a very good job of removing the usual files and registry keys that the normal uninstall routines leave behind.  After re-installing the client software, Client C's control panel displayed the correct IP address and Client C was suddenly visible to Retrospect again. 

 

(Note:  at this point, I reverted the IP address to DHCP.) 

 

So what is the lesson here, or the best practice?  For sure, disable any Ethernet adapters besides the one used to connect the client to my LAN hub.  Will this fix be persistent across DHCP IP address changes?  Dunno, but I'll post when I see results.

 

 

x509

Link to comment
Share on other sites

Then I noticed on Client C when I opened Retrospect Client Control Panel that the Client name is correct, but the IP address is 192.168.144.128.  Whiskey-Tango-Foxtrot!  That turned out to be the IP address of an Ethernet Adapter associated with VMWare Workstation. so I disabled that adapter.

 

I had exactly the same problem with a system with VMware virtual network adaptors that had an active connection to the host system.

 

 

So what is the lesson here, or the best practice.  For sure, disable any Ethernet adapters besides the one used to connect the client to my LAN hub.  Will this fix be persistent across DHCP IP address changes?  Dunno, but I'll post when I see results.

 

This looks to be a specific Windows/VMware/Retrospect combination problem. From my experience as long as the VMware virtual network adaptors remain disabled then Retrospect will follow the DHCP allocated IP address. If you can work with the VMware virtual network adaptors host connections disabled then this is the easiest solution.

Link to comment
Share on other sites

x509, it sounds as if you essentially did the same workaround that I linked to in my first post in this thread.  Presumably the uninstall tool you used accomplished the Windows equivalent of "Make sure the file 'root-drive-name/Library/Preferences/retroclient.state' (no single-quotes around file name, root-drive-name is usually 'Macintosh HD' with no quotes) is no longer there; if it is still there, delete it."

 

However I probably should have made it clear in my previous post in this thread that the idea is to override the DHCP address that the Internet-connected router might assign to your client C.    Years ago this was not necessary, but now it is (don't shoot me, I'm only a messenger for A. of Retrospect Inc.).  What I am suggesting you do is described in the manual allocation paragraph of this Overview section of the Wikipedia article on DHCP.  In other words, establish "a preconfigured mapping to each client's MAC address."

 

You need to obtain the client's MAC address.  Under Mac OS X's Apple menu, this can be done in either of two ways: (1) About This Mac -> System Report -> Hardware -> Ethernet Cards or (2) System Preferences -> Network -> Advanced (button) -> Hardware (tab).  In either case, what you are looking for is a string of 6 pairs of hexadecimal digits separated by colons.  It's been 12 years since I had a Windows 95 machine (loaned by my employer) at home, but I sure there are one or more Control Panels that will give you the MAC addresses for your Windows clients.

 

As I said in my previous post, how you will then go about mapping a reserved fixed DHCP address to each client MAC address depends on what brand and model of Internet-connected router you have.  But the Wikipedia paragraph I linked to in the second paragraph of this post essentially says that you can do this mapping on any brand of Internet-connected router; you only have to figure out the terminology used and navigate to the place to do the mapping once you have connected to your router.

 

I'd even be willing to bet that there is some way of determining the MAC address for a VMware virtual network adapter.  If so, it should be possible to map a fixed DHCP address to that MAC address, so that you can then enable that virtual network adapter's host connection.  I'll let the Windows/VMware experts figure out how to do that, but you might want to start with Chapter 16 of the Ver. 11 Retrospect Windows User's Guide—followed by searching the Knowledge Base to see if you can do it without paying for an add-on product.

 

In response to your question "Is it even reasonable in an era when lots of office workers have laptops connected by DHCP-based WiFI to require fixed IP addresses?", the answer is that you must once obtain the MAC address of each laptop that will be used by an office worker and map a new reserved fixed DHCP address to that laptop's MAC address.  As soon as you have done that, you can—in the presence of the laptop user—wave a dead chicken over the laptop to signify its being approved for connection to the office LAN.  If an office worker tries to connect an unapproved laptop to the LAN, you can instead hit him/her with the dead chicken.

Link to comment
Share on other sites

In this specific case the problem is the interaction of the Retrospect Client, Windows and VMware virtual network interfaces. The Retrospect Client always binds to the VMware virtual interface and ignores any communication to it on the physical interface where the Retrospect server is. From my experience the type of IP address assigned has no effect.

 

From my experience the Retrospect Client, on Windows at least, seems to have problems with binding to the correct network interface when a system has more than one active network interface.

Link to comment
Share on other sites

In this specific case the problem is the interaction of the Retrospect Client, Windows and VMware virtual network interfaces. The Retrospect Client always binds to the VMware virtual interface and ignores any communication to it on the physical interface where the Retrospect server is. From my experience the type of IP address assigned has no effect.

 

From my experience the Retrospect Client, on Windows at least, seems to have problems with binding to the correct network interface when a system has more than one active network interface.

 

I think we have exposed two design flaws here.  One is to not consider the presence of a virtual machine.  The second is to require the "dead chicken procedure" for positively identifying a laptop.  If I were the product manager, I would expect to find that administrators are not happy with this situation and so I would put requirements on engineering to address these issues. But I'm not the product manager, only a Retrospect Professional customer.

 

x509

Link to comment
Share on other sites

 

 

However I probably should have made it clear in my previous post in this thread that the idea is to override the DHCP address that the Internet-connected router might assign to your client C.    Years ago this was not necessary, but now it is (don't shoot me, I'm only a messenger for A. of Retrospect Inc.).  What I am suggesting you do is described in the manual allocation paragraph of this Overview section of the Wikipedia article on DHCP.  In other words, establish "a preconfigured mapping to each client's MAC address."

 

You need to obtain the client's MAC address.  Under Mac OS X's Apple menu, this can be done in either of two ways: (1) About This Mac -> System Report -> Hardware -> Ethernet Cards or (2) System Preferences -> Network -> Advanced (button) -> Hardware (tab).  In either case, what you are looking for is a string of 6 pairs of hexadecimal digits separated by colons.  It's been 12 years since I had a Windows 95 machine (loaned by my employer) at home, but I sure there are one or more Control Panels that will give you the MAC addresses for your Windows clients.

 

I'm not going to shoot you, even with a peashooter.  But it seems like making progress "backwards" to require a fixed IP in release 11 (of Windows) even though earlier releases worked just fine without it. 

 

C'mon guys (Retrospect engineers.) Fix this issue.

Link to comment
Share on other sites

 

However I probably should have made it clear in my previous post in this thread that the idea is to override the DHCP address that the Internet-connected router might assign to your client C.    Years ago this was not necessary, but now it is (don't shoot me, I'm only a messenger for A. of Retrospect Inc.).  What I am suggesting you do is described in the manual allocation paragraph of this Overview section of the Wikipedia article on DHCP.  In other words, establish "a preconfigured mapping to each client's MAC address."

 

Guys, I'm happy to report that Client C is still recognized by the Retrospect "server" even after an IP address change. When I re-installed the client, the address was xx.xx.xx.132.  After a round trip through Wi-Fi and DHCP, the address is now xx.xx.xx.133.  And the Piton service still located the client.  So it seems the issue was that previously the Retrospect software on Client C was bound to a VMWare Ethernet interface, not the physical Ethernet interface.

 

If this approach works for Mac OS X, I have no idea and no way to do a test.

 

x509

Link to comment
Share on other sites

 

C'mon guys (Retrospect engineers.) Fix this issue.

 

This is (mainly) a user-to-user forum. Which means that Retrospect staff rarely responds. I'm not even sure they read everything.

 

So your best way to get this fixed is to contact Retrospect Support. Link in the black "header" at the top of this page.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...