-519 Error

[pkeenan]

OK Boys and Girls,

With the help of a forum brother I am now in the right forum to ask this question. Maybe not get an answer but I'll ask it anyway.

 

I recently upgraded to Retrospect 8.1. It's installed on a Mac Mini and is backing up 7 computers. I upgraded because the Retrospect client in version 6.0 kept turning itself off. Now I can't get a solid network connection. I continue to get a -519 error (network communication failed) even though I know all of the computers that I'm backing up are online.

Anyone have a "fix" for this situation? I'm a bit perplexed since I went to the hip to pay for the newer software.

 

My server is in a DHCP config and on Monday (Feb 1) I will go to static to see if that helps.

 

All and any answers are most welcome. Do you think the folks from EMC monitor these forums? Just curious.

 

Thanks in advance.

[Tree]

I also made the leap, almost a year ago, to RS8 in the belief that it would deal with the thorny issue of clients turning themselves "off". Over the past year, as I've tried coming to terms with the new flawed software I have learned what the actual problem with the clients was, since I ran into the same phantoms when using the newer client. Of course, the client that one gets with RS8 is a version 6 client, so why should we expect things to be any different? I was kinda surprised that there wasn't a version 8 client; maybe that's something still in the works, alongside the User's Manual.

 

Basically, the "turning off" was really more like "not turning back on" after reboot; Startup Items was failing to invoke the client properly and thus the client would be "not running" (reported status) after a restart. I believe that the fix for this will apply to RS6 as well; it's not dependent on the RS version but rather on the particulars of installation and operating system. You can search through these forums for my own older posts about this, how I specifically dealt with it.

 

However, I do believe the -519 error is something different, and I too see this error from some clients, occasionally, though not all. I had also seen -530 errors which proved to be OS X firewall related, but as I got firewall exceptions squared away I continued to see the -519's. I haven't had much time to try and analyze the situation, opting instead to just tolerate and work around... because as I said they don't always happen.

 

In my case, all clients are on static DHCP (i.e. the router reserves an internal IP for each MAC address), and now that I mention that I have to wonder if it plays a role... such as somehow accidentally getting two devices assigned to the same IP, though I don't think this is happening (and would expect some more visible consequences besides RS client issues if it were).

 

I'll watch this thread, and throw in any useful info I might come across, as I find time to investigate.

[rhwalker]

In my case, all clients are on static DHCP (i.e. the router reserves an internal IP for each MAC address), and now that I mention that I have to wonder if it plays a role... such as somehow accidentally getting two devices assigned to the same IP, though I don't think this is happening (and would expect some more visible consequences besides RS client issues if it were).

Doesn't sound like the grave disorder that would occur if multiple devices were at the same IP.

 

Do you have multiple DHCP servers? It can be done, but only if:

 

(1) all static maps are identical in all DHCP servers, such that no two MAC addresses will get the same IP lease, and

 

(2) if you don't have any dynamic DHCP scopes that overlap between the two DHCP servers, and if one DHCP server's dynamic scope doesn't overlap the other DHCP server's static scope.

 

Really doesn't sound like what is happening here, though.

 

Russ

[Tree]

I agree that overlapping IP's is most likely not happening here; I only mentioned it because I did have one machine that kept insisting its IP was the same as a networked printer a while back, and I think I had to go reserve a different IP for the printer in order to let the computer have its way. I might be remembering that wrong, but at any rate I saw some kind of unexpected behavior from my static DHCP settings in the past. I do only have a single router managing the static DHCP, and I'm not seeing other grave disorders, so I'll table this line of thinking.

 

Back to the intermittent -519 errors; I had some scripts that ran overnight, with three in particular that dealt with a client that has produced -519's repeatedly in the past. They did not generate any -519's last night. However, the first one of the three did produce a -530 (client not found) error when it ran at 9:45 PM; the other two, which ran after 11 PM, both ran with no problems (i.e. the client was found). I know nobody was here to make any changes or even wake up the computer between 10 PM and 11 PM, so why would a client go from "not found" to "found"? It makes me wonder whether there is some network gremlin that sometimes gets reported as -519, sometimes as -530, and sometimes doesn't get seen at all.

 

Wish I had better information than that right now, but I'm just starting to dig into this.

[rhwalker]

Ok. That's helpful.

 

Did you add the clients by name or by IP? Because all of your clients are (or should be) staying at the same IP, try forgetting them and then adding them back by IP. That would eliminate multicast / broadcast issues with routers, etc., because the Retrospect discovery stuff wouldn't be in play then.

 

Russ

[pkeenan]

Gentlemen, You two seem like you're on to something. I will continue down my path and add anything that I find appropriate. All of my client computers are DHCP. Only the server is a static. Currently I've paired back all clients to just one. I'm taking it through it's paces and will add the others one at a time. I did restart the Retrospect engine as well as repair the permissions on the server as directed in other threads. I also deleted config80.bak and config80.dat just to be sure. A word of warning though to anyone who's fine tuned their "Rules". Print out or copy down all of your custom rules because they will be lost forever after you delete those two files.

 

Thanks.

 

Peter

[rhwalker]

I did restart the Retrospect engine

Might be useful

 

as well as repair the permissions on the server

Voodoo, not useful.

 

I also deleted config80.bak and config80.dat just to be sure. A word of warning though to anyone who's fine tuned their "Rules". Print out or copy down all of your custom rules because they will be lost forever after you delete those two files.

That's why I suggest to people, before they try this step, to move those files to the Desktop with the engine not running (or somewhere that the engine can't find them) so that they can be moved back if this doesn't contribute toward a solution.

 

It's been requested since time immemorial with Retrospect (not just Retrospect 8), if the preference file won't be made human readable (XML?), which would be the obvious first choice, that there be some way to "export" the settings into a readable form, and then "import" the settings back later. Such a step would make troubleshooting so much easier, would enable standard tools (diff or document comparision redline) to see the result of changes and detect corruption, etc., but this suggestion hasn't received any attention. Sigh. There are standard libraries (debugged, and solid) that can read and write preferences from/to an XML file. That's well-known technology.

 

Russ