clients jumping from wifi to ethernet

[Pokeseven]

Hello

 

My current backup host is Retrospect 6 for Macintosh; i'm thinking about upgrading to version 8 and would like to know if Retrospect have managed to fix one of my major annoyances with the app...

 

A large portion of my laptop users jump from wifi to ethernet; at present with version 6 the host see's the client machines as being offline if they're not under the IP under which they were setup {i think }

 

this means i have to chase users down and ensure they're sitting at their original spot in the studio with their wifi switched off and or ethernet plugged in...

 

any help / input on this matter would be much appreciated!

[Maser]

What I do for that is modify the "RetroClient" file located at:

 

/library/startupitems/RetroClient

 

 

File looks like this initially:

 

#!/bin/sh

 

##

# Start retroclient (formerly pitond) daemon

#

# please make sure this is saved with unix line endings

##

 

. /etc/rc.common

 

if [ -f "/Library/Preferences/retroclient.state" ] && [ -d "/Applications/Retrospect Client.app" ]; then

ConsoleMessage "Starting Retrospect Client"

/Applications/Retrospect\ Client.app/Contents/Resources/retroclient &

fi

 

 

 

Modify it so the last part of the file looks like this:

 

/Applications/Retrospect\ Client.app/Contents/Resources/retroclient -ip www.xxx.yyy.zzz &

fi

 

 

where the "-ip

" part contains the *static* IP address of your clients.

 

That way, when the plug into the IP address you set them up with -- assuming they get a *static* IP address -- the client is forced to *only* use that IP for backup.

 

 

(You could be giving them static WIFI addresses -- but that's usually not done -- what I do here is configure their *Ethernet* IP addresses and tell the users they must be docked to their Ethernet if they want backup. This has not been a problem...)

 

 

Works here just fine.

[Maser]

And, if I remember correctly, this works with Retrospect 6, too (as you are making the change on the *client* only.

[Pokeseven]

Hello - Correct me if i understand wrong: this solution works on the premise of static IP on ethernet - most my users are never in one place and my studio seating plan changes every 6 months....

 

:: sys admin nightmare ::

 

[rhwalker]

No, just set your DHCP up to assign IPs by MAC address from a "static map" rather than from a dynamic pool. That's "sys admin happiness" because each computer always gets the same IP. It makes reverse DNS lookup work on your LAN, it means that you can log computer accesses by name rather than by IP, and you can access computers by name rather than IP. Makes life much simpler, allows central management.

 

If you also have a dynamic pool, make sure that the DHCP scope of that dynamic pool doesn't overlap with the DHCP scope of the static map. Otherwise, grave disorder results.

 

Russ

[CallMeDave]

A large portion of my laptop users jump from wifi to ethernet; at present with version 6 the host see's the client machines as being offline if they're not under the IP under which they were setup

 

That's the problem [color:purple]Multicast[/color] was designed to avoid, wheres Retrospect see clients on the subnet(s) by name and not by number. Of course, if you add a client by IP address you've bypassed that feature and told Retrospect not to look anywhere but at that address.

 

While Retrospect 8 is still exhibiting teething pains in regards to client communication, Multicast in Retrospect "Classic" has always worked pretty well. Why have you setup your clients via IP?

 

just set your DHCP up to assign IPs by MAC address from a "static map" rather than from a dynamic pool

 

As long as your WiFi and Wired networks are all in the same subnet, served by the same DHCP server.

[rhwalker]

As long as your WiFi and Wired networks are all in the same subnet, served by the same DHCP server.

Most routers don't allow that because of routing confusion - where should the packets go? Back out on the same interface? To another interface with the same subnet? Confusion abounds. Routing is supposed to be simple, based only on subnet.

 

I completely agree with you, Dave, about the multicast discovery. I was only responding to the "::sys admin nightmare::" response to Steve Maser's workaround suggestion.

 

Russ

[Glenn_K]

The multicast feature will not work for me. It never finds the client. I can add by IP, then IP changes and client is lost.

 

:-(

[CallMeDave]

The multicast feature will not work for me. It never finds the client. I can add by IP, then IP changes and client is lost.

 

Then the major annoyance has been the failure of Multicast to work on your network; if you add by IP and that address changes, the loss of the client would represent the program working as expected and designed.

 

As to the "where should the packets go" question, I'm not real great with this routing stuff, but I have a wired home router in the basement and an Airport Extreme in the living room, and both are on the same subnet, with only the basement device providing addresses. That's bridging, no? I thought it was pretty common for a LAN...(and now the whole internet knows my ignorance).

 

 

Dave

[Glenn_K]

I'm also finding that it seems like prefs get corrupted easily and makes Multicast not work. After deleting prefs, my multicast worked right away.

 

The idea of using DHCP and always having the router give the laptop the same IP is a good one for when IP is the only way to add.

[Maser]

The idea of using DHCP and always having the router give the laptop the same IP is a good one for when IP is the only way to add.

 

 

That's what I've done for years -- going way, way back.

 

There are a whole bunch of non-Retrospect-related reasons why (IMO) it's good for clients to pull the same IP address whenever possible.

 

If you can easily set your DHCP server to do this, it really is worth the effort to set it up that way.