Jump to content
file82

Intel 10.5.1 retrospect network communication error

Recommended Posts

If this issue is indeed firewall related, here are a couple of good links for information about Leopard's new firewall technology. Some of these pages include deeper links to more information (including from Apple). As I understand it, ipfw still runs in Leopard, and is ahead of (and different from) the "Application Firewall" that you set with the Security preference pane.

 

 

http://www.isfym.com/site/blog/Entries/2007/11/7_The_Leopard_built-in_firewall.html

http://www.isfym.com/Site/Blog/Entries/2007/11/16_And_Leopard_too.html

Share this post


Link to post
Share on other sites

Thanks for the links, interesting reading. However, I don't know that it's related to firewalls at all, at this point. Some more input from EMC as to what could be preventing this from working would be appreciated.

Share this post


Link to post
Share on other sites

Quote:

I don't know that it's related to firewalls at all, at this point. Some more input from EMC as to what could be preventing this from working would be appreciated.

 


 

More?

 

First off, we have a confirmation from an EMC engineer that this is a "big problem." That's a good thing (the confirmation, not the problem!).

 

Next, we have two ideas from the engineer about what might be the cause ("either a permissions problem with the client or a problem with the file system on the client volume"). We have had confirmation that pitond is running as root (and its binary has the correct setuid permission setting), so it's not that. And while perhaps a file system corruption is possible, even a slightly-less-then-fresh Leopard install should have resulted in a pretty clean directory.

 

Still, running Disk Utility for a repair, or running DiskWarrior 4 (from their CD or from a Tiger hard drive) would be a reasonable thing to do.

 

But it still seems possible that something in the new Apple firewall is responsible for preventing the Retrospect application from writing this file to the Retrospect client package.

 

EMC is not going to be able to fix this until they can reproduce it.

 

Any Forum readers wanna meet up at the EMC booth at Macworld Expo next week smile.gif

 

 

Dave

Share this post


Link to post
Share on other sites

Quote:

Quote:

I don't know that it's related to firewalls at all, at this point. Some more input from EMC as to what could be preventing this from working would be appreciated.

 


 

More?

 

First off, we have a confirmation from an EMC engineer that this is a "big problem." That's a good thing (the confirmation, not the problem!).

 


I'm not sure I read it that way. He said "if it isn't creating/installing the file for the user, it's a big problem". Not that he acknowledges that it's a big problem for EMC, and they're worrying about it at all. I know it's a big problem; it doesn't work (for me). wink.gif

 

Quote:

Next, we have two ideas from the engineer about what might be the cause ("either a permissions problem with the client or a problem with the file system on the client volume"). We have had confirmation that pitond is running as root (and its binary has the correct setuid permission setting), so it's not that. And while perhaps a file system corruption is possible, even a slightly-less-then-fresh Leopard install should have resulted in a pretty clean directory.

 

Still, running Disk Utility for a repair, or running DiskWarrior 4 (from their CD or from a Tiger hard drive) would be a reasonable thing to do.

 


I have just run Disk Utility and asked it to verify the disk. It reported that everything was OK. I do not have a recent copy of DiskWarrior...

 

Quote:

But it still seems possible that something in the new Apple firewall is responsible for preventing the Retrospect application from writing this file to the Retrospect client package.

 


Sure, it's possible - anything's possible. But I'm not a professional IT guy, I have no idea about how firewalls work, I've already wasted days on this, meanwhile my leopard machine is completely not backed up, I've been using it for a week, entering dangerous territory.

 

BTW, today I updated from 10.5 to 10.5.1. No change in the situation. There were supposed to be "firewall fixes" in the 10.5.1 version.

 

Basically, I'm now to the point of wiping the drive, reinstalling Leopard 10.5, which I will then update immediately to 10.5.1, install an RC, and see if it works, before migrating anything back. This will probably waste the better part of a day, what with trying to keep all the work I've done the past week on the machine.

Share this post


Link to post
Share on other sites

As a test, I deleted the retropds.xx files (I had 22, 23 and 24) from my installed client package and scanned from my Retrospect machine.

 

retropds.23 was created when I scanned (Config->Volumes->FooVolume->Browse), and from that point I was able to backup a test subvolume successfully. Other activities such as syncing the clock and changing the Client Name also worked. No further files were added to the client the Contents/Resources/ folder.

 

From what EMC has written in this thread, it seems apparent that only one retropds.xx is needed, and that new ones are spawned when/if necessary, but the old(er) one(s) is/are not deleted.

 

 

Client: Intel Core2Duo iMac, Mac OS X 10.5.1, Retrospect Client 6.1.130

Retro: PowerMacintosh G4, Mac OS X 10.4.10, Retrospect 6.1.138 (and 6.1.126)

 

My install is an upgrade, but I have, in the past, deleted my ifpfw configuration file. Current firewall settings are to allow all.

 

Maybe Mayoff will have some additional information on Tuesday; I'll bring cookies.

 

 

Dave

Share this post


Link to post
Share on other sites

Quote:

From what EMC has written in this thread, it seems apparent that only one retropds.xx is needed, and that new ones are spawned when/if necessary, but the old(er) one(s) is/are not deleted.

 


That seems interesting and different from my conclusions. It would be nice if EMC could confirm that one way or the other. As I mentioned above, my experience was that retropds.22 was created during the installation of the client, when it asks you to supply a password for it, then retropds.24 was created the first time I configured the client from Retro. My machine doesn't use either of those for scanning apparently, it seems to want retropds.23, which is NOT being created.

Share this post


Link to post
Share on other sites

Quote:

my experience was that retropds.22 was created during the installation of the client, when it asks you to supply a password for it, then retropds.24 was created the first time I configured the client from Retro.

 


 

This part is entirely consistent with what I wrote. The version of Retropds.xx that was included with your client installer software is, well, the version included with your client installer software ("Apr 6 2006 retropds.22"). The version of Retrospect that you are using may not be satisfied with that; perhaps it (Retrospect) needs to have a more current version of it (retropds.xx) to play with. So a new one is created.

 

I'd offer that your conclusions are based on different testing experiences/observations then mine are. But my testing works as it should (backups are successful), while your tests result in failures. So it seems reasonable that what I'm seeing is how the software is _supposed_ to work, while what you are seeing cannot be considered to be expected behavior.

 

The information provided by the EMC engineer ("We write a fresh retropds.xx if there is none or if the current one appears out of date") seems to clearly imply the need/use of a single of these files. So the question becomes, what's happening to the resources that do get downloaded to your client machine?

 

My Gut Feeling about firewalls was misplaced, since you'd confirmed that Retrospect (the application) _is_ able to download retropds.xx to your client (or maybe it was just gas).

 

So the question becomes, what's causing your retropds.xx file(s) to fail to work as intended?

Share this post


Link to post
Share on other sites

Quote:

So the question becomes, what's causing your retropds.xx file(s) to fail to work as intended?

 


Yes, that's the question.

 

Well, I'm now at the end of my rope. I have spent the last 2 days testing and reinstalling leopard on this machine numerous times, trying to be able to migrate my previous laptop's Tiger settings to the new laptop.

 

==== TEST#1 ====

- wiped the hard drive and reinstalled 10.5. Created a new account; did not import or migrate any settings from my other laptop.

 

Installed 6.1.130 Retrospect Client, everything went normally.

 

And - It works! (Actually, I did not do a complete BU, just let it start scanning, it scanned the whole thing successfully.)

 

So: Leopard client on a virgin install, no migration of user settings = WORKS.

 

Interestingly enough, while this happening, retropds.24 is running in the processes list. So apparently, my earlier speculation about retropds.23 being needed (for scanning) was wrong. Apparently, in the earlier problem, it actually created retropds.24 like it was supposed to during configuration, but then was never able to subsequently run the process for scanning operations. I have no idea why that would be the case. It can run the process for configuration, repeatedly, but cannot run the same file for scanning (?).

 

==== TEST#2 ====

- wiped the hard drive and reinstalled 10.5 again, fresh. When the option to "Transfer Your Information" arrived, chose "transfer from another Mac", and selected all 4 items (user account, network and other settings, applications folder, files and folders - 44 GB.) This takes several hours.

 

(Note: I did not create the default account, and later migrate using the migration assistant, which is what I did originally, if I recall correctly. This time I used the option during installation to import previous settings, so that I only end up with one user account.)

 

Now, when I did this and then installed Retro Client on the machine, I ran into some issues because the settings and applications that I imported already included a copy of Retrospect Client (which is on the other machine as well.) Example: it didn't ask me to supply a password for the client upon installation, like it normally would, because apparently it is using the password of the migrated one. And this reminded me that I ran into that same issue on this machine a week ago during installation.

 

Anyway, to make a long story short, after doing it this way, the computer exhibits the exact same problems as before - cannot scan the machine, error 519 communication error, stops at 75 folders and 25 files. Once again, no retropds.xx file gets launched while it attempts to scan. retropds.24 *does* get launched during configuration, yet cannot launch during scanning. Yet it worked perfectly fine in TEST#1 without migration of previous laptop's settings.

 

This led me to wonder if it is something with migrating settings from another computer that has a copy of Retrospect Client already installed on it. So, I decided I would reinstall 10.5 yet again, but remove (uninstall with the 6.1.130 installer) RC from the previous machine before migrating the settings.

 

==== TEST #3 ====

- wiped the hard drive and reinstalled 10.5 again. fresh. When the option to "Transfer Your Information" arrived, chose "transfer from another Mac", and selected all 4 items (user account, network and other settings, applications folder, files and folders - 44 GB.) But this time, unlike TEST #2, I uninstalled Retrospect Client from the old machine before transferring settings.

 

Result: computer exhibits the exact same problems as before - cannot scan the machine, error 519 communication error, stops at 75 folders and 25 files.

 

OK, time for a last attempt at migrating settings. I'm going to do it all again, only this time, I will NOT transfer "Network and other settings." You would think that any firewall-related stuff would be in there.

 

==== TEST #4 ====

- wiped the hard drive and reinstalled 10.5 again, fresh. When the option to "Transfer Your Information" arrived, chose "transfer from another Mac", and selected only 3 items (did not select "Network and other settings").

 

Result: still doesn't work. Exact same problem.

 

I transferred my User Account, my Applications, and the files and folders. Something in there STILL causes this situation to happen.

 

Note: I've tried repairing permissions during these tests as well. No change.

 

===============================

 

It seems my only option if I want Retrospect to work is to NOT migrate any settings from my old laptop (which has my entire set of business software and tools), and laboriously manually reinstall every single application and setting (and I have a lot, and a lot of custom stuff). What a joke. It'll take me weeks to get the machine back to my normal operational status. I'll be finding things that don't work right or launch for weeks. I'm sure someone will jump in and blame Apple completely for this, but from my viewpoint, I would expect EMC to be able to tell me what I need to change to make this work. Not just "something is preventing retropds.xx from running", and then I'm supposed to figure it out...

Share this post


Link to post
Share on other sites

Quote:

I would expect EMC to be able to tell me what I need to change to make this work. Not just "something is preventing retropds.xx from running", and then I'm supposed to figure it out...

 


 

The support available on the Forum is by users for the benefit of fellow users. Certainly you have done a yeoman's job on this testing, showing that the problem is not apparent on a clean test bed, and is caused by some other file or setting from the old machine.

 

EMC is watching this thread, as evidenced by Mayoff's input from the very beginning. In the past, users have hashed out cause and effect in posts here, leading to Dantz/EMCInsignia/EMC to address the problem.

 

If you want personalized tech support, you'll need to open a Support Incident with EMC.

Share this post


Link to post
Share on other sites

Quote:

If you want personalized tech support, you'll need to open a Support Incident with EMC.

 


 

$$$ - $69.95 - $$$ mad.gif

 

Well, at this point, thanks for trying to help, I cannot spend any more days dicking around with this. I've got a business trip in two days, I need a fully operational Leopard laptop, with the capability of being backed up before I leave. I guess I'll bite the bullet and start manually reinstalling all of my software...

Share this post


Link to post
Share on other sites

I've been away from this thread for awhile as I've worked around the issue by backing up just specific sub-volumes and it is apparent this problem will only be solved when EMC realizes it is a major issue and starts to address it.

 

The big problem I see with this error is it's inconsistency. You can get it to work or not work just by trying backup at a different day/time without changing anything. Try to duplicate the error several times throughout the day for several days without making a change and you'll see... Obviously something is changing (or some state of the client machine is changing) but finding it will be very difficult. The fact that you sometimes get it to work after making a change "tricks" you into thinking you've solved the issue only to have the problem return later (maybe after you made another change so you think you undid your fix). I can see that this is happening to people as I read these posts. This happened to me several times; once after changing the ACL setting as someone suggested - it seemed to then work; however, I couldn't get it to stop working by changing the ACL setting back, then it stopped working again later and the ACL trick never worked again. I then discovered that if you just keep trying backup at different times without changing anything, you'll eventually get it to work. I used this technique to get my full backups of each Leopard client on each backup disk and then I set my unattended backups to just back up specific sub-volumes on those clients, which always works. One thing I thought of that might change each time without intervention is the preferences so maybe this is a place to look - ?

 

As more and more Leopard clients emerge, EMC will either need to solve this issue or go out of the backup business. If I had a few more Leopard clients, I couldn't use Retrospect due to this issue, so I am looking around...

 

Good Luck!!

Share this post


Link to post
Share on other sites

Quote:

set my unattended backups to just back up specific sub-volumes on those clients, which always works.

 


 

I was just working with a good friend and fellow Retrospect user who is being bitten by this. But when I have him attempt to Configure a Subvloume on the client, he gets the net retry error before he's able to see the dialog box that would allow a folder to be defined.

 

EMC is "close" to releasing a beta of their Universal Binary client; perhaps they're focusing all their engineering resources on getting that released, although without a doubt this issue is real and painful for existing Rosetta/Leopard clients.

 

 

Dave

Share this post


Link to post
Share on other sites

If EMC is focusing all their efforts on the universal binary version and ignoring this problem, they might want to re-establish their priorities or they risk losing their customer base in the interim. Backup software that cannot be relied on to accomplish backups is very serious!

 

I can almost guess the scenario: EMC will come out with the universal binary version (7.x) and fix this "Net Retry" error on that version, then they will say (admit) that all the older versions are not Leopard compatible so you must upgrade to the newer version if you have Leopard, which will cost you $$$. If you have Leopard on non-intel Macs, you will still need to upgrade to this version and run it in Rosetta mode (or they will have a companion non-intel version 7.x that you can upgrade to). Either way, it's going to cost you.

 

Hopefully, EMC will dispel my cynicism and actually fix this problem on version 6.

 

Good Luck!

Share this post


Link to post
Share on other sites

The Universal Client will be compatible with Retrospect 6.1, so it will be a free update.

 

Will the universal client fix the problem you are reporting? I don't know because you are not seeing a problem I have ever been able to reproduce in a leopard environment.

 

If the problem you are having is something we can fix, we won't be able to fix it with an old version of Retrospect Client, it will get fixed in the new client.

Share this post


Link to post
Share on other sites

Quote:

If you have Leopard on non-intel Macs, you will still need to upgrade to this version and run it in Rosetta mode.

 


 

"If you have Leopard on non-intel Macs, you will still need to upgrade to this version and run it in Rosetta mode."

 

(I just wanted to type it again...)

 

Rosetta is emulation software that allows Intel based Macintosh computers to run software that was created exclusively for PPC based Macintosh computers. As such, non-intel Macs don't run Rosetta at all, ever, in any sense.

 

> you are not seeing a problem I have ever been able to reproduce in a leopard environment.

 

Well, I'm convinced that it is real, and I may be able to arrange for access to an effected machine with a routable IP address on a very fast university internet connection. Let me know privately if this is something that might be helpful to your engineering/testing people.

 

 

Dave

Share this post


Link to post
Share on other sites

Quote:

Will the universal client fix the problem you are reporting? I don't know because you are not seeing a problem I have ever been able to reproduce in a leopard environment.

 


 

This whole thread discusses the same problem I have been having (Net Retry error when trying to back up a leopard client). If you (or EMC in general) are not able to reproduce it, I have little hope of it being fixed.

 

Sorry for my cynicism. It's just very frustrating trying to work with backup software that doesn't work reliably anymore. It is rare now that my weekend unattended backup is successful, even though I've done a workaround on this Leopard issue. I invariably have one client that Retrospect gets stuck on until I come back to it after the weekend and abort trying to backup that client that it is stuck on.

 

For example: today I came back to find Retrospect stuck with a Net Retry error on a user (Raylene) until I aborted it. Below is the log. Interesting that it says stopped by operator on 1/19/2008 at 1:21:56 AM even though no-one was around to stop it until I came in this morning and stopped it (1/22/2008 at 9:59:09 AM). One suspicion I have is the screen saver as it was on screen saver when I came in (standard Apple screen saver - I do not allow system sleep to occur). The rest of my backups, which didn't occur, I have set for this evening. I have to do this almost every week. Note: This is not a Leopard client.

 

1/19/2008 1:26:50 AM: Connected to Raylene

 

- 1/19/2008 1:26:51 AM: Copying Macintosh HD on Raylene…

1/19/2008 1:26:51 AM: Execution stopped by operator.

 

1/22/2008 9:59:09 AM: Execution stopped by operator.

Total performance: 0.1 MB/minute with 0% compression

Total duration: 04:26:23 (84:22:52 idle/loading/preparing)

Quit at 1/22/2008 10:03 AM

Share this post


Link to post
Share on other sites

Quote:

"If you have Leopard on non-intel Macs, you will still need to upgrade to this version and run it in Rosetta mode."

 

Rosetta is emulation software that allows Intel based Macintosh computers to run software that was created exclusively for PPC based Macintosh computers. As such, non-intel Macs don't run Rosetta at all, ever, in any sense.

 


 

I stand corrected! I apparently wasn't thinking clearly when I wrote that. I should've said that they would come out with a new companion version designed for non-intel Macs running Leopard that you would still need to upgrade to to solve this issue, but it sounds like a may be wrong with this prediction anyway (hopefully!)

Share this post


Link to post
Share on other sites

Quote:

This whole thread discusses the same problem I have been having (Net Retry error when trying to back up a leopard client)

 

... snip ...

 

For example: today I came back to find Retrospect stuck with a Net Retry error on a user (Raylene) until I aborted it. ... Note: This is not a Leopard client.

 


 

Certainly one of the difficulties the engineers will have is the contradictorily nature of a report such as this. Saying "my problem is with Leopard clients" and then providing an anecdote about a non-Leopard client simply adds to the confusion.

 

I have always been suspicious of screen savers on Mac OS X in regards to background computing.

 

I have no idea what your Operations Log might indicate (it is odd), but I'd suggest changing your Energy Saver settings to put the display to sleep, and set your screen saver to Never.

Share this post


Link to post
Share on other sites

Just as a comment that might reinforce what Dave is saying, our Xserve is headless and so we have never had the screen saver issues (and have never seen this net retry either). We also aren't running Leopard yet because I don't think it is ready for prime time on servers.

 

Russ

Share this post


Link to post
Share on other sites

Quote:

Quote:

This whole thread discusses the same problem I have been having (Net Retry error when trying to back up a leopard client)

 

... snip ...

 

For example: today I came back to find Retrospect stuck with a Net Retry error on a user (Raylene) until I aborted it. ... Note: This is not a Leopard client.

 


 

Certainly one of the difficulties the engineers will have is the contradictorily nature of a report such as this. Saying
"my problem is with Leopard clients"
and then providing an anecdote about a non-Leopard client simply adds to the confusion.

 

I have always been suspicious of screen savers on Mac OS X in regards to background computing.

 

I have no idea what your Operations Log might indicate (it is odd), but I'd suggest changing your Energy Saver settings to put the display to sleep, and set your screen saver to Never.

 


 

It seems like you purposely "snipped" out the context to make what I said seem more contradictory. I was trying to point out that this isn't the only problem I've been having with Retrospect. It seems like your constantly looking to correct others and you're not satisfied until you do. I have given enough examples of my problem throughout this thread, as have many others. I do appreciate your feedback, except for the parts that seem like an attempt to make others feel like they're stupid.

 

That said, I will try the energy saver suggestion. I know that putting the computer to sleep prevents backup from occurring but I never tried just the display sleep (apart from screen savers, which I've never had a problem with in the past)

Share this post


Link to post
Share on other sites

Quote:

It seems like your constantly looking to correct others and you're not satisfied until you do.

 


 

Generally, what I try to elicit from posters is detailed, specific information. It's the only way that this inherently limited mode of communication can be effective in solving issues.

 

You said it best yourself in post #105563 "The big problem I see with this error is it's inconsistency."

Engineers are not magicians; if they can't see the bug/error/defect running on a test machine where they can debug the code, they can't understand/fix the problem.

 

So the help that users here who are affected by the problem can give is to keep the thread on topic, and note the similarities and differences of the places where it crops up.

 

Red herrings are the big danger, and this thread has already had its fair share.

Share this post


Link to post
Share on other sites

Quote:

Red herrings are the big danger, and this thread has already had its fair share.

 


 

I'll have to disagree with you on this point. Sometimes the answer is found in these seemingly "Red Herrings." I'm not saying to go totally off subject but you are apparently implying that my comment about having Net Retry errors on a non-Leopard client is what you consider one of the Red Herrings, when it actually might point to a broader cause of the problem.

 

Anyway, I think I've run my course on this thread except to browse it now and then to see if a solution ever emerges. I think the thread contains a lot of useful info for anyone at EMC trying to tackle this problem, which I hope they do soon.

 

Good Luck and Take Care!!

 

Tim Sachi

Share this post


Link to post
Share on other sites

May be a solution :

 

I had the same issue after using the migration assistant.

Using the terminal, I compared the / with with a new, fresh and working 10.5.1.

 

Then I removed all files, on the bugus MacBook Pro, that where not on the working machine.

 

I can now scann and define a subfolder ! smile.gif

 

HTH

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

×