Comment 2 for bug 608701

This came about because a user wanted to VNC to a machine which is inside a LAN that has no connection to the outside world. In that instance vino refused to enable because it couldn't get to the outside world to test the incoming port. So using an external site to detect local connectivity isn't robust.

I see three issues really.

1) vino shouldn't depend on an _internet_ connection, but could just rely on a _network_ connection, in which case the suggestion jpds makes about nm seems valid? Many (most?) people will be behind NATed connections so an external site making an inbound connection to VNC server will be pointless because without port-forwarding it will always fail.

2) vino shouldn't rely on some random website(s) to determine if it should or should not start.

3) The user is not told (or asked to confirm) that an outbound connection, and a subsequent inbound connection to their machine is made.

This bug seems to be a combination of those issues.