Try it out – it’s simple – but make sure you test it before you rely on it!

Airport Base Station – wired connection

• Open System Preferences
• Choose Energy Saver
• Laptop users: select the Power Adapter section
• Tick the “Wake for ethernet network access” option (wording may vary)

Now it should be safe to let your Mac go to sleep. When you connect to FarFinder or Webjimbo, your Mac
should wake up. Make sure you test it from another computer on your network if you can.
If you have trouble, there’s lots more information in
this Macworld article.

Airport Base Station – wireless connection

If you have a newish Mac (2009 onwards, perhaps), the above should work on a wireless
connection too. If your Mac supports this, the option described above will be called
“Wake for network access”. Again,
the Macworld article
has useful information.

Everyone else

If you don’t have an Airport base station, or if the above doesn’t work for you, your options are:

• Stop your Mac going to sleep using Energy Saver in System Preferences
• Schedule sleep and wake times if you know you don’t need to connect to your Mac at certains times of the day or night,
  thereby saving power.
  You might not save much money, but it’s good for the environment.
• Investigate wake-on-LAN (advanced users only). Note that wake-on-lan is not built into the applications, nor is it likely to be in the future. Your
  aim is to wake your Mac up, then connect to FarFinder or Webjimbo as usual.

“Find Me Anywhere” service for beta users

If you’re using this service for people on difficult networks, you won’t be able to connect to your Mac if it’s asleep. Sorry.

If you’ve just installed an update, and now FarFinder’s menu bar icon now keeps disappearing and you can’t connect, please download FarFinder from our web site and reinstall:

http://flyingmac.com/farfinder/download.html

If you’re not seeing this problem, you don’t need to do anything. The bad update was only available for about 10 hours, and doesn’t affect Snow Leopard users.

All users can now install the update safely, as the problem has been fixed.

My apologies for any inconvenience caused.

—-

The issues Glenn describes above are common to any remote service you run on your Mac, including FarFinder, so I thought I’d contribute some of my own experience.

The single most common problem is when people with DSL connections buy a separate wireless router. This causes the “double NAT” problem Glenn describes – you now have two private networks: one between the modem and the router, and one on the other “side” of the router where your Macs are. Rather than putting the router (or Airport) in bridge mode, I usually recommend telling the modem to forward all incoming traffic to the router (“DMZ” or “default server” setting). This is because most routers support UPnP, while many modems don’t, so the poor user is often saved an extra configuration step.

Alternatively, the simplest solution to the double NAT problem is to buy a decent DSL modem with a built-in wireless router, thus you only need one device.

(Incidentally, cable modems are transparent to the network, so a wireless router added to a cable connection doesn’t suffer the double NAT problem, since it’s on the internet-proper.)

Another big problem is that a lot of routers just don’t do UPnP (automatic port mapping) properly, even though they claim to support it. (I go into this in detail in an earlier comment.) Of the big names, D-Link are particularly guilty of this in my experience, and I often end up advising users to add the port mapping to the device manually instead – a hassle, but a stable solution in the long run.

Having said all this, it’s almost always possible to get things working properly on a home network with the right configuration changes. (Exceptions are cases where the user doesn’t have access to the modem and router, eg. some apartments, some offices, schools and most hotels. The ISP restrictions Glenn describes are less common in my experience.)

But the network device makers are letting us down. Settings are hard to find, badly named and terminology varies wildly from device to device, often to the point of nonsensicality. Reliable, standards-compliant devices would be a great step forward, but there’s also a lot that could be done in terms of automatically adapting to common network conditions, eg. the double NAT problem.

Unfortunately the obvious place to lay the blame is on the software – FarFinder, BtMM or whatever, and you get many people mistakenly saying that a product doesn’t work. You can’t blame them – they shouldn’t really have to care about this network stuff – but they end up missing out on useful software because of it and mislead others too. The fact is that quite often configuration will be required and there’s simply no way for the software to do it for you. The best it can do, like FarFinder, is recognise common situations and point you towards some help.

(Of course BtMM might have other reliability issues too – I don’t know, I don’t need it

One day, IPv6 might solve this all for us, but don’t hold your breath.