Jump to content
henry-in-florida

Retrospect 15.6.x - multicast unreliable. Fails to find an updated, attached network client

Recommended Posts

This is a bug of some long standing related to locating a client. I have found it regularly when needed to add or re-add it to the sources. Here's an example:

  1. I have TWO clients. Both work fine and can be located by IP with no trouble. Also, both exist on my network and Bonjour can locate them in MacOS. However multicast cannot find one of the two. The attached shows the story. Since updating to 15.6.x, I now have to add at least the missing client via it's IP rather than with multicast. 
  2. I tried to turn the client software on and off, restart the machine and combinations reversing these two steps without success. Does anyone have an idea what causes multicast to behave so badly with network attached clients in Retro? 
  3. Have also had the other client go missing from multicast and the opposite client show up instead in previous iterations of the process. 

I conclude that multicast is very unreliable. YMMV.

Screen Shot 2018-12-12 at 10.04.46.png

Screen Shot 2018-12-12 at 10.05.04.png

Share this post


Link to post
Share on other sites

I found this Retro article related to Multicast: https://www.retrospect.com/en/support/kb/why_is_retrospect_communicating_with_address_224_1_0_38

Running terminal as described by the article (ping test of 224.0.0.1), I found a huge number of assignments, which repeat. Could this be the problem?? No idea how to fix it. 

The only relevant IP's are clients at .70, .64 (TWO CLIENTS), .86 (the Server). Can I delete the others (.121, .83, .81, .67)? It seems these may be IP's stored in my router that are no longer active for these clients or their predecessors. I don't see how this could be gumming up the works but I could force my router to forget inactive clients, I suppose. 

Ping Result_multicast_181212.rtf

Share this post


Link to post
Share on other sites

henry-in-florida,

First, have you updated your "backup server" machine and your Mac Clients to 15.6.1.105? 15.5 and 15.6.0 seem to have been "bad releases", at least for Retrospect Windows.

Second, I was told years ago by the now-departed-from-Walnut-Creek Alan that the "backup server" should not have a fixed IP address.   The one time I tried violating that, I had problems.

Third, surely you shouldn't have two "client" machines assigned the same fixed IP address—such as .64.

 

Share this post


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

henry-in-florida,

First, have you updated your "backup server" machine and your Mac Clients to 15.6.1.105? 15.5 and 15.6.0 seem to have been "bad releases", at least for Retrospect Windows.

Second, I was told years ago by the now-departed-from-Walnut-Creek Alan that the "backup server" should not have a fixed IP address.   The one time I tried violating that, I had problems.

Third, surely you shouldn't have two "client" machines assigned the same fixed IP address—such as .64.

 

Hi David,

Thanks for your thoughts on the matter. 

  1. Yes. I neglected to put that in my post. I am running 15.6.1(105) on both Clients, Engine and Server.
  2. When you say "fixed IP", what do you mean by that? The Server name is what I input, its IP address appears when upgrading on the app. I have always done that and this install is no different. Do you mean to leave the Server address set as the "default IP" of 227.0.0.1? That doesn't appear to work. Do you instead mean the machine's router IP? Yes, that is DHCP. 
  3. Please reread. I mention three IP's as being those in use- two clients, and a server. They are respectively ending in: .64, .70 and .86. 
  4. Please re-read the comments I made and the IGMP multicast document from Retrospect. They say that using the multicast model they licensed for port 497 should work. It does, but pings to that address reveal a huge number of devices (judging by their IP) very old devices no longer active but previously assigned to that port. I wondered if that is the issue? Perhaps this is a cause of my problem, not finding the actual devices in use? I recorded the output of the ping list and you'll see the results on the attached document in that comment. 

Screen Shot 2018-12-12 at 18.03.28.png

Share this post


Link to post
Share on other sites

henry-in-florida,

2. Tomorrow is "Make Friends With Your Router Day". ;)  Start by getting the MAC addresses for each of your "client" machines from Apple Menu->About This Mac->Ethernet Cards, and writing them down.  Then proceed with connecting to http://192.168.1.1, logging in with your password (if you haven't changed it, it's probably on a label attached to your router), and phoning your ISP's Tech Support (not Retrospect's).  Once you've done that, you want to ask the T.S. person how to navigate to setting a fixed IP address for each client machine that you actually still have.  On my Verizon Quantum Gateway, that's Advanced-> IP Distribution->Edit (assuming your "client" machines are booted, so they show the default IP addresses in the router).  Enter the MAC address for each machine that you do have, and checkmark the box or whatever to make the listed dynamic IP address the static IP address.  If any machines are listed that you don't have, find out how to delete them.

3.  You said in your second post that you have two "client" machines with the same x.x.x.64 address.  That's obviously a problem; look in System Preferences->Network for each of the "client" machines, and change the duplicate to a different IP address.  Make sure that the static IP for that machine is changed accordingly in your router.

4.  Do not set a static IP address for your "backup server" machine.  That advice came from Alan in 2015.

Share this post


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

henry-in-florida,

2. Tomorrow is "Make Friends With Your Router Day". ;)  Start by getting the MAC addresses for each of your "client" machines from Apple Menu->About This Mac->Ethernet Cards, and writing them down.  Then proceed with connecting to http://192.168.1.1, logging in with your password (if you haven't changed it, it's probably on a label attached to your router), and phoning your ISP's Tech Support (not Retrospect's).  Once you've done that, you want to ask the T.S. person how to navigate to setting a fixed IP address for each client machine that you actually still have.  On my Verizon Quantum Gateway, that's Advanced-> IP Distribution->Edit (assuming your "client" machines are booted, so they show the default IP addresses in the router).  Enter the MAC address for each machine that you do have, and checkmark the box or whatever to make the listed dynamic IP address the static IP address.  If any machines are listed that you don't have, find out how to delete them.

3.  You said in your second post that you have two "client" machines with the same x.x.x.64 address.  That's obviously a problem; look in System Preferences->Network for each of the "client" machines, and change the duplicate to a different IP address.  Make sure that the static IP for that machine is changed accordingly in your router.

4.  Do not set a static IP address for your "backup server" machine.  That advice came from Alan in 2015.

  1. Your ideas have merit, I made "friends" with my router already, David. A long time ago. However, the router is not so friendly as to allow me to remove select inactive IP's singly. I have several IPs that, while inactive now, become active when the WiFi in the device turns on and the devices go from active on wired connections to active on WiFi. So there is NBO REASON to remove inactive IPs en masse. Irrespective to activity there is no reason that this is an issue the Multicast shouldn't take care of (multiple inactive users)itself and there are many reasons I do not want to willy-nilly get rid of all active or inactive IP's. No thanks. 
  2. No, that's not what I said as to the IP assignment of my machines. They're not on the same IP. If you saw that, then it's an error. Let's move on. 
  3. I've already proven (at least to my own satisfaction, if not yours) that based on the article Retro published (shared with you earlier) that Multicast works at the network level. So I disagree that it's a router issue in the first place. The ping proves that the IP's re being discovered. What happens within Retro beyond that is a Retrospect problem. 
  4. I have static IP for my clients and have done so in the past. I feel very comfortable with my router (using it and diagnosing the performance of it) and the system I've got now. Although it's not the fastest in overall throughput, it gets the job done. I'm not making more trouble for myself than it's worth restructuring everything over and over, for no potential gain when there're multiple ways to discover clients in Retro. 

Emailed with a Retro support rep (Kyle) who's got a few more ideas. He suggests making the Subnet broadcast source selections work instead of the Multicast. Tried setting it up. This works very well and both clients respond to it without a problem. Obviously Direct selection of sources is a backup and also works fine, so I've got two paths to source machines, the latter being the most cumbersome. Fine. So Subnet selection's what I'll use instead of Multicast.

There's still no good explanation about why Multicast fails, but I'm willing  (more than, actually) to let Multicast go it's merry way without me. As I said, I've had too many problems over the years with it to believe it's happenstance or router issues as you indicate. Actually don't care to go further unless Retro support wants to carry on.

I'm of the opinion that Retro's implementation of Multicast is the issue. Now, that I present the problem to Retrospect, simply not going to pursue it further. 

Screen Shot 2018-12-13 at 13.40.16.png

Screen Shot 2018-12-13 at 13.40.41.png

Share this post


Link to post
Share on other sites
I was able to ping (e.g., see) from all clients to Multicast port 497, and from the server as previously describer. However I did not ping to Multicast from anywhere. Still assuming a bidirectional pathway. That’s the implication - Multicast to a machine is blocked? 
 
Robin at Retrospect mentioned a Multicast check tool - Multicast Ping for use on two machines to send and receive from each other. See this web page from the developer Mr. Dunagan
When I used the app supplied (Multicast Ping) current version, I was unable to ping from one client to the server when the app was running simultaneously, obviously the very one having the issue in Retrospect. I believe I was successful open up that port (create a firewall "pinhole") on the router IP connection to the client to see if that makes a difference, it should have been opened on the machine when I installed the Retro Client. Perhaps it will open up now, when I retest the two-way ping between the Server and this particular Client. The other devices (client and server) communicate with no pinhole configuration on the router, so I have no idea what could have caused this issue. 
 
Either way, it's simply a matter of interest. Since Subnet protocol seems perfectly fine. 

Share this post


Link to post
Share on other sites

henry-in-florida,

First, sorry for misreading your second post in this thread.  I saw "The only relevant IP's are clients at .70, .64 (TWO CLIENTS), .86 (the Server)", and thought you were saying you had two clients at .64.

Second, thanks for probably solving a problem I have had for nearly two years with -530 errors on Backup script runs.  I wasn't having any problems with Adding my two Mac clients, but I have been intermittently getting -530 errors for the first client (a MacBook Pro) when I run scheduled daily scripts that back it up.  My closest approach to a remedy has been to schedule a "NoOp" script 5 minutes before the "real" script;  the "NoOp" script is a duplicate of the "real" script that adds the No Files rule.  Because the -530 errors are intermittent—indicating IMHO that the error is hardware-related, sometimes the "NoOp" script immediately gets an error but the "real" script runs OK, sometimes both scripts run OK—especially when both my "backup server" and my MBP client are booted before the scheduled time for the "NoOp" script, and sometimes the "NoOp" script sits there past 3 minutes trying to Find the MBP.  My cure in the latter case is to Pause the "NoOp" script, do a Locate—which always works—of the MBP, and then do a Stop of the "NoOp" script; at that point the "real" script always starts and runs OK.

I long ago submitted a Support Request for this problem, and twice Retrospect Tech Support has given me test versions with extra logging so that I can help the engineers find the bug.  I am permanently stuck running the Retrospect Mac 14.6.0 Engine and Console and the 14.1 Client, because the test versions indicated that engineering had introduced a "fix" in 14.6.1 that actually made the problem worse.  I'd like to be able to upgrade to Retrospect Mac 16 next spring so I can upgrade my Mac Pro "backup server" and MBP "client" to macOS 10.14 Mojave to get the benefits of APFS; maybe switching from Multicast to Subnet Broadcast—which I have just done—will enable me to do that.

If Subnet Broadcast makes my intermittent -530 errors go away, that would be IMHO a sad day for Retrospect Inc. :( unless Retrospect 16.0 introduces an explicit fix for Multicast.  If the fix isn't in Retrospect 16, Retrospect Inc. will have to distribute a very-prominent document (for Retrospect Windows, too, because some administrators have reported -530 errors with that variant) that says "Don't add your 'clients' with Multicast anymore, because it creates errors for some administrators.  Instead use Subnet Broadcast; we know it's going to be tougher for you to learn how to do that but you're stuck with it."  I don't think that will ease Tech Support's workload; quite the contrary, since they may have to process additional product returns from disgruntled customers.

 

Share this post


Link to post
Share on other sites

Hi David, 

I should've credited Robin Mayoff, Director of Support and longtime Retro boss. He explained troubleshooting Multicast, which is a network standard, not a Retro invention. The troubleshooting procedure(Multicast app) is nice but not easy to implement, since it involves setting up a path for the client AND the server machines outside of the Retrospect app to prove it works. It clearly didn't. I found the relevant app and tested it. Sure enough, the client's port is stuck for this access, I know not why. 

That doesn't address what the problem is, only that it's not Retro. And it wasn't. The fact that the Server works and it's port is open. That leaves the other port on the router since subnet works and it's blocking of port for the range needed by Multicast. I could've tried to force open those ports for the IP and confirm. That would be the fix for the router- port blocking or assignments. Rather, I simply went with Plan B, e.g., Subnet Broadcast. 

It was easier to implement, and Retrospect engine settings support it quite well. As you apparently found as well. One day, I'll get the complete port assignment for Multicast and open a hole for all three machines' ports. Ah, one day... 

Edited by henry-in-florida
Properly accredit a response

Share this post


Link to post
Share on other sites

henry-in-florida,

First, the person you mentioned in the first sentence of your post immediately above has for years been the head of Retrospect Technical Support—not the head of Sales unless there has been an unannounced management upheaval.  He's worked in T.S. since 1994 (and still will until at least Wednesday according to this announcement), and lived through the "near-death employment experience" I discussed in the first substantive paragraph of this post.  As I discussed in the second substantive paragraph of that same post, he's IMHO a prime example of "Retrospect Inc. PTSD"—so for the last year or so I've had a policy of never mentioning his name on the Forums (because I'm convinced he does a daily search of the Forums looking for a mention of his name in a post by me).  Nevertheless he's a good man doing a very difficult job, and I admire him even though I think 24 years in T.S. have made him just the least bit crabby. ;)

My intermittent -530 error problem has endured through two MacBook Pros and two pairs of Ethernet switches, so it's not a simple hardware problem.  My best guess is that it's related to the fact that the switch in my study—where my two "clients" are located—and the switch in my bedroom—where my "backup server" is located—are connected via an installed-when-the-apartment-was-built stretch of coax cable with a MoCA adapter at each end.  I'd love to replace that with a stretch of Cat5e Ethernet cable, but I couldn't do that without either tearing up an interior hallway floor or running a 100-foot-long Cat5e cable just underneath the ceiling of 3 sides of that hallway.  At a cost of $120 I replaced the MoCA 1.1 adapters with MoCA 2.0 adapters about 6 months ago, but that doesn't make any difference.  IMHO there's a bug in the Retrospect Multicast code that makes it vulnerable to timing delays, particularly when the "backup server" has just been booted and immediately needs to run a scheduled script.  I even started a thread about that on the Ars Technica Networking forum, but nobody had an answer.

Share this post


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

henry-in-florida,

First, the person you mentioned in the first sentence of your post immediately above has for years been the head of Retrospect Technical Support

My intermittent -530 error problem has endured through two MacBook Pros and two pairs of Ethernet switches, so it's not a simple hardware problem.  My best guess is that it's related to the fact that the switch in my study—where my two "clients" are located—and the switch in my bedroom—where my "backup server" is located

Hi David, 

I stand corrected as he-whom-you will not name is in Support. I go back a long way, too. So I recognize the history lesson. However that is very old news. One that I prefer to leave in the scrum gone by.

As to YOUR issue with -530 errors, switches should not cause it, since by definition, a switch doesn't assign IP ports, rather simply allows data to pass along to multiple connections paths at the proper speed between the router (which IS the only type of device to deal with the IP assignment table) and the client device(s). If, OTOH, you have multiple routers (most routers have an included switch) cascaded throughout your network, then it's a different kettle of fish. In case you have "Switches" that are really routers and wish to deactivate the router part, try bridging mode on those routers to avoid a router behind a router situation. Or you can try to use subnets there AND in Retro as you are apparently doing with the proper subnet assignments for your reconfigured system. I'd avoid the use of multiple routers for LANS, personally, as much as practical anyway. After all, do you really have 250+ devices to manage at home?

I use bridging mode for devices like WAP(s), which typically have routers inside them. My network of WAPs improve wireless coverage at home, several WAP's "meshed" to appear as one. I also frequency coordinate my use of spectrum for both bandwidth and cross channel RFI (radio frequency interference) coordination in WAP RF assignment. That has worked for me prior to the advent of recently introduced meshing WAP "systems" that recently came on the market. They don't do that to the same extent as Apple did. They are now out of this market, sadly. 

Again, Apple was way ahead of their time on this since the Airport Express and Extreme WAP products do (and were the first to) coordinate between themselves when set up correctly on a single SSID. Some of these new type meshing devices claim very high network connection speed due to multi-channel wireless connectivity (may be false claims, since I did not notice such terrific, read claimed results when I helped set up a friend's system using one). So I'd recommend you perform some thorough testing for WAPs before using them for Retrospect. 

For backup speed, I still use wired LAN connections between Server and clients, not wireless. 

Share this post


Link to post
Share on other sites

henry-in-florida,

Unfortunately it's not "very old news" when it affects what we can discuss in these Forums.  I suggest you read the last two substantial paragraphs in that same post I linked to concerning the person who is the head of Retrospect Technical Support.

I only have one router in my LAN, and that is my Verizon-provided Quantum FiOS "gateway".  That router is directly connected to a full-up 8-port 1Gbps Ethernet switch in my study.  That switch is in turn connected to a MoCA 2.0 adapter, which via a length of coax cable is connected to an identical MoCA adapter in my bedroom.  Until a few minutes ago the adapter in the bedroom was connected to a 5-port 1Gbps Ethernet switch, but only one of the ports on that switch is in active use—connected to my Mac Pro "backup server".  In order to eliminate a possible source of timing delay, I have just now cabled the "backup server" directly to the MoCA adapter in the bedroom.  It works fine for a test NoOp backup; we'll see whether it makes any difference in eliminating the -530 error I got for the "sacrificial" NoOp script run two hours after its scheduled time early this morning (the "real" backup script scheduled directly after it ran fine).

My LAN is totally wired.  A few months ago I tried running a "real" Backup script via 802.11g (the fastest speed the wireless built into my old Mac Pro supports).  It ran at around 20% of the normal speed, probably partly slowed down by the three layers of sheetrock and one concrete column between my router (a DSL one at the time) and the Mac Pro.

Edited by DavidHertzberg
Added left-out "ago" in 4th sentence of 2nd prgf.

Share this post


Link to post
Share on other sites
8 minutes ago, DavidHertzberg said:

henry-in-florida,

...

It works fine for a test NoOp backup; we'll see whether it makes any difference in eliminating the -530 error I got for the "sacrificial" NoOp script run two hours after its scheduled time early this morning (the "real" backup script scheduled directly after it ran fine).

David,

 

Let's digress... I'm assuming the client and Server now work to at least see the internet.

  1. So, did you use Subnet client selection to register your client, did it find the client?
  2. Did you (delete the old client and) re-add it to your script(s)?
  3. Did this fix the -530 error you said you get or not on an actual backup script?
  4. If not... Did you then see and try the troubleshooting steps here?
  5. What were the results of that? 

Henry

Share this post


Link to post
Share on other sites
3 hours ago, henry-in-florida said:

David,

 

Let's digress... I'm assuming the client and Server now work to at least see the internet.

  1. So, did you use Subnet client selection to register your client, did it find the client?
  2. Did you (delete the old client and) re-add it to your script(s)?
  3. Did this fix the -530 error you said you get or not on an actual backup script?
  4. If not... Did you then see and try the troubleshooting steps here?
  5. What were the results of that? 

Henry

1. It did, but Multicast also did that.

2. Yes, of course.

3.  As per above, when run 2 hours past the scheduled time, the "sacrificial" NoOp script failed within a few seconds with a -530 error, and immediately after that—with no manual intervention—the "real" Backup script ran fine.  This is the -530 Bug 1 scenario, as I have named it,  which has occurred frequently since early February 2017.

4. I followed those steps nearly two years ago.  The only exception is that "Make sure the client has the most recent version of the Retrospect client software" no longer applies, because—as I stated above—going more recent than the Retrospect Mac Client 14.1 makes the "real" Backup script also fail with a -530 error—an intermittent situation which I have named -530 Bug 2.

5. As stated in the preceding paragraphs of this post.

Share this post


Link to post
Share on other sites

Cabling my "backup server" directly to the MoCA adapter in my bedroom, which I mentioned I had done at the end of the second paragraph here, resulted in a -530 Bug 2 scenario when I booted the Mac Pro "backup server" four hours after the scheduled time for the daily Backup of my MacBook Pro this morning.  That means both the "sacrificial" NoOp script and the "real" Backup script failed with -530 errors.  I was then able to do a two-second Locate of my MBP, and run the "real" script manually.

I have accordingly just re-connected my bedroom MoCA adapter to my Mac Pro through the 5-port 1Gbps Ethernet switch in my bedroom.

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

×