Jump to content
x509

Yet another -530 client not found error

Recommended Posts

x509,

I did a little Googling, and—just below the heading "How to assign static IP address using Settings" [my emphasis] on this Pureinfotech article on "How to set a static IP address on Windows 10"—is a section "Assigning static IP address for Wi-Fi adapter".  So you wouldn't have to do scripting or get into your router's assignments table, but—from what you  and mbennett have said up-thread—a Windows update might silently reset any such settings.

Everyone,

I went searching for this because I couldn't believe that modern Windows doesn't have the equivalent of the System Preferences->Network->Location dialog in macOS, for x509 to use with his Wi-Fi.  This facility was developed in OS X to provide for Mac laptops that might be moved to different locations (hence the name) having different LANs, and is available as far back as my ex-wife's ancient Digital Audio G4 booting 2003's "Panther" OS X 10.3.

Although my MacBook Pro never leaves my study desk, I discovered Location after I bought a CalDigit Thunderbolt Station 3 Plus dock to connect it via a KVM switch to a an external monitor.  When my Apple 27-inch LED Cinema Display loses the video signal, it goes into a "deep sleep" mode—and needs to be "goosed" to wake up.  If my KVM switch is still set to take input from the CalDigit dock, it has lost the DisplayPort video because I shut down the MacBook Pro the input was indirectly coming from—so rebooting the MBP results in the dock "goosing" the monitor.  If  OTOH my KVM switch was formerly set to take input from the G4 via converted DVI, it has lost the DisplayPort video because I switched it to an awake MBP—and only rebooting the dock results in the dock "goosing" the monitor. In that second case I originally found that detaching and re-attaching either end of the Thunderbolt 3 cable between the MBP and the dock was sufficient to reboot the dock—as was unplugging and re-inserting the dock's power cord, but a woman at Apple Tech Support suggested that a method which wouldn't violate any mechanical port-insertion limits would be to plug the dock into a surge protector whose sturdy switch I could use to reboot the dock—so I'm doing it.

This created a problem with using Retrospect to simultaneously Recycle backup my MBP—using version 16 and an Ethernet connection wired via MoCA (inter-room Wi-Fi is slow in my apartment) to a "backup server" in another room—and my G4—using version 6.1 and a DAT tape drive SCSI-cabled directly to the G4.  Using the KVM switch to switch the Cinema Display from the MBP to the G4 works fine, because the G4 automatically "gooses" the monitor out of "deep sleep".  However using the KVM switch to switch the Cinema Display from the G4 to the MBP was killing the MBP's backup, because power-cycling the CalDigit dock was interrupting its Ethernet connection.  My solution was to create a Location named "Retrospect Priority" in addition to the "Automatic" one.  In "Retrospect Priority" the MBP's Ethernet connection is via a Moshi USB-C-to-Ethernet adapter (used with iffy StarTech USB32DPPRO before CalDigit), and the Ethernet connection through the dock is disabled—so power-cycling the CalDigit won't interrupt the MBP's Ethernet connection.

I took the trouble to explain this because, now that external docks are becoming popular, other administrators with DisplayPort or Thunderbolt 3 monitors in their installations may have similar problems.  The "deep sleep" feature is common to many such monitors—not just Apple's, and represents monitor manufacturers taking advantage of a DisplayPort (and Thunderbolt 3, which merges DisplayPort + PCIe + DC power) characteristic to lengthen monitor life—ignoring DP cable swappers and KVM switchers.  HDMI monitors also have a  "deep sleep" feature, but it can be disabled in some models.

Share this post


Link to post
Share on other sites
17 hours ago, DavidHertzberg said:

So you wouldn't have to do scripting or get into your router's assignments table

Would just warn that different routers' DHCP servers behave in different ways. Some treat the address blocks reserved for statics as inviolate, some will continue to offer those addresses when no MAC address has been set, etc. I always belt-and-brace, putting MAC addresses in the router's table and setting static IPs on the clients, when I need a definitely-fixed IP.

Also, some routers force a certain (often limited) range for statics and others let you do as you will, so check your docs before planning.

  • Like 1

Share this post


Link to post
Share on other sites

I am in fact doing what Nigel Smith calls "belt-and-brace" ("braces" are British English for what the rest of us call "suspenders") ; I have entries both in my router's MAC table and my MacBook Pro's System Preferences->Network->Locations for both my Moshi USB-C-to-Ethernet adapter port (X.Y.Z.201) and my CalDigit TS3 Plus Ethernet port (X.Y.Z.202)—X and Y and Z are "seekrit" numbers you couldn't 🤣 possibly guess..  My "Automatic" Location has the CalDigit port enabled, and my "Retrospect Priority" Location has the Moshi port enabled.  On my Retrospect Mac 16.6 "backup server", the Source for the MBP is defined with Add Source Directly as X.Y.Z.201—and my MBP usually uses the "Retrospect Priority" Location although the "Automatic" Location would give me slightly-faster Ethernet via Thunderbolt 3.

Yesterday afternoon I did a couple of tests, using my handy-dandy NoOpSun-FriBackup script with the No Files Rule (Selector in Retrospect Windows).  I first switched my MBP to the "Automatic" location and ran the script, which immediately issued a -519 error for the MBP.  (That error number is an argument for my side in the 6-months-back dispute with Nigel Smith over whether the "backup server" uses the multicast Piton Protocol in finding a Source defined with a correct MAC address using Add Source Directly.  My "backup server" would have found the MBP by name if it had used the Piton Protocol, or it would have issued a -530 error.)

I then switched my MBP's Location to "Retrospect Priority" and reran the script.  It started to run fine, until I too-rapidly shut down the MBP while the script was still making its 4-minute run—eliciting a "backup server" -519 error.  (Point for Nigel Smith in the 6-months-back dispute; "the client was found, then disappeared".)

Getting back to Nigel Smith's final warning, x509 should certainly find out what range for fixed IPs his router allows.  I believe I checked the manual for my ancient Verizon Quantum G1100 "gateway", but I simply set up fixed IP addresses starting with X.Y.Z.200.

Share this post


Link to post
Share on other sites
1 hour ago, DavidHertzberg said:

(That error number is an argument for my side in the 6-months-back dispute with Nigel Smith over whether the "backup server" uses the multicast Piton Protocol in finding a Source defined with a correct MAC address using Add Source Direct.  My "backup server" would have found the MBP by name if it had used the Piton Protocol, or it would have issued a -530 error.)

You're viewing the Piton protocol too narrowly. It's the protocol(s) by which server and client communicate and includes discovery, access and data transfer (amongst other things) and is used in the unicast (defined IP client, as above), broadcast and multicast "location" (using that since "discovery" usually means "first time ever finding a client" in RS) of a client on the network and all subsequent communication.

You'll have to do a lot more digging with eg WireShark to know exactly why you saw what you saw -- I'd expect it to throw a -530 (because the client was still listening on x.x.x.202:497) or just work, not throw a -519 -- but I suspect that permanently binding the client to x.x.x.201 with "ipsave" might eliminate the issue.

-530 is quite clear -- the client couldn't be found. That -519 is separate implies that the client could be found but then there was a problem, but I'm probably reading to much into it. All we really know is that "network communication failed", for whatever reason.

Share this post


Link to post
Share on other sites

Nigel Smith,

You are correct about my having defined the Piton protocol too narrowly; Instead of writing "multicast Piton Protocol", I should have used the term Piton Name Service—per page 227 of the Retrospect Windows 17 User's GuideAt last the -530 versus -519 difference is clarified.  On page 221 the UG says:

Quote

By default, Retrospect uses its Piton multicast method of searching for clients in the local subnet.

Page 228 says:

Quote

Multicast Piton Name Service uses the assigned address 224.1.0.38, which allows Piton to direct its queries only to those computers running Retrospect Client software.

Page 33 of the Appendices says:

Quote

Piton –Retrospect’s own proprietary protocol for communicating with backup clients. In the live network window, Retrospect uses the Piton name service to establish contact with clients.

In fact, a closer examination of the log for my first test run illustrates the difference between the overall Piton protocol and Piton Name Service in a rather interesting way (it turns out I didn't need WireShark. 😁).  The run actually "Finished scanning backup set data files to ... ", then issued the message "Can't access backup client ..., error -519 (network communications failed)".  It seems my "backup server" managed to find my MacBook Pro "client" by name, when it couldn't do so by Direct Access because the IP address the "client" was using didn't match the one defined in Sources.  Then, after successfully finishing scanning, the "backup server" said "Wait a minute, that's not the Source I'm supposed to back up" and issued the -519 error—not a -530 error.

By contrast, the log for my second test run—where the IP address the "client" was using did match the one defined in Sources—says "Can't read state info, error -519 (network communications failed)" when I too-rapidly shut down the MBP after the "backup server" had successfully finished the backup stage.

Thus it's the Piton Name Service that needs to be fixed.  As I've predicted elsewhere, StorCentric will have to force this to be done for the forthcoming Drobo variant of the "backup server"—so hordes of new Retrospect users won't have to learn how to set up Direct access to avoid -530 errors.

Share this post


Link to post
Share on other sites

Not so fast...

3 hours ago, DavidHertzberg said:

Then, after successfully finishing scanning, the "backup server" said "Wait a minute, that's not the Source I'm supposed to back up"

This is what I think might be happening (and why a WireShark run would help):

  1. Client is on "Automatic" location -- x.x.x.202
  2. You switch to "Retrospect Priority", client address now x.x.x.201, and immediately run the server script
  3. Server multicasts to all devices, asking for client
  4. Client responds, but we know the client doesn't instantly reflect a network change, so says "Yay! Me! Here and ready on x.x.x.202!"
  5. Scan gets done
  6. By now, the client is listening is on x.x.x.201:497 (or, rather, is no longer listening on x.x.x.202:497)
  7. Server initiates the backup "Hey, x.x.x.202, give me all these things!"
  8. Silence...
  9. More silence...
  10. Server assumes network communication has failed and throws -519

Step 4 is total guesswork from me -- all we know is that there must be some mechanism for a multicasted client to tell the server its IP address. If I'm right, they might be able to fix this on the client, though it may dependent on the OS promptly informing all network-using services of an IP change (the client unnecessarily spamming the OS for updates would be horribly inefficient). Or they might be able to fix this on the server, with a re-multicast after step 8's failure to pick up the new address.

But, even in these days of devices often changing networks, I doubt the above crops up very often and probably isn't worth fixing (directly, at least). x509's "binding to a bogus address" is much more common, and if solving that solves other issues too -- bonus!

Share this post


Link to post
Share on other sites

Nigel Smith,

Your 10-step guess as to what might have been happening may be correct, although you got confused about the Location of my first test—it was "Automatic" (X.Y.Z.202) instead of "Retrospect Priority" (X.Y.Z.201).  I reran that test yesterday, but—after changing the Location of my MacBook Pro "client" machine—scheduled the backup run 15 minutes in the future and then shut down and re-booted my "backup server".  This time the No Files backup ran with no error. 😲

That raised the question of how the Retrospect Engine had been able to find the MBP Source, which I am sure I had defined with Add Source Directly as X.Y.Z.201.  The answer seems to be the "magic" of Piton Name Service.  When I did a Locate of that Source after the test, it found the MBP via Multicast as X.Y.Z.202.  (I intentionally did not do a Locate after re-booting the "backup server" but before the test run was scheduled, because I found 3 years ago that a pre-Backup Locate would eliminate a -530 error that otherwise would occur.)

So am I going to investigate this further in my installation, other than possibly making the effort (because of necessary script changes) to Remove and re-Add my MBP as a Source with Use Multicast?  No I am not, because of an experience I had with Tech Support over two years ago.  As the third paragraph of that post says, T. S. twice gave me test versions of Retrospect with extra logging.  I uploaded the results to my Support Case, and got back a reply that said basically "Yes we see a problem, but we can't do anything about it unless we can reproduce it on our own machines—because it seems to be at least partially related to network hardware."  I thereupon offered to snail-mail T. S. my two MoCA adapters (for which I had by then bought higher-speed replacements) and a 40-foot length of previously-bought-for-testing Radio Shack coax cable to run between them, but got back a reply that said basically "Thanks for the offer, but we cannot take responsibility for customer-owned hardware."  I then suggested they find someone in the Retrospect Inc. organization who had gone far enough in law school to be able to write a deed of gift to Retrospect Inc. that I could sign, but they didn't reply. ☹️

So, as the last paragraph in this up-thread post states, we'll just have to wait until StorCentric discovers the -530 problem for the forthcoming Drobo variant of the "backup server"—and provides Retrospect "Inc." engineers the necessary resources to find and fix the problem. 😢

 

Share this post


Link to post
Share on other sites
3 hours ago, DavidHertzberg said:

So am I going to investigate this further in my installation... No I am not

Smart move, IMO!

These are deep waters, best left unrippled. Especially when you remember that network communication is not directly via IP address, but is next-hop routing via the mapping of IP addresses to gateway/MAC address in ARP tables. Table updates aren't instant, which is why I can quite easily see why my guess might happen -- step 5 is based on the MAC address of the previously  detected client, obviously still "valid" since the interface used wasn't changed (just the IP address). But when we get to step 7 it's aged out/replaced, the IP address is no longer valid, and you get a comms fail.

Share this post


Link to post
Share on other sites

Hi all! Sorry for the long delay. The Real World is intense for me right now :)

The following simple sequence has been a 100% reliable workaround for me:

1) AFTER an endpoint is stably connected to a LAN via any mechanism (wired, wifi, etc)...

2) Restart the Retrospect Client service (stop / start as described earlier)

The client NEVER gets confused under such conditions, at least in my way-too-extensive testing.

Confusion arises when the client initializes at the same time as the computer is initializing various things, including a variety of network-connected startup services etc. And/or if the network connection changes (eg wired to wifi, or to a different wifi.)

Share this post


Link to post
Share on other sites

This thread, plus some of the weird things Windows updates does to network settings, probably explains why there is such grief around Windows networking.  Way back in the 1980s, I was a product manager for networking protocols and stacks.  That was before TCP/IP took over the world.  Aside from LAN protocols, I dealt with SNA and DECNet, also oddballs like Banyan Vines.  Thinking back on those days, I can't imagine what i was thinking.  When TCP/IP became the One Protocol To Rule Them All, and Microsoft aligned its LAN networking around TCP/IP, life was supposed to get better.  I must have been smoking some strong stuff back then.

I like the belt and braces approach above.

Share this post


Link to post
Share on other sites

The problem with belt-and-braces: for some of us, the same computer can show up with different IP addresses in the same overall network (ie connecting to different subnets.) This requires a dynamic solution for both server and client.

AFAIK, at the server end, all methods work just fine.

The only serious problem with dynamic IP's is on the client end, as has been discussed.

Share this post


Link to post
Share on other sites
On 5/30/2020 at 11:12 PM, MrPete said:

The problem with belt-and-braces: for some of us, the same computer can show up with different IP addresses in the same overall network (ie connecting to different subnets.)

Totally agree, with both this and your previous post. We never static just for Retrospect, simply restart the client when needed (though the occasional missed backup can be annoying, it isn't the end of the world, and "moving" clients often miss backups anyway). But on a relatively "fixed" home or small business network, where IPs are only usually DHCPed because it's the default option, b'n'b helps with problems caused by... let's say "less compliant"... DHCP servers.

Share this post


Link to post
Share on other sites
On 5/30/2020 at 6:12 PM, MrPete said:

The problem with belt-and-braces: for some of us, the same computer can show up with different IP addresses in the same overall network (ie connecting to different subnets.) This requires a dynamic solution for both server and client.

AFAIK, at the server end, all methods work just fine.

The only serious problem with dynamic IP's is on the client end, as has been discussed.

MrPete,

For the problem described inside parentheses in your first paragraph, have you defined your subnets per pages 228–229 of the Retrospect Windows 17 User's Guide—and have you added such clients using the Subnet Broadcast access method per the Access Tab alluded to (not described) on page 223?

My impression is that Subnet Broadcast—which I've never used for its intended purpose—searches for the "client" machine using the Piton Name Service on each of the subnets defined on the "backup server".  If that doesn't do what you need, here's why and how to create a feature request Support Case for enabling multiple Direct Access addresses for a particular "client".

 

Share this post


Link to post
Share on other sites

I've had problems with clients not found with many versions of Retrospect (most recently 16.6) currently on Windows 10 Pro Build 18363.  In our small home office, I have a dedicated Gigabit Ethernet dedicated to communication among our PCs.  We have pretty high speed wireless Internet access provided by the place where we live.   I use static IP addresses because long ago I had problems with multicast.  My setup is pretty static anyway.  My problem is that occasionally the IP address, subnet mask, and default route will disappear from the Gigabit Ethernet interface.  This happens both on the "server" and the clients.  Finally I gave up and wrote a command file that runs in the background, periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary.

Share this post


Link to post
Share on other sites
On 6/1/2020 at 5:26 PM, rfajman said:

I've had problems with clients not found with many versions of Retrospect (most recently 16.6) currently on Windows 10 Pro Build 18363.  In our small home office, I have a dedicated Gigabit Ethernet dedicated to communication among our PCs.  We have pretty high speed wireless Internet access provided by the place where we live.   I use static IP addresses because long ago I had problems with multicast.  My setup is pretty static anyway.  My problem is that occasionally the IP address, subnet mask, and default route will disappear from the Gigabit Ethernet interface.  This happens both on the "server" and the clients.  Finally I gave up and wrote a command file that runs in the background, periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary.

rfajman,

You've left out a key word after "dedicated Gigabit Ethernet": you should have written "dedicated Gigabit Ethernet WHATSIS".  Is the WHATSIS a piece of hardware—such as a router or "gateway", or is it a piece of software—such as something in Microsoft Windows 10?

The WHATSIS apparently has an interface, and that interface is checkable and configurable via a command file.  Some Googling seems to show that Gigabit Internet interface is a connection between a computer and a router.  You may have a Windows 10 problem, but I'll let someone who knows Windows explore (no pun intended) that further—based on further information about your script that you must provide.

P.S.: Rewrote 2nd sentence of 2nd paragraph; the interface isn't necessarily a particular Windows table.

Edited by DavidHertzberg
Question mark ending 2nd sentence of first paragraph. P.S.: Rewrote 2nd sentence of 2nd paragraph; the interface isn't necessarily a particular Windows table.

Share this post


Link to post
Share on other sites
On 6/1/2020 at 2:26 PM, rfajman said:

I've had problems with clients not found with many versions of Retrospect (most recently 16.6) currently on Windows 10 Pro Build 18363.  In our small home office, I have a dedicated Gigabit Ethernet dedicated to communication among our PCs.  We have pretty high speed wireless Internet access provided by the place where we live.   I use static IP addresses because long ago I had problems with multicast.  My setup is pretty static anyway.  My problem is that occasionally the IP address, subnet mask, and default route will disappear from the Gigabit Ethernet interface.  This happens both on the "server" and the clients.  Finally I gave up and wrote a command file that runs in the background, periodically checks the Gigabit Ethernet interface, and reestablishes the proper configuration when necessary.

rjafman,

Can you post this script.  Thanks.

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

×