Jump to content
x509

Yet another -530 client not found error

Recommended Posts

10 days ago, Retrosect suddenly could no longer connect with client "LENOVO730."  No changes in the home LAN, which is a Windows workgroup, other than normal Windows background updates.

 

I just verified that the client on LENOVO730 is active.  I can ping the client by name in a Windows cmd-box.   In Retrospect, I did a TEST in the Network Access window and got this result:

image.png.d0d1e84a3113553bb210ccbc3601a4b4.png

So Retrospect Desktop has detected the client at its correct IP address.  But right after I got this result, I clicked on the Refresh button for Lenovo730 Client properties.

image.png.6eacba3d70d2c7c9400436f4e5c9e18f.png

I don't know if this is a Retrospect issue or a Windows issue.  I've been using Windows networking since the Windows for Workgroups 3.11 days, and I think that networking issues are responsible for the vast majority of issues on systems in my home LAN.  If you go to this forum, https://www.tenforums.com/network-sharing  there are endless threads about Windows networking issues with missing clients, missing network shares, etc., etc.  So I don't know where the issue lies. 

Are there any additional steps I can take to rule out a Retrospect issue?

Share this post


Link to post
Share on other sites

I solved my own problem.  😲 

 

In the Client Windows, I selected the Access tab and then clicked on the Direct button.  Then I entered the client's TCP/IP address.  It worked. Lesson learned.

Share this post


Link to post
Share on other sites

x509,

That is what finally worked for in Retrospect Mac 15 for my -530 problems that started on 30 January 2017, as detailed in this post and its thread predecessors—plus links to preceding threads.  Add Source Directly is the Retrospect Mac equivalent of the Direct Access Method, which is described on pages 296-297 of the Retrospect Windows 16 User's Guide.

I had to both look up my old Forums post and find the Retrospect Windows UG equivalent of Add Source Directly, while working only during only the TV commercials interrupting the film "Dancing With Wolves".  Sorry for the delay.

Share this post


Link to post
Share on other sites

There are so many, many frustrations in using Retrospect.  Why do I (or anyone else) stick with it?  This client not found issue seems like a self-inflicted wound.

Share this post


Link to post
Share on other sites
On 10/5/2019 at 10:40 PM, x509 said:

There are so many, many frustrations in using Retrospect.  Why do I (or anyone else) stick with it?  This client not found issue seems like a self-inflicted wound.

x509,

I understand your frustration, but IMHO calling the -530 error a "self-inflicted wound" is a bit unfair to the Retrospect engineers.  The Multicast access method used to work beautifully, at least for me using Retrospect Mac from 1995 to early 2017.  However if you read the first expert-quoting section in this post earlier in the same Forums thread I linked to in my preceding post, you'll see that Retrospect's version of Multicast seems to have recently stopped working reliably because of "improvements" in networking hardware (my situation) and/or software (your reported situation).  IMHO the Retrospect engineers should at most be faulted for not having done a really thorough investigation of my -530 problems as reported in Support Case #61302 (in which my March 29, 2019 00:38  Additional Note is a copy of the same post section I linked to in the third sentence of this paragraph), and then not having faced up to the need to revise Retrospect's method of Multicasting (e.g. to use mDNS as the Ars Technica expert suggested).

Of course in 2018-2019 the Retrospect engineers had many enhancements on their agenda, which Product Management undoubtedly considered to be more urgent than an extensive effort to fix -530 bugs that only some administrators were experiencing.  Still, considering that AFAICT most Retrospect engineers are in their 50s, IMHO they would benefit from being forced to take a Software Engineering course in modern debugging methods—which they probably never had in college or grad school (I was a professional applications programmer from 1964 through 1988 after flunking out as a Political Science major, and then went back to get a quickie Bachelor's in CS followed by a night-school MSCS in early 1996—and I never had such a course).

IMHO getting Multicast working reliably again will be an absolute must for the planned version (StorCentric management has announced this ) of the Retrospect "backup server" running on Drobo NAS appliances.  Given that reviewers agree the main market for Drobo is for home users and SMEs, how can Drobo expect those customers' backup administrators—having backgrounds as described in the last sentence  of that Wikipedia article's lead—to be expert enough in networking to assign fixed IP addresses to "clients" on their particular brand of routers and then enter those addresses via the Retrospect Drobo equivalent of the Direct Access Method?:rolleyes:  No, IMHO they'll need reliable Multicast.😎  I'd therefore suggest that you invoke superior force by communicating that requirement (as I already have in a snail-mail letter, but you can find an e-mail address on LinkedIn) to:

Drobo

    Attn.: Mr. Rod Harrison, CTO

1289 Anvilwood Ave.

Sunnyvale, CA 94089

USA

Be sure to mention my name, which I used in the snail-mail letter (put a space between my "handle"'s second 'd' and the 'H'), and Support Case #61302.

P.S.: A Forums search using "-530" (including the double-quotes) in the Sarch bubble shows some administrators have been getting this error since 2002.  A number of these have turned out to be networking problems, and a number because bugs had not yet been fixed for Retrospect Windows.

Share this post


Link to post
Share on other sites

I experience this too, on a regular basis.  Yes, it used to work and stopped being reliable a couple of years ago.  Tried using a static IP address but that's inconvenient for a laptop that frequently travels to other locations and networks.  Nothing else works.  When it breaks I use ipconfig on the laptop and reset it to that address on the client setup in Retrospect.  It's annoying, but nothing else seems to work.

Share this post


Link to post
Share on other sites

mbennett,

Have you tried using the Subnet Broadcast access method?  It is initially described under "Subnet Broadcast" on page 294 of the Retrospect Windows 16 User's Guide; how to use it is described under "Subnet Broadcast Access Method" on pages 295-296.

Subnet Broadcast  was suggested by henry-in-florida in this December 2018 post.  IIRC I used it for my MacBook Pro "client" for about a month, then eventually (when a trial of Multicast didn't work) switched to Add Source Directly—the Retrospect Mac equivalent of Direct Access Method—after having upgraded to Retrospect Mac 15 (because of a Retrospect-Mac-only bug in preceding versions that activated at the start of 2019).  My MBP never travels off my LAN, so Add Source Directly using a fixed IP address works for me.

 

Share this post


Link to post
Share on other sites
On 10/7/2019 at 10:27 AM, mbennett said:

I experience this too, on a regular basis.  Yes, it used to work and stopped being reliable a couple of years ago.  Tried using a static IP address but that's inconvenient for a laptop that frequently travels to other locations and networks.  Nothing else works.  When it breaks I use ipconfig on the laptop and reset it to that address on the client setup in Retrospect.  It's annoying, but nothing else seems to work.

mbennett,

Alternatively, have you considered setting up a "BackupLand" or "HomeSweetHome" Location in the Windows equivalent of your laptop's System Preferences->Network?  You could copy your addresses from your Automatic location, and put your laptop's fixed IP address (not "static"; that term now refers to an Web-wide IP address permanently assigned to you by your ISP) specified on your home/office LAN's router into that Location.  You could then use the Windows equivalent of the Mac System Preferences->Network dropdown to switch to that Location whenever you bring your laptop back to your home/office where you back it up.That way you could continue to use the Direct Access Method for your laptop "client" in Retrospect.

I have no personal experience with this, especially since I'm a Mac administrator, but from reading the Mac System Preferences Help I think this would be better than defaulting to the Automatic location—unless Subnet Broadcast instead of Direct works for you.  This Web page looks as if it might offer a clue to Windows 10 Settings for networking. I would welcome comments from Retrospect Windows administrators.

Share this post


Link to post
Share on other sites

mbennett,

As an alternative to my alternative, when using "static IP address", try implementing

retroclient.exe /ipsave xxx.xxx.xxx.xxx

per what's under "Windows usage" in this Knowledge Base article.  This 2014 enhancement was never put into the User's Guides; it should have been.

Share this post


Link to post
Share on other sites

Interesting. I just finished discovering a specific set of bugs in Retrospect, and challenges in our router(s) and local network apps, that directly lead to the above anomalies in finding and/or connecting to clients. (Yes, all of the following has been submitted as a bug report.)

I'm running a more Windows-centric network, with a little OSx tossed in, so my tools are a bit different.

Tools:

  • WireShark: shows packets actually traveling. Most useful is a filter of udp.port==497 || tcp.port==497
  • tcpdump (command line in linux and/or osx) - monitoring port 497
  • TCPview (from SysInternals, now owned by Microsoft) - sort on port. Look at what is listening to 497 and on what IP address(es)
  • (command line) ipconfig and also "route print"
  • In Retrospect: go into Clients -> choose a client-> access tab -> Interface -> Configure Interfaces ... and see what default interface IP address is.

Things to watch for:

  • Are UDP broadcast packets being received by clients? (eg 192.168.x.255, port 497)
  • For multicast, are packets getting to clients? (eg 224.0.0.0/4 -- Retrospect uses 224.1.0.38 UDP port 497)
  • Are clients responding to those packets (UDP broadcast or multicast) (initially to UDP port 497 on the backup system)
  • If crossing subnets, is TTL set high enough to reach the client?

What could possibly go wrong? Heh. :)

Here are anomalies I've seen:

  • Often, some app will create virtual interfaces. This includes npcap (for Wireshark etc), VMware, TAP-Windows (comes with Windows?), etc... This has led to:
    • On some of my clients, some virtual interfaces have APIPA addresses (169.254.*) -- which makes it obvious when retrospect chooses the wrong interface to listen on! (Workaround: I uninstalled the TAP-Windows adapter as I don't need it. And I temporarily disabled npcap on the one workstation where that got in the way.)
    • On my retrospect backup desktop, retrospect chose one of the VMware virtual adapters as the default adapter! This even though the real gig adapter has higher priority etc etc. (Workaround: create another adapter in Retrospect)
    • The result in either case: I can't see the clients, even though ping works.
  • I have a network security system. It regularly scans all ports on all subnets. Some (but not all) clients get confused by this, with the retroclient app hung up on an IP connection in CLOSE_WAIT status. The result: the client is never available for backups. Yet it is visible to subnet or multicast.
  • We switched to a pfSense firewall/router. I just discovered that multicast forwarding is badly broken.(Workaround: manually installed pimd.)
  • Similarly, UDP broadcast is often blocked by firewalls. Make sure the packets are getting through!

Having fixed and/or worked around ALL of the above, and rebooted everything... I can now reliably use either multicast or subnet broadcast to connect with clients.

Share this post


Link to post
Share on other sites

Magnificent investigation, MrPete! :) 

All machines on my LAN are Macs, and to my knowledge I don't have a network security system—not to mention VMware (for which the -530 problem was discussed starting in a 2017 thread).  I don't have a firewall on my LAN's FiOS "gateway", and the firewall is disabled on my MacBook Pro. 

As a result of your investigation I'm now wondering if my "gateway", which is a Verizon G1100 which also functions as my router, uses pfSense (or its fork OPNsense) code.  Almost a year ago I ran a test which temporarily connected my MBP "client" to my Mac Pro "backup server" so that it was "upstream" from my "gateway".  However I didn't think of disconnecting the "gateway" until I had disassembled the test setup, and the connection probably wouldn't have worked without it.  However my original -530 problems, which started on 30 January 2017 when I still had DSL instead of FiOS, occurred only when I booted the "backup server" after the scheduled time for the backup script and the script ran immediately—so I thought the bug was caused by uncoordinated startup in the Retrospect Engine.

Share this post


Link to post
Share on other sites
On 10/7/2019 at 10:27 AM, mbennett said:

I experience this too, on a regular basis.  Yes, it used to work and stopped being reliable a couple of years ago.  Tried using a static IP address but that's inconvenient for a laptop that frequently travels to other locations and networks.  Nothing else works.  When it breaks I use ipconfig on the laptop and reset it to that address on the client setup in Retrospect.  It's annoying, but nothing else seems to work.

mbennett,

When you wrote "Tried using a static IP address  ...", did that mean an IP address designated on your router via a "DHCP reservation" based on your laptop's MAC address?  Inquiring minds (with limited reading ability :rolleyes:) on the Ars Technica Networking forum want to know.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×