multicast response on wrong network

[jalex]

I'm (still) running Retrospect 5.0.238, currently under Mac OS 10.3.3. Client version is 5.0.540. I'm generally able to make this combination work fine for me, so I don't intend to upgrade for now. The client and server are on the same wireless subnet. The server is also on a wired network. The wireless network is configured to be the primary interface (i.e. it appears first in the list of interfaces in the Network pref panel).

 

My problem is that I periodically cannot get the server to talk to my single client. It happened again today, so I decided to take a close look at what's going on, and try to solve this once and for all. What appears to be happening is this:

 

(1) Server sends the retrospect multicast over over the wireless interface.

(2) Client receives the multicast packet.

(3) Client, perpexingly, responds using the address of the server's wired interface's IP address, which it can't reach since the client is not on the wired network.

 

It seems that the server is requesting that the client respond using the wired network since if I change the server's wired IP, the client follows suit and tries to respond using the new IP.

 

I've been able to work around this by putting a static route into the client's routing table, telling it to route traffic bound for the server's wired IP to it's wireless IP, but I'd really rather such a hack wasn't necessary.

 

I suspect the problem stems from the fact that the client initially was backed up over the wired network, and has this information cached somewhere in its configuration. Is there any way that I can get retrospect to stop trying to using the wired network?

[shadowspawn]

I was just looking at the same problem today with a somewhat different setup, and you have got further than me. I assumed because changing settings on the server fixed the problem that the server was at fault, but perhaps the client is implicated too.

 

I suspect "Configure Subnet Broadcast" might help, but for me "This feature requires a more powerful application license code". :-)

 

(I look forward to a solution that does not mean I have to turn off internet access on my desktop computer to back up clients on the local network.)

[jalex]

I may have a solution to your problem, if what you have is two network inferfaces on your desktop, and you have to temporarily disable the primary interface to back up clients. Try this, as root (change en1 to match the identifier of the network interface your LAN is on, if necessary):

 

/sbin/route delete 224.1.0.38

/sbin/route add 224.1.0.38 -interface en1

 

This forces Retrospect's broadcasts to go out the inferface you want them to go out. Then launch Retrospect (quit and restart if its already running), and check to see if you can reach clients. If that works for you, then you can create a StartupItem that executes these commands whenever you reboot.

 

My problem seems to be the other half of the coin: the clients are responding to the wrong interface, seemingly because Retrospect has cached this interface somewhere. Turning off my wired interface doesn't make any difference for this issue.

 

I suspect that it is actually related to the "license code" issue in that it is caused by unintended behavior from Retrospect server code meant to enforce licensing restrictions: you only get to only back up clients on one network. This restriction is fine for my purposes, only I'd like to change that network if I want to.

[shadowspawn]

Nice one jalex, the route commands mean I can now access clients without altering network settings on desktop/Retrospect Server.

 

Good luck with your problem!

[natew]

Hi

 

My understanding of the issue comes from the linux multicast how to (good read BTW)

 

Apparently the OS kernel picks one interface to route multicast packets. As to which one it picks - your guess is good as mine. I suspect it chooses what the computer thinks is the primary interface.

 

Your solution of setting a static route is actually quite good. I wonder if removing the gateway settings from your wired nic would achieve the same results? Forcing multicast replies through wireless.

 

Thanks

Nate

[jalex]

No, please go back and read the entire thread. Setting a static route for Dantz's multicast channel, or else making the LAN interface primary by reordering the interfaces, etc., does solve shadowspawn's problem, but doesn't help with mine. My clients have only one active interface, the wireless interface, so they can only reply on wireless, if they reply at all.

 

I can use a static route to make Retrospect server's multicast to go out any interface I want. The clients, however, do not respond via multicast - they respond via normal TCP/IP addressing. The Retrospect server must be including a "reply-to" address in the data it is sending via the multicast it uses to search for clients. The clients blindly reply to whatever address the server specifies, regardless of whether they have a route to that address. In my case, the server asks that the client respond to the wired interface's address. I don't know why the server chooses the interface it does for its "reply-to" address - it does not seem to be affected by which interface is primary. In fact, in my case, the wireless interface is primary, not the wired! My speculation is that the server's preferred interface is cached the first time you successfully configure clients. If this is really the explanation, I just want to know how to clear this cached information.

 

I don't know why the clients don't do all of their communication over the multicast channel, anyway, since client discovery is done via multicast. Probably a performance issue.

[natew]

Hi

 

With Mac clients there isn't much you can do to force the client to work on a particular interface. The best solution I have heard so far is to set up a different location where the wired NIC is disabled. That way Retrospect has no alternative but to route traffic to the wireless.

 

As far as I know Retrospect and Retrospect client don't keep track of which interface it used to back up.

 

Just out of curiosity, what are the IP address for each adapter? Is the client sending multicast replies out the numerically lower address?

 

Thanks

Nate

[jalex]

I think we're still failing to communicate here. The client has only one active adaptor, a wireless one. The wired interface is not turned on, and has no cable connected to it. The server has active wired and wireless interfaces, and the wireless inferface is primary (it is first in the list in the network preferences panel).

 

Retrospect server sends its multicast packets, correctly, out of the wireless interface; nothing is sent out the wired interface. The client sees the multicast, and replies, but, perplexingly addresses its reply to the IP address of the server's wired interface, no matter what I set the wired interface's IP address to. Since the client is not on any wired network whatsoever, much less the wired network that the server is on, it has no route to the server, so the server never sees the reply.

 

Here's a relevant chunk from a tcpdump on the wireless network (probably should have included one in the first place):

 

11:59:15.233929 IP 192.168.2.51.49458 > 224.1.0.38.dantz: UDP, length: 196

11:59:15.234395 IP 192.168.2.52.dantz > 192.168.1.10.49458: UDP, length: 196

11:59:17.383410 IP 192.168.2.51.49459 > 224.1.0.38.dantz: UDP, length: 196

11:59:17.385195 IP 192.168.2.52.dantz > 192.168.1.10.49459: UDP, length: 196

11:59:19.532696 IP 192.168.2.51.49460 > 224.1.0.38.dantz: UDP, length: 196

11:59:19.533161 IP 192.168.2.52.dantz > 192.168.1.10.49460: UDP, length: 196

 

192.168.2.51 = server wireless interface, en1

192.168.1.10 = server wired interface, en0

192.168.2.52 = client wireless interface

 

This pattern continues as long as I have the server scanning for clients. If I change the server's wired interface to a different address temporarily (I tried 192.168.1.11 and 192.168.5.200, to test whether the lexicographic ordering of the addresses made any difference), and the client always follows the change, always trying to respond using the server's wired IP address. This means that the server must be telling the client to use the wired interface's address somewhere within that packet it sends out to scan for clients.

 

If I disable the server's wired interface, then the clients do respond properly using the wireless address.

 

Based on this further testing, I think you're right: no caching is going on. It looks like what's happening is that Retrospect server defaults to sending its multicast packets out the primary interface; in Mac OS X, the primary interface is whatever interface is first in the network control panel. Retrospect server also picks one of the interfaces to tell its clients to respond on, perhaps by choosing the lowest-numbered device. It really doesn't make any sense that it chooses different interfaces for these purposes, so I'd definitely call this a bug. It seems to me that a much better way of handling this situation is to allow those of us with Desktop licences to explicitly choose the interface that will be used for all backup traffic as a preference within retrospect, since we can't pick clients by IP address like those with Server or Workgroup licenses.

 

I know that it's vanishingly unlikely I'll see a Retrospect 5.0.x fix for this, but maybe this thread will help others who have run into problems finding their clients. For myself, though, it would be really nice if someone could definitively say whether this behavior is still present in 5.1.x or 6.0, so that I would know for sure that an upgrade would make this little annoyance go away ...

[natew]

Hi

 

Thanks for the clarification. You are right - I didn't understand everything you were saying.

 

I know 5.1 does not have any changes in this regard but Retrospect 6.0 has some updates that are designed to make it work better with multiple ethernet adapters. I don't know the details of those improvements but it may address this very issue. It is worth installing the trial version of 6.0 at least to see.

 

I would test this here myself but I only have one Nic on my machine.

 

Thanks

Nate

[jalex]

FYI, I have now upgraded to Retrospect 6.0 for other reasons, and the behavior that I describe earlier in this thread is still there, and is very annoying for those of us with multiple NICs. If Dantz wants to continue to limit the Desktop product to one network, that's fine, however the backup administrator ought to be able to configure _which_ network they wish to use for backup. This ought to be a trivial feature to add.