not seeing 6.3.029 clients

[markshe]

I'm not able locate intel macs running client 6.3.029, i can Ibelieve I mis-posted this in the mac version 6 forum, this is a repost in the correct (i hope) forum.

 

I can ping the mac clients 6.3.029, no firewall is 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. I am lead to believe this it is a client problem with software/system conflict. anyone tried going down that road?

[CallMeDave]

I can get clients to show briefly by removing and re-adding them.

 

Removing them from where? You can only remove a client Source if it's already been added.

 

 

tried multicast and subnet.

 

Subnet broadcast would only work if you had configured it in Preferences.

 

 

I can ping the mac clients 6.3.029

 

What about the "Test Address..." button in the Add Source drop-down sheet?

 

What about the Add Source Directly... button in the same place?

[markshe]

OK bad verbiage are the way around.

 

1) Removing them from where? You can only remove a client Source if it's already been added.

 

correct, should have said I can get client to work briefly by adding them in with add source directly, never actually see the client that is added.

 

2) have not tried test address, will try that later.

 

3) add source works, but only briefly and I never see it. Tried using static IP and add source directly, it doesn't work for long either.

 

 

[markshe]

i can't explain it, but one mac client started to show all by itself, The other two still don't. I configured subnet with 192.168.1.0 and mask of 255.255.255.0.

 

Using test address didn't produce anything.

[Daniels]

Have you checked the client and made sure that are actually turned on? Also have you checked the firewall on the clients to make sure the client is getting through? Was the shown client in a different state than the other two that are not showing up?

[markshe]

OK this is officially getting weird,

 

Yes I checked client it is on, firewall is off, clients are all in the same state. Also, installed Single Server Mac (8.2.0399) on same machine that has client that will not be seen, it sees all of the other clients.

 

Now the kicker:

 

I installed Parallels 6.x, then XP, Sp 3 and installed the windows client 7.7.106 and that shows up fine on same machine that has client (Mac) that will not be seen.

 

All of this is done under multicast, none of the clients show up under subnet configured 192.168.1.0, 255.255.255.0. Network has only three switches with the server on one end. One windows machine is seen on the middle switch and one Mac is seen at the other end. What is going on here?

[Daniels]

What is the status of each client, i.e. waiting for first access, etc.?

[markshe]

What is the status of each client, i.e. waiting for first access, etc.?

two are ready and one other is waiting for first access.

 

warning log files from one computer are next:

 

1285822625: Main: Client version is 6.3.029

1285822625: SopsLoad:

1285822625: SopsLoad: continuing on...

1285822625: NetStart: starting interface thread

1285822625: netCheckNewInterfaces: found new address 127.0.0.1:0

1285822625: ConnStartListen: starting thread ConnStartListen for 127.0.0.1:0

1285822625: netCheckNewInterfaces: found new address 10.211.55.2:0

1285822625: ipludAddMembership: adding membership for 10.211.55.2

1285822630: IPNSRegister(0): registered: "Pro Tower","aa9c0198ce0d3e32","0.0.0.0:0"

1285822630: ConnStartListen: starting thread ConnStartListen for 10.211.55.2:0

1285822630: netCheckNewInterfaces: found new address 10.37.129.2:0

1285822630: iplud: bind() failed with error 48

1285822636: IPNSRegister(0): registered: "Pro Tower","aa9c0198ce0d3e32","0.0.0.0:0"

1285822636: ConnStartListen: starting thread ConnStartListen for 10.37.129.2:0

1285822637: bindToValidBootPort: gServerPID has been initialized to 206

1285822641: netCheckNewInterfaces: found new address 192.168.1.201:0

1285822641: iplud: bind() failed with error 48

1285822647: IPNSRegister(0): registered: "Pro Tower","aa9c0198ce0d3e32","0.0.0.0:0"

1285822647: ConnStartListen: starting thread ConnStartListen for 192.168.1.201:0

1285824293: NetGetMacAddr: This system's built-in MAC address is e8:06:88:cc:1e:58

1285852320:

1285852320: SopsSetNotifyStates: notify = 131079

1285852320: SopsSetNotifyStates: theServer.parms.notifyNumDays = 7

[CallMeDave]

clients are all in the same state

 

- And what state is that?

- What does the "Status" field of the Retrospect Client application show?

[markshe]

thought I said: two are "ready" and one other is "Waiting for first access".

 

[Daniels]

The next thing I would try is checking permissions on the clients? How was the client installed, i.e. using a restricted user, using an admin account, etc.?

Also try the following commands in the terminal and see what the results are. These commands are same as using multicast from within Retrospect to add clients:

 

On Retrospect machine:

echo 'Hello from Retrospect.' | nc -u 244.0.0.255 1234

 

On the clients:

sudo tcpdump -nAs0 224.0.0.255

 

If you get no results on the clients then multicasting is not working and you may need to try adding the clients manually. You may also need to change the commands slightly to match your multicast settings.

 

You can also try the Multicast Ping tool which can be downloaded here.

[markshe]

I did a clean install of 10.6.4 (on client) and I can now be seen by Retrospect server. The other clients are still broken, at least I know the problem is on the client side. I will continue to build it until it breaks. Right now the only difference is the client was previously built with 10.6.0 and upgraded incrementally to 10.6.4, as are the other machines, hate that to be the fix, but it is a potential fix. more than I had previously.

[rhwalker]

Consider also that it's something about the OS update after Retrospect install process that changes the firewall configuration.

 

You might have the same problem on this client after a subsequent 10.6.x update.

 

It seems to be a battle with Apple's attempt to make the firewall more bulletproof (for security reasons), adding not only port and protocol lockdown, but lockdown by target applications allowed to use those ports / protocols, complicated by Retrospect's moving/renaming due to rebranding after the EMC to Roxio migration.

 

It just might be that this can only be fixed by a more robust repair procedure by the Retrospect installer.

 

Russ

[markshe]

I would think more about the firewall, but I had this working under parallels 6.x, xp sp3 working through windows firewall and apples firewall without any problems. it was when I used only 10.6.4 and (with firewall on or off) with 6.3.029 that it broke.

[Daniels]

Interesting since the machines I have running 10.6.4 in my setup have never had this problem however the client was not installed until after the machines had 10.6.3 and the clients have been upgraded with 10.6.4 so maybe something changed between 10.6.0 and 10.6.3

I would not put it pass Apple to do this since they made a library change in 10.5.3 making packages with a certain copyright character to be broken on Intel-based machines.