Yet another -530 client not found error

[x509]

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:

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.

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?

[x509]

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.

[DavidHertzberg]

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.

[x509]

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.

[DavidHertzberg]

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?  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.

Edited May 18, 2020 by DavidHertzberg
P.S.: Some administrators have been getting -530 errors since 2002

[mbennett]

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.

[DavidHertzberg]

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.

 

[DavidHertzberg]

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.

P.S.: Upon later investigation, it appears there is no Windows equivalent of the Mac's System Preferences->Network->Location. 😦

Edited May 26, 2020 by DavidHertzberg
P.S.: It appears there is no Windows equivalent of the Mac's System Preferences->Network->Location

[DavidHertzberg]

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.

[MrPete]

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.

[DavidHertzberg]

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.

[DavidHertzberg]

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 ) on the Ars Technica Networking forum want to know.

[x509]

Very useful informatiion here.  I've created a PDF of this thread, so I can review everyhing here, highlight some points, etc.

I have no idea how I could use Retrospect successfully without this forum.  I guess as a home user, I am part of the target demographic for a Drobo unit.  Maybe if they offer a nice unit at 75% off in combination with the Retrospect 17 upgrade ....

Right now, the system running Retrospect is housed a full-tower case (home built based on ASUS motherboard), with lots of drive bays.

x509,

[x509]

I just ran into the "client not found" error message on one client because Windows rebooted the system as part of a software update and the IP address, being DHCP-based, changed. 😩  So I was able to reconnect using IP Direct Connect, but that's not exactly a "scalable solution."  I've been using Retrospect for at least 10 years now, and I don't remember having this problem years ago.  I need Retrospect to automatically detect clients on my home LAN, even if the IP address has changed.  The subnet address is always the same:  192.168.1.xx.

So before posting, this time I did a search on "Piton client" and found six pages of links, and I opened up a lot of them.  Lots of unfamiliar names in posts from 2005 or so.  I even found some of my own old posts. 

One suggestion was to make sure that port 497 is open on the firewall.  I use Norton Internet Security, not Windows Defender, so I added an Allow rule for port 497 on both server and a test client.  No joy.  So I fell back to direct connect to connect to the problem, which did work, but I'm not happy about it because that's just muddling along, and not addressing the root cause.

I'm running Retrospect 16.6.0.133, with latest version client.  The last post in this thread seems to hold out a glimmer of hope that Retrospect 17 can detect a client with a changed IP address.  Is that true?  If it is, then I will upgrade to V17 as fast as I can pull out my credit card. 

I know that another option is to make DHCP assign fixed addresses to the client machines, and I'll probably do that when I have some time.  Maybe it's time for me to create a IP address plan for all the devices on my network, computers, phones, tablets, TVs, Roku stick, etc.  (Believe or not, the Covid lockdown seems to keep me busier than ever.  Who knew?)  But I still think the problem should be fixed at the source.

Question:  Does Piton depend on SMB V1?  That protocol is supposed to be disabled due to serious security vulnerabilities.

Second question:  Does Apple Bonjour interfere with Piton?

Third question:  Does your head hurt now?

[DavidHertzberg]

x509,

You don't need to create a fixed IP address plan for all the devices on your network, just the computers you back up with Retrospect.  Just pick a number evenly divisible by 100—higher than the number of devices you have on your network, and assign fixed IP addresses to your computers equal to or higher than that number.  For instance, back in 2015 when I had to connect my ancient HP LaserJet 5MP printer—which connects to my LAN via an HP JetDirect EX Plus (too old for Bonjour, my 2015 problem when I upgraded to OS X 10.10) because the 5MP doesn't have Ethernet, I just plugged the EX Plus's MAC address with 192.168.1.200 into my router.  It still works fine, and I did the same for my client computers in February 2017 starting with 192.168.1.201.

The only thing I changed on 30 January 2017 was replacing a dead 100Mbps switch with a 1Gbps switch.  It appears that newer networking hardware blocks ports 497 and 22024.  These must be open on your LAN for both TCP and UDP for the Piton protocol to work.  Retrospect "Inc." hasn't yet revised that protocol—which doesn't depend on SMB V1—to cope with the situation; I've been told there's a different approach to multicast that they should be using.  It's also possible that your Windows software update turned on a firewall on your "client",  as part of the update, that blocks those ports.  Ah security, what crimes are committed in thy name! ☹️

 

[x509]

David,

Agree with your point about needing an IP address plan for just the devices to back up, but if I had fixed addresses for my other devices that would help me to debug "strange" network problems.  Big issue for me is the very complex password I use.  It's a pain in the tuchus to type that in on an iPhone, or worse yet a Roku device.  But in my heart I know I should do it.

thanks for letting me know that SMB V1 is not an issue here.  In general, home networking is a real weak spot within Windows.  Windows forums are just filled with people complaining that system A can see system B and C, but C can't see A or B, and B can see only C.

[Nigel Smith]

16 hours ago, x509 said:

Question:  Does Piton depend on SMB V1?  That protocol is supposed to be disabled due to serious security vulnerabilities.

Second question:  Does Apple Bonjour interfere with Piton?

Third question:  Does your head hurt now?

No, no, and no 😉

Long time since I've seen Norton firewall, but make sure that you are opening port 497 on both TCP and UDP protocols (direct connection only need TCP, discovery uses UDP). Windows also has a habit of changing your network status after updates, deciding your "Home/Private" network is "Public" instead, if Norton makes use of those distinctions (Windows Firewall does).

Easiest way to check for discovery is Configure->Devices->Add... and click Multicast -- is the device listed? Also try Subnet Broadcast. 

I have no particular problems with DHCPed PCs at work, so it's something about your setup. As David says, you could get round it by assigning static IPs -- check your router documentation first, some "home" routers supplied by ISPs have severely limited ranges that can be reserved for static mapping -- which can also make life easier for other things, eg just use "\\192.168.1.x" to access a share instead of hoping Windows network browsing is having a good day...

Question: Are client and server both on the wired network, or is one (or both) wireless?

[x509]

Please see properly formatted reply below.

[x509]

Please see next message.  This forum doesn't have the same reply formatting flexibilty as others.

[x509]

5 hours ago, Nigel Smith said:

No, no, and no 😉

Long time since I've seen Norton firewall, but make sure that you are opening port 497 on both TCP and UDP protocols (direct connection only need TCP, discovery uses UDP). Windows also has a habit of changing your network status after updates, deciding your "Home/Private" network is "Public" instead, if Norton makes use of those distinctions (Windows Firewall does).

Easiest way to check for discovery is Configure->Devices->Add... and click Multicast -- is the device listed? Also try Subnet Broadcast. 

I have no particular problems with DHCPed PCs at work, so it's something about your setup. As David says, you could get round it by assigning static IPs -- check your router documentation first, some "home" routers supplied by ISPs have severely limited ranges that can be reserved for static mapping -- which can also make life easier for other things, eg just use "\\192.168.1.x" to access a share instead of hoping Windows network browsing is having a good day...

Question: Are client and server both on the wired network, or is one (or both) wireless?

In the Norton firewall, I added a rule for Port 497, for both TCP and UDP.  Didn't fix the problem.

Neither Configure -> Devices method discovered the clients.

To respond to your point above, the Norton firewall has a concept of "trusted" networks devices.  But as you say, Windows is notorious for changing network status in multiple ways.  Sometimes after updates, sometimes for no apparent reason.  Networking is to me, the biggest single source of grief and unwanted maintenance work in Windows.  Perhaps PC networking works much better in a domain with an Active Directory server, but home networking is a hot mess.  It's much easier to throw in the towel and use Direct IP Addresses for clients. 

 

 

[MrPete]

Hi all,

I don't have time to go into detail on this... but in sum:
* I found several MORE related issues.
* Turns out, some of the problems cannot be repaired by use of a fixed IP on the server side
* WORKAROUND: Restart the Retrospect Client service
             At admin cmd prompt, you can do two commands: net stop "retrospect client" followed by net start "retrospect client"
* (Alt workaround for static clients: https://www.retrospect.com/en/support/kb/client_ip_binding )
* Retrospect engineers are grinding through it all. Based on my background, I am guessing they are needing to re-architect some pretty deep stuff.

It's bug #8512. Last I heard it is being worked on and hopefully in a "soon" update of retrospect 17

In brief:

* Particularly for clients (laptops etc) that can shift between wifi and wired etc...
* The **client** can easily latch onto a wrong or invalid (169.254.*) IP address. That's NOT what the UI says (necessarily)
* Once listening there (particularly on UDP for multicast), it will NEVER update until the client service restarts. TCP client also has similar failure modes.
* There's more but that's the essential bit
* (To see for yourself, have fun with SysInternals TCPview, sort by port, watch port 497. Retrospect already has all they need to fix it.)

[Nigel Smith]

On 5/15/2020 at 9:01 PM, MrPete said:

* (Alt workaround for static clients: https://www.retrospect.com/en/support/kb/client_ip_binding ).

Not just statics -- you can also use it for DHCP clients. And it wouldn't take much work to write a script that would find the current active IP and do a temporary rebind. On a Mac you can even tie it in to launchd using either NetworkState, or with WatchPaths on /private/var/run/resolv.conf (although, in my experience, Mac clients do get there eventually and rebinding is only necessary if you are in a hurry to do something after a network change).

[MrPete]

On 5/18/2020 at 2:36 AM, Nigel Smith said:

Not just statics -- you can also use it for DHCP clients. And it wouldn't take much work to write a script that would find the current active IP and do a temporary rebind. On a Mac you can even tie it in to launchd using either NetworkState, or with WatchPaths on /private/var/run/resolv.conf (although, in my experience, Mac clients do get there eventually and rebinding is only necessary if you are in a hurry to do something after a network change).

That's pretty complex compared to restarting the client ... but sure it could be scripted.

[Nigel Smith]

16 hours ago, MrPete said:

That's pretty complex compared to restarting the client ... but sure it could be scripted.

Of course -- would I offer anything simple? 😉

More seriously, if the client is "confused" by network interfaces when it starts up, can we guarantee it won't also be "confused" on a restart? While it should be better, since it is restarting when there is (presumably) an active interface, it might be safer to explicitly tell the client what to do rather than hoping it gets it right.

And a batch script triggered by double-click is a lot easier for my users than sending them to the command prompt.

As always, horses for courses -- what's best for me isn't best for a lot of people here, but might nudge someone to their own best solution.

[x509]

Since I personally don't have scripting skills beyond Windows CMD files, and not very good even at that a fixed IP for all clients (as David suggests) is probably the best approach for me.

Right now, I'm busy with covid projects from my wife for fixing up things around the house, but I will get into my router's IP assignments table soon enough.

To reprise an earlier comment, networking is the weakest part of Windows 10, since there is no one screen or set of screens to control all the entire TCP/IP stack or all the processes that can affect networking.  Add to that the ways that a Windows update can silently reset some settings, and I spend way too much time on this issue.  Retrospect client discovery is only one relatively small aspect of the overall issue.

In my humble home LAN, all Retrospect clients and the server are wireless.  One less issue.