Jump to content

Recommended Posts

Is it at all possible to force Retrospect NOT to use multicast in finding clients. At our university, multicast (and especially broadcast traffic) are heavily restricted, which results in many failures of Retrospect being able to see clients.

 

Retrospect has the direct IP addresses of the clients, why can't it use that only?

 

If this isn't what's causing our failure, then is it just the networking in Retrospect being completely unreliable?

 

Background:

 

Firewalls are set for TCP/UDP port 497 allowed on both server and client. I *am* able to telnet to the clients at port 497 and reach them, however, Retrospect frequently fails to find them during backup. Often, I will have the client list open in Retrospect, try to configure a client, Retrospect will complain that it cannot connect (error -1028). If I wait a few seconds and try again, MAGIC: it will work.

 

I do NOT have the luxury of changing how traffic is managed on our routers.

Link to comment
Share on other sites

Quote:

is it just the networking in Retrospect being completely unreliable?

 


No. The problem is in your network infrastructure. There have been many issues with Retrospect over the 15 years that we have used it, from the days of ASIP and Mac OS 7, now to Mac OS X Server and Mac OS X, and it's far from a perfect product, but Retrospect's networking has never failed us, and it has always been able to find its clients on our network. It's always been completely reliable for us in that aspect.

 

Are you seeing this both on your local network segment and also through routers? Sounds to me like it may be your routers that are unreliable.

 

Russ

Link to comment
Share on other sites

Quote:

Retrospect has the direct IP addresses of the clients, why can't it use that only?

 


 

Are _you_ using only that?

 

> Often, I will have the client list open in Retrospect, try to configure a client, Retrospect

> will complain that it cannot connect (error -1028). If I wait a few seconds and try again...

 

Is this for clients that have been added via IP address (or DNS name)? Or is this for clients that are configured using the network technology that you don't want to use anyway?

 

Dave

Link to comment
Share on other sites

Also, maybe if you have access to the machines when these failures happen, check out if you can telnet into the machine that retro is bombing out on and see if it allows you to connect.

 

is it on specific machines? random machines? random times of the day/backup days? Any software firewalls?

Link to comment
Share on other sites

I enter all clients by IP, not DNS hostname. Yes, I can telnet in at times when Retrospect can't see the client. The server is on Mac OS X 10.4.8, 256MB, 350MHz G4, dedicated solely to Retrospect. Clients are Win2K, XP and 10.4. Retro is current version for all.

 

Clients have either Symantec Client Firewall (explicitly allowing 497 TCP/UDP) or MOSX ipfw (also allowing 497 TCP/UDP).

 

I just replicated it again this morning:

 

Nightly backup reported a failure. I launched Retrospect, found the client that failed (in this case, a WinXP Pro machine), then went to Configure >> Clients >> Backup Client Database. I double-clicked on the client name in the list, then switched to the Configure and Volumes tabs. Each time I did so, I got the -1028 error.

 

I then fired up Terminal and telnetted to the IP address port 497. I got in just fine. I went back to Retrospect and tried again (the same method as above). Again, not visible. I telnetted again to make sure. Works fine.

 

Then I went into the Configure >> Clients >> Network, and hit the Test button. I put in the IP address, and it reported that it found the client, client name and version. Then I went back to configure it, but again it failed.

 

This, IMO, is not a problem of the network (even if it does restrict some traffic), but of Retrospect.

Link to comment
Share on other sites

Quote:

This, IMO, is not a problem of the network (even if it does restrict some traffic), but of Retrospect.

 


 

I'm curious on what your opinion is based.

 

There is obviously a difference between your network (where there are failures) and mine (and Russ's and the majority of users) where there is only success (defined as if the client process is alive, the program can see the client). The software is the same, suggesting that the problem is of the network, not of Retrospect.

 

Retrospect uses UDP only for client discovery. Once the client is logged into the Client Database, communication is (IIRC) only TCP.

 

- In your first post, you suggested that there was magic in waiting a few seconds; is this always the case?

- If you forget the client that has become invisible, then re-add it via IP address, does it come up as expected?

- Are all the clients on the same subnet?

Link to comment
Share on other sites

The replication I did just this morning should be indicative enough that there's something wrong beyond simple discovery.

 

At the *exact* same time that I could telnet directly into the client (from the server), Retrospect could NOT see it in the client configuration. However, Retrospect COULD see it via the Configure >> Clients >> Network >> Test.

 

So, in summary:

 

Terminal: telnet [ip.address] 497 -- WORKS

Retrospect: Configure >> Clients >> Network >> Test [ip.address] -- WORKS

Retrospect: Configure >> Clients >> [select client in list] >> Configure >> Configure -- FAILS

Retrospect: Auto backup -- FAILS

 

While it does SOMETIMES work (the particular client I'm focusing on right now has been backed-up within the last week), it more often fails.

 

We are on a class B network, but the failures are not particular to any subnet.

 

If I *can* telnet into a client, why can't Retrospect? If Retrospect's own Test *can* see the client and report the correct client sw version and client name, why can't it configure?

 

Finally, yes, if I re-add it, it shows up fine... for now.

Link to comment
Share on other sites

Quote:

If I *can* telnet into a client, why can't Retrospect?

 


Because telnet uses the tcp protocol and Retrospect uses udp. just because your network passes one protocol doesn't mean that it passes another.

 

Your problem is with your network, not Retrospect. Sorry that you are more interested in ranting than in examining the facts analytically. Or perhaps you just don't understand networking basics.

 

Russ

Link to comment
Share on other sites

Quote:

Because telnet uses the tcp protocol and Retrospect uses udp.

 


 

I'm just not certain that this is true in this situation (not the part about telnet; the part about Retrospect).

 

If the client is added via its IP address, I don't think that Retrospect needs to pass any UDP packets to communicate successfully. UPD is necessary for discovery only.

 

You (no, not you Russ) were having client problems almost three years ago (post #78779, 09/07/2004). Those symptoms also seemed to be hardware related.

 

The "Test" button only sends a quick ping and receives a quick reply. Configure opens the port for a lot longer. The fact that a few packets can pass but a large request for packets gets hosed suggests a network problem.

 

Since you're not using UDP or any broadcasting, your network gods might be willing to assist. Maybe they can use some "big iron" hardware to test what's going on.

 

Dave

Link to comment
Share on other sites

Quote:

Quote:

Because telnet uses the tcp protocol and Retrospect uses udp.

 


I'm just not certain that this is true in this situation (not the part about telnet; the part about Retrospect).

 


Here is the relevant information for a client computer running the retrospect client (there is no TCP port 497 open, as you can verify by a "netstat -p tcp"):

Code:


rhwimac:~ rhwalker$ netstat -p udp

Active Internet connections

Proto Recv-Q Send-Q Local Address Foreign Address (state)

... (irrelevant lines deleted for brevity) ...

udp4 0 0 *.dantz *.*

... (irrelevant lines deleted for brevity) ...


Russ

Link to comment
Share on other sites

Quote:

Here is the relevant information for a client computer running the retrospect client (there is no TCP port 497 open, as you can verify by a "netstat -p tcp")

 


 

I won't make any snide remarks about your knowledge of networking basics, but if you run that on the client while making a connection between the server and the client, you WILL see activity:

 

Code:



$ netstat -p tcp

Active Internet connections

Proto Recv-Q Send-Q Local Address Foreign Address (state)

tcp4 0 0 ip.address.client.dantz hostname.server.49192 ESTABLISHED

tcp4 0 0 localhost.dantz localhost.59975 ESTABLISHED


 

(I prefer using wireshark to capture packets, but to each their own)

 

The Windows client I was using yesterday to test worked last night and again this morning. However, a Mac client couldn't be seen by the server. So I did the same thing again: Configure: failed. Telnet: worked. Test: worked. Went back to Configure, and then it worked.

 

Ultimately, none of this addresses my original question (which I will rephrase for clarity): is it at all possible to force Retrospect to use direct TCP connections only? Forget for a moment why I'm asking, just please... is it even possible?

Link to comment
Share on other sites

Quote:

I won't make any snide remarks about your knowledge of networking basics, but if you run that on the client
while making a connection between the server and the client

 


Excuse me. From your original post, I thought the stated problem involved the client state during the discovery phase (whether retrospect could "see" the client, not the backup phase):

Quote:

Is it at all possible to force Retrospect NOT to use multicast
in finding clients
. At our university, multicast (and especially broadcast traffic) are heavily restricted, which results in many failures of Retrospect
being able to see clients
.

 


Dave had correctly stated above earlier that:

Quote:

Retrospect uses UDP only for client discovery. Once the client is logged into the Client Database, communication is (IIRC) only TCP.

 


I was just pointing out why your test with Telnet was not appropriate for testing whether client discovery was working.

 

I don't care what snide remarks you make. One of the half-dozen 4.2BSD Unix ports on the market a while back was done by me, so I think that I do understand networking basics. If you want to know my educational background, I could provide that, too. As far as I know, it was the only 4.2BSD port that worked on the Sun I platform; others believed that it was not possible.

 

I was just trying to address your stated problem, which only involved client discovery, not go into a treatise about how Retrospect operates during backup. You seem to feel that you are much more of an expert than anyone here, and you obviously don't want our help. Good luck.

 

Russ

Link to comment
Share on other sites

(oh man, I've gotta stop taking breaks to watch the Attorney General stutter and moan between my first draft and my posting...)

 

Quote:

Here is the relevant information for a client computer running the retrospect client...

 


 

I assume this client was added to the Client Database via its IP address, and not using client discovery? (you've noted before that your desktop computers have unchanging ip addresses provided by your dhcp server)

 

But does this address the issue of whether or not Retrospect rquires UDP to pass even for clients that have been added to the Client Database via their addresses?

 

I'm under the impression that UDP is for discovery only, yet you seem to be suggesting that UDP is required no matter what.

 

Can this be proved/disproved by these cool BSD tools?

 

Dave

Link to comment
Share on other sites

Okay, while I think within all this I've somehow gotten the answer to my question ("No, you can't force it to do TCP only."), I decided I might as well do the heavy lifting and see what's really going on.

 

$ sudo tcpdump -i en0 -p -w capturefile port 497

 

Doing that while checking my various routines reveals that (when selecting the Configure option to connect to a specific Mac OS X client) it sends out a UDP packet (to 224.1.0.38), waits for the UDP repsonse, and then switches over to purely TCP communication. If it doesn't receive the UDP reply, it doesn't even bother attempting a TCP connection, even though it already knows the IP address of the client as part of the original configuration.

 

It does NOT use UDP at all in establishing connections with a Windows client. Goes directly to TCP with the IP address it already knows.

Link to comment
Share on other sites

Quote:

even though it already knows the IP address of the client as part of the original configuration.

 


Provided that the client was added by IP address rather than by DNS name or AppleTalk name by client discovery? I don't believe that you have explicitly stated how the client was added; Dave has asked.

 

Have you made your test by first forgetting the client and then adding it by IP address (rather than by some other way) ?

 

Russ

Link to comment
Share on other sites

Quote:

I don't believe that you have explicitly stated how the client was added; Dave has asked.

 


 

I'll restate it more clearly: Yes, all clients are entered by fixed, unchanging IP addresses, not by DNS hostname.

 

From my original post:

Quote:

Retrospect has the direct IP addresses of the clients, why can't it use that only?

 


 

As far as forgetting then adding goes, yes, I've done that many times. The current Retrospect server installation was a complete machine wipe and install with all clients rebuilt just two weeks ago (to ensure no lingering effects from a possible bad prior machine). In fact, it isn't even on the same physical server as I had originally posted about some years back.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...