Multicast or Network Not Accessible

[mduke]

Retro 8.1 on Leopard 10.5.8 server, 2x.2.8 Dual Quad Core, 6GB RAM.

 

I want to use multicast or subnet so that every time a laptop DHCP changes, I don't have to change the IP for that source. I can always find the source via "Add source directly" but nothing ever appears when invoking Multicast or Use subnet broadcast. Tech support told me to check for the Retro port TCP/UDP and I confirm via my server admin that port 497 is set for Dantz Retrospect.

 

I infer there is more I can check but not sure what. Please advise as to further steps to take to investigate this.

[rhwalker]

Details in these two Knowledge Base articles:

Multicast KB article

 

See the last paragraph in this KB article:

Client discovery

 

There's also a multicast diagnostic written by one of the Retrospect programmers:

Multicast Ping

 

If you still can't get it working, report back and we can go from there. It would be helpful to know your network infrastructure.

 

Russ

[mduke]

Thanks, Russ. I read both pages. Will have to query campus network support on this; not sure how to determine whether the router is blocking multicast and/or subnet broadcast.

 

I'll let you know what I find out.

 

FYI, I can scan all IP devices on our subnet using Apple Remote Desktop. Initially, I might think then that subnet broadcasting is not being blocked, but I'm not clear whether that paragraph is referring specifically to the Retrospect port 497 or more generally (I infer the former).

[rhwalker]

You may be seeing interactions between the Leopard firewall and Retrospect as well. Try with your Leopard firewall turned off.

[mduke]

Finally getting back to this. Turning off the Leopard Server firewall immediately enables both multicast and subnet scanning, so we now know it is definitely the firewall (this despite port 497 TCP/UDP both being open when the firewall is closed).

 

Before I ask a network specialist here on campus to figure out how to enable multicast or subnet without turning off the firewall, can you tell me what needs to be done? I'm guessing this would involve some kind of addition to the server config file.

[CallMeDave]

I confirm via my server admin that port 497 is set for Dantz Retrospect.

 

we now know it is definitely the firewall (this despite port 497 TCP/UDP both being open when the firewall is closed).

 

What does this mean?

 

How exactly was the machine configured to open this port? What process is the port open for? Did you use Server Admin? Or some other ipfw configuration utility? Or the command line?

[mduke]

When I installed Retrospect 8, perhaps it engaged the port, because I never did this myself.

 

But when I used the Leopard Server admin interface, I checked the Firewall/Settings/Services pane and noted Dantz Retrospect had been assigned to 497.

 

Whether this was a default setting done when the Leopard server was first set up I don't know, however. But no, I did not use any ipfw utility or the command line.

[CallMeDave]

When I installed Retrospect 8, perhaps it engaged the port, because I never did this myself.

You didn't configure the firewall and it's not passing packets through to the program you want. Seems a logical train of events. Server firewalls generally don't create new rules on their own.

 

I checked the Firewall/Settings/Services pane and noted Dantz Retrospect had been assigned to 497.

This is very likely out-of-date, as OS X Server 10.5 shipped when Retrospect "Classic" was still in use, long before Retrospect 8.

 

So while the port is still the same, the Retrospect Engine is probably not what's being described there.

 

Try configuring your server's firewall to allow traffic to the Engine process:

 

/Library/Application Support/Retrospect/RetrospectEngine.bundle/Contents/MacOS/RetroEngine

[mduke]

Okay, thanks much, Dave. I've asked my network specialist to help with this as it seems likely this is not something I can do using the Server Admin gui. Or...is it?

[rhwalker]

See also the three links upthread that I provided a while back.

 

This is really something that you should be able to work out with Retrospect support.

 

Note that there are three (and perhaps four, depending on where you have the Retrospect console) things that must get through the firewall:

 

(1) port 497 - this is how the client and engine chat to accomplish the backups.

 

(2), (3) subnet broadcast and multicast - used in client discovery

 

(4) port 22024 - used between the Retrospect console (or iPhone app) and engine, goes through firewall if console is on a different machine See:

Retrospect engine / console port requirements

 

Russ

[mduke]

RH: That's interesting because Retro support told me the ball was in my court if it was a Leopard server issue. I do have the services of a network specialist who said he'd be willing to look into effecting the needed config changes, so maybe this is moot, but I have to admit I was disappointed to have support tell me this, since I figure they would have to have some degree expertise with OS X servers. I'd think my situation would've come up with other users, eh.

 

BTW, in your list, it's "client discovery" that's the issue at hand, correct?

 

Thanks for the info.

[CallMeDave]

it seems likely this is not something I can do using the Server Admin gui

 

I don't see why not. Although a lot of hardcore OS X admins only use the cli.

 

As with other mere mortals, most ipfw rules are beyond my comprehension. I do see in Server Admin's Firewall Services list the "Dantz Retrospect" field is just descriptive text, not pointing to anything specific, so it's reasonable to assume it should work today as it did in yesteryear (meaning my comment above was gibberish).

 

When you tested with the firewall disabled, did you use the "Stop Firewall" button on the bottom of the Server Admin window? Or did you change the radio button to "Allow all traffic" while leaving the firewall itself running? I don't know if these two settings do the same thing, but it might be worth something to have tried them both.

 

And you're sure the "Editing services for:" popup is set to either "any" or to your correct network?

[rhwalker]

RH: That's interesting because Retro support told me the ball was in my court if it was a Leopard server issue. I do have the services of a network specialist who said he'd be willing to look into effecting the needed config changes, so maybe this is moot, but I have to admit I was disappointed to have support tell me this, since I figure they would have to have some degree expertise with OS X servers. I'd think my situation would've come up with other users, eh.

Interesting to me, too, especially since they charge more for a "server" license.

 

To my mind, the frequent problems people have with software firewalls indicates a problem with either (a) the Retrospect installer, or ( the Retrospect documentation, or © both.

 

I don't see this issue because our xServe doesn't have the software firewall turned on. Our small network is pretty locked down, and access at the edge is well controlled.

 

BTW, in your list, it's "client discovery" that's the issue at hand, correct?

Yes. I was just trying to point your network investigations in the right direction. You've got the port 497 stuff working.

 

Russ

[mduke]

RH: I read the brief KB blurb on Retrospect Engine via the link you provided (console port requirements), but afaik, this only applies to the admin console. For the helluvit, I did add a new rule to my firewall to enable 22024 TCP/UDP and as you might expect, it had no impact on the issue at hand.

 

Dave: BTW, there is a difference between turning the firewall off and allowing all traffic: the former leaves the server much more vulnerable than the latter, because in the latter, while all services *can* be allowed, they can be overriden by any rules you set (e.g., advanced rules to limit/restrict access).

 

Possibly the good news here is that by allowing "any" as opposed to turning off the firewall, the multicast and subnet features do work. I'm hoping this is sufficient grist for tech support to provide more specific assistance.

 

Thanks again to both of you for helping me with this dogged issue.

[rhwalker]

RH: I read the brief KB blurb on Retrospect Engine via the link you provided (console port requirements), but afaik, this only applies to the admin console. For the helluvit, I did add a new rule to my firewall to enable 22024 TCP/UDP and as you might expect, it had no impact on the issue at hand.

I provided the console port information simply because, in the information that you have provided to date in this thread, there is no information as to where your Retrospect console is running.

 

On the same machine as the Retrospect engine?

On some other machine on your LAN?

On some computer on the other side of the world on the internet?

On an iPhone, using the console app?

 

Just trying to be helpful,

 

Russ

[mduke]

Russ: okay, gotcha. Yes, it's on the same machine as the Retro engine. Just like my Leopard server admin, I prefer to run admin guis on the machine hosting the server. More reliable.

 

That said, do you think I should try the Retro admin console on my local client machine? I wouldn't think it'd make any difference but ...

[rhwalker]

It won't make any difference if you have the port open.

 

Our server is headless.

 

The only "difference" it would make is to spread the load a bit. In most situations, the Retrospect console is not a very big load - it's just a GUI. The engine does the real work.

 

Some put the console on a separate machine to try to isolate crashing issues. Right now, Retrospect 8, while having come a long way from the 8.0 days, is still not rock solid.

 

Russ