Can't connect to client

[noca]

I'm running Retrospect 6.5 Pro over Win2KPro and am having trouble communicating with the Retrospect client running on another Win2KPro computer on the same subnet. Here's what I know:

 

Client doesn't appear in the "clients" window, and when tested, returns error 541 - backup client not installed or not running.

 

Other networking works fine between the two computers (e.g., ping, windows filesharing)

 

Problem does not seem specific to these two computers. Other clients on the subnet are just as obscure. I even installed Retrospect on another test computer (within the subnet). It too could not find any clients.

 

I've tested this with computers that have fixed IP configurations as well as those using DHCP -- no difference. The DHCP server is a domain controller on our subnet, but these computer do not log onto the domain.

 

No personal firewalls are running on any of the computers.

 

The computers are normally plugged into LAN sockets in the walls which lead to switches and routers I don't control. However, I have been told that TCP/UDP port 497 filtering is not occurring at our router.

 

I CAN get things to work properly by setting up an isolated network using a SOHO DSL router/hub -- a Linksys BEFSR41 -- only consisting of the two computers in question (no outside link). I set both computers to use DHCP, and things work just fine.

 

Per this forum's advice, I used Portqry to look to examine the client computer. "portqry -local" reveals that while plugged into the wall, the client computer has only one entry for 497:

 

TCP 497 127.0.0.1 LISTENING 0.0.0.0:26822

 

A "portqry -n mycomputer.edu -e 497 -p both" returns that neither 497 port is listening.

 

As one might expect, in the isolated network configuration, portqry returns that both ports ARE listening properly. There's three entries in the "portqry -local": one for 127.0.0.1 and one each for TCP and UDP binding to my IP address.

 

While connected to the wall, I tried manually binding the client with "retroclient -ip mmm.mmm.mmm.mmm." This did not fix the problem nor change the results of portqry. Looking at the Retrospect Client window (on the client computer) after I run this command it says: "IP address specified not available, client will be inaccessible." The client service (as seen in CP) also stops at that point even though the Retrospect client window says it's "on."

 

Before I run the binding command, the client says "waiting for first access," and the CP reports that the service is running.

 

To be sure, I do understand that mmm.mmm.mmm.mmm should be my IP address, and when I am trouble-shooting this with DHCP enabled, I confirm my IP lease with "ipconfig."

 

I'm stumped. Seems like the problem is at the client, but I've run out of things to try.

 

For what it's worth, the wall ports are on a VLAN with a subnet mask of 255.255.255.128, while with the DSL router/hub I get a subnet mask of 255.255.255.0. Dunno if that difference is significant.

[natew]

Hi

 

Can you connect the machines directly with a crossover cable or a really basic hub? If that fails we can at least rule out the network as the problem.

 

Chances are the router is not specifically blocking port 497 but it is probably not forwarding multicast packets. Retrospect uses multicast to discover clients and set up the initial connection.

 

The subnet masks you mentioned indicate that the machines are on different subnets. Retrospect professional is only capable of seeing clients on the local subnet.

 

Hope that helps

Nate

 

 

 

[noca]

Thanks for the response Nate. Blocking of multicast packets at the router is definitely a possibility, but it seems there must be something more going on for the Retrospect Client to be unwilling to bind the IP address when the computer is plugged into the wall, but not when plugged into the SOHO router.

 

I think I have the answer now, though. It appears that the 6.5 client is actually designed to not bind to IP addresses in the range 169.xxx.xxx.xxx. Yeah, you heard that right. So, if you have an IP address that's say in the range 169.237.xxx.xxx, which is like... every single computer on the University of California, Davis campus... then you might as well give up ever trying to get the 6.5 client to work for you. Kind of ironic that our bookstore sells a product that won't work on our campus, eh?

 

So the important difference for me between the SOHO router and plugging into the wall was not the subnet mask, but rather the IP address itself. I tested this by manually changing my IP address to something in the 168.xxx.xxx.xxx range while plugged into the wall. Sure enough, the retrospect client binded my IP address just fine (according to portqry). Couldn't test whether that actually made the client work in my situation because the IP was bogus, but at least this solves the binding problem.

 

I hear the work around for this is to use the 6.0 client. Haven't tried that yet.

[noca]

Yeah, it looks like the 6.0 client works just fine for my present purposes (duplication).