Multicast not working on 6.2.229 Intel Macs?

[mcnaugha]

I've just installed Retrospect Client 6.2.229 on a serious of 10.5.4-based Intel Macs. There seems to be odd behaviour with the ability to multicast to the Server. I have not had this kind of problem before. My Retro Network browser cannot find my clients... which are all online with the Retro client showing a status of "ready".

 

I can't get the subnet broadcast to work either. Addresses are 10.123.88.x/255.255.248.0.

 

The clients were showing immediately after install and before the restart. Since then they do not automatically show up. I have to add my address and this will become a problem when their DHCP lease runs out and they may change IP. I've already lost over 10 clients already to changing IPs.

 

Help!

 

Thanks.

[mcnaugha]

I just caught one of our systems with the Retro client turning itself off, as per the topic in this forum. That doesn't appear to be the case on all of them. It's definitely a multicast issue too.

[Mayoff]

When you install or update to the new client, it must be added to the 10.5 firewall (if the firewall is turned on) even if you had an old client in the firewall.

 

Once it has been added to the firewall (if the firewall is on) then everything should work.

 

Did you update the Retrospect Application to the latest version? That is also required when updating the clients.

 

If you updated your clients over the network use the .rcu file, then you will probably need to uninstall and reinstall the clients due to the RCU bug turning clients off.

[mcnaugha]

These were fresh installs. Matching Retro app version.

 

No firewalls enabled.

 

This is an all-gigabit network with no management at all. So nothing blocking Retro port.

[zsoul]

I am having a similar problem with OS X clients, and I'm stumped.

 

We're running Retrospect MultiServer 7.6.123 on a Win 2003 box.

 

I'm using a later version of the OS X client than the original poster, version 6.2.234 on an Intel Mac (MacBook Pro) running 10.5.6

 

When I first install the client, everything seems fine. The server can see the client via Multicast, and back everything up. However, as soon as I restart the client machine, the server can no longer connect via Multicast or Subnet Broadcast. Only by direct IP can we see the client and connect to it. This is unacceptable in our network environment, which gives dynamic IP's to workstations.

 

Our OS X workstations do not have a firewall turned on, and there should be nothing restricting port 497 from being used.

 

It should be noted that there are some client workstations for which this error does not occur. I cannot find anything different about their configuration. They are running the same client version on the same OS version, on the same subnet of the same network in the same office. However, the majority of our clients are having this problem.

 

If anyone is having similar problems and/or a solution at hand I would love to hear it.

 

-AL

[CallMeDave]

If anyone is having similar problems and/or a solution at hand I would love to hear it.

 

Don't have a solution, because the cause of the problem is unknown.

 

But I do have a test.

 

Bring the Macbook to the Retrospect host machine, and connect the two directly using an appropriate ethernet cable (Macbooks are auto sensing, so cross-over wiring should not be required).

 

Give each machine the appropriate network settings, and see if you can see the client.

 

If you _can_ then you know the Retrospect software is working correctly at both ends, and that the problem lies in between.

 

If you _cannot_ then you still don't know what's causing the problem.

 

 

Dave

[rhwalker]

Check to see which network interface is listed first (primary) for the MacBook. Possibly Retrospect is listening on the wrong interface (Wireless?) after reboot.

 

Check the interface ordering between the Mac clients that work and the clients that don't work.

 

Russ

[zsoul]

Thanks for the quick response!

 

Russ, the primary network interface is definitely correct for our environment on all the clients, and is ordered the same way for them all. Ethernet, then airport. We have port 497 blocked on our wireless access points to enforce fast backups.

 

I will try your test, Dave, when I get a chance. Our Retrospect host machine is located offsite several miles away, and I won't be able to go over there for a few days at least. I am reluctant to say that it is a network issue though, because I can connect to the problematic clients by entering their IP or DNS name, just not via multicast or subnet broadcast.

 

Here's something interesting I found out: I can get my client "visible" again if I force quit the retroclient process, and then turn the Retrospect Client back On. This is obviously not a solution I want to roll out to the people I work for. It does suggest, however, that the problem is with the retroclient crashing.

Edited March 18, 2009 by Guest

[rhwalker]

If you updated your clients over the network use the .rcu file, then you will probably need to uninstall and reinstall the clients due to the RCU bug turning clients off.

did you try uninstalling those clients (use the Uninstall menu choice in the 6.2.234 client installer) and reinstalling locally (run the installer image on the client, not using an .rcu client push)?

 

You may have hit the bug that a local uninstall/install will fix.

 

Russ

 

[CallMeDave]

I can get my client "visible" again if I force quit the retroclient process, and then turn the Retrospect Client back On. This ... does suggest, however, that the problem is with the retroclient crashing.

 

No, it does not.

 

If retroclient were crashed you would not be able to kill it, nor would be able to connect via IP.

 

Our Retrospect host machine is located offsite several miles away

 

This suggests a large and likely complex network. I agree that if a simple restart of the retroclient process makes a difference, that suggests the software. But your original post was clear when you wrote: "as soon as I restart the client machine, the server can no longer connect via Multicast or Subnet Broadcast." Since retroclient starts up "as soon as" the machine does, it would be odd that killing/restarting the daemon at that moment would make much difference.

 

But if you can reproduce the failure with a system restart and then solve it with an immediate cycle of retroclent, that would be quite interesting.

 

Dave

[rhwalker]

Just for yucks, could you please type the following command in Terminal (best way is copy-and-paste so that you don't make mistakes) on one of the misbehaving machines and report the results:

cat /Library/StartupItems/RetroClient/RetroClient

The line of interest is the next-to-last line that ends with an "&".

 

Russ

[zsoul]

Russ, here's the contents of RetroClient:

 

#!/bin/sh

##
# Start retroclient (formerly pitond) daemon
#
#	please make sure this is saved with unix line endings
##

. /etc/rc.common

if [ -f "/Library/Preferences/retroclient.state" ] && [ -d "/Applications/Retrospect Client.app" ]; then
ConsoleMessage "Starting Retrospect Client"
/Applications/Retrospect\ Client.app/Contents/Resources/retroclient &
fi

 

Dave, you are correct that our network is both large and complex. In troubleshooting this problem I've found there may be issues with our DHCP server as well.

 

I just got back from vacation this week so I am getting a Rashomon Effect from support staff on the issues at hand here. I apologize if I am being needlessly accusatory towards EMC.

 

I will try Uninstall and re-installing the client as well, although I really hope that isn't the solution as it will mean doing the same to over a hundred laptops.

 

Thanks again for your help,

 

AL

[rhwalker]

Ok, thanks. You've got the correct startup code. Earlier versions of the Retrospect Client (before 6.2.x) had a different name for the daemon that was started at boot time.

 

Prior to when you do the force quit, is the name of the process that you blow away "pitond" or "retroclient"? (should be the latter).

 

Like Dave, I think this would be very interesting if you can reproduce the failure with a system restart and then solve it with an immediate cycle of retroclent.

 

The reason for my inquiry was not only to see whether you had the correct startup code, but to wonder whether you also had an older client on the machine, too, such that one was starting at boot and another was being started after your force quit. You might want to try the following Terminal command to see if that might be the case:

 

locate Retrospect

Of course, a local uninstall (using the installer image on the Retrospect updates page) would fix.

 

Russ

 

[Risdall]

Has a definitive solution been reached? We're having the same issues -- visible when first installing, disappears after a restart, and can be made to reappear after force quiting the process and starting again. Our network is not complex. The mac in question is running 6.3.028, server is W2k3 running 7.6.123.

[twickland]

I'm not sure that the Mac client version 6.3.x will work with Retrospect 7.6.x for Windows. The client version that was last distributed for that Windows version was 6.2.234, available here.

 

If downgrading the client doesn't help, you should repost your issue in the Windows section of the Forum, since that's what you're running on your backup computer.

[Daniels]

Client version 6.3.x does work with Retrospect 7.6 for Windows. You may want to check the firewall on both the client and the server.

[Risdall]

Force quitting the app and starting again via the control panel allows the machine to be backed up. That rules out firewall and client/server compatibility, and seems to indicate a client issue. If any other poor sap out there has successfully dealt with this issue I'd be very grateful if he/she would share the solution.

[mhintz]

I'm not sure if this will resolve your issue but here is the band-aid I finally resorted to in order to resolve all my unresponsive Mac OS X clients problems. There's probably a better way.

 

I created a script file with the following and save it at /library/application support/reretro/reretro.sh. The script forces down retrospect client and then launches it.

 

 

 

#!/bin/sh

 

kill -TERM `ps -ef | grep retroclient | grep -v grep | awk '{print $2}'`

/sbin/SystemStarter start "Network Backup"

 

====

 

Then I created a launchd job to run the script a minute before the daily backup script is scheduled to run and saved it in /library/launchdaemons:

 

 

<?xml version="1.0" encoding="UTF-8"?>

Label

tld.YourDomain.reretro

ProgramArguments

/Library/Application Support/ReRetro/reretro.sh

StartCalendarInterval

Hour

17

Minute

59

UserName

root

 

====

 

Either reboot the client computer or use launchctl to load the launchd job.

[markshe]

I'm not able locate intel macs running client 6.3.029, i can ping them, no firewall turned on. server 8.2.0399 20 client version. windows clients are seen and backed up without any problems. I can get clients to show briefly by removing and re-adding them. flat network (192.168.1.x) tried multicast and subnet.

 

making my life as backup guy a real pain. seen lots of posts to this problem by no answers. leads me to believe it is a client problem with software/system conflict anyone tried going down that road?