December 5, 2010 4:34 PM   Subscribe

Vnc Mac PC Question. I'm trying to setup a VNC connection that allows a windows box to screenshare a mac desktop, but I'm having issues and all the how-tos online assume you're behind a router. Any help would be appreciated.

The setup: Mac OS X (Leopard) running VineServer. (Remote management enabled) I've tried the PC with TightVNC and RealVNC (firewall is off). I've got them ethernetted to each other with no router in between. (Is this my problem?) I can't seem to ping the mac's IP from the PC and just keep getting destination host unreachable. Obviously the VNC isn't even managing to connect. I can connect to Vine Server fine using Chicken of the VNC on another mac. I know that OS X has native support for VNC but it seems like from help posts in forums online it doesn't play well with 3rd party VNC software hence the VineServer. Any thoughts? Is there some basic aspect of a simple LAN between a PC and a MAC that I'm missing here? These two machine's will never ever be online for anyone who's worried about security. (It's a theater thing screensharing in order to control a program that needs to live in the booth while the operator sits in the audience during techs).
posted by edbles to Computers & Internet (14 answers total)
Best answer: If you can't get ping to work, you'll need to get your network happening before you need to worry about VNC apps.

If you're just connecting the machines directly, have you set static IPs? Just plugging two machines together with ethernet will generally lead to two machines waiting for the other to assign a DHCP address.
posted by pompomtom at 4:39 PM on December 5, 2010

Response by poster: Ok static IPs are set on both machines still nothing. It seems like the windows box is receiving packets, but is unable to send them? When I try to ping from the MAC the received packet count on the windows box goes goes up, but the Mac has 100% packet loss. When I ping from the PC the mac nothing changes in the packet info tab.
posted by edbles at 5:31 PM on December 5, 2010

Now disable the firewall on the PC and I think you'll be right.
posted by pompomtom at 6:01 PM on December 5, 2010

Best answer: Either the PC is not responding / blocking outgoing ICMP replies, or the Mac is blocking / ignoring incoming ICMP packets. Is the Mac's firewall turned on ("Security => Firewall") and, if so, what are the settings under the "Advanced" button?

And, just to be sure, what are each machine's IP addresses & subnet masks?
posted by Pinback at 6:01 PM on December 5, 2010

Response by poster: DIFFERENT SUBNET MASKS! VNC is working now. The windows box was on and the Mac was on Didn't realize I had to set those as well as part of the static IP config, which in retrospect is silly. Thanks!
posted by edbles at 6:25 PM on December 5, 2010

Best answer: Set the gateway on each machine to the IP address of the other machine. Make sure the static IP addresses are on the same network (if the subnet mask is, then the first three octets of the IP address need to be the same.)

I don't believe that a PC will block pings with the firewall in standard configuration, so if you can't get pings something else is wrong. Might be a cabling issue- if the receive pair on the Mac or the send pair on the PC is broken, you would get this behavior.
posted by gjc at 6:34 PM on December 5, 2010

And the IP addresses were both within the same subnet e.g. 192.168.0.xxx? Odd, I would never have picked that as the problem. Go figure…
posted by Pinback at 6:37 PM on December 5, 2010

Response by poster: Nope. I had them on slightly different subnets. and so I changed them both to which I guess means only the first two octets needed to be the same and I got lucky. And now I'm reading the wikipedia page on subnets and am getting that it is a whole big binary and thing happening.
posted by edbles at 6:45 PM on December 5, 2010

Best answer: Yes, you've got it.

The standard setup for the school network I admin involves using a subnet mask of, which means that the first 23 bits define the subnet and the last nine identify the host (this is policy from upstream, not something I designed).

Every now and again I find myself needing to explain, to technicians who ought to know better, why the broadcast address on our LAN really does have to be even though DHCP is set up to hand out addresses in the 10.129.172.xxx range. You would be surprised just how many qualified people still don't get the "whole big binary and thing".
posted by flabdablet at 8:01 PM on December 5, 2010

Best answer: In 99% of small-network cases you can ignore the whole "big binary thing AND thing", and just deal with 255 & 0. 255 means "I'll only talk to addresses where these octets match", and 0 means "don't care, I'll talk to anything".

But I'll note that those addresses you have are in the 169.254.x.x range, which are link-local addresses (i.e. only really valid on a single network segment), and are auto-assigned at startup in cases when the machine expects to be given an IP address but isn't. If you've hand-assigned them, you're probably better off choosing addresses in the 10.x.x.x or 192.168.x.x. ranges (or the 172.16-31.x.x range, which blows my simplistic netmask explanation above ;-), which are allocated to private non-internet-routable networks.

And if you've let the machines auto-assign themselves those addresses, you'll be even better off if you give them fixed address in one of the aforementioned ranges.
posted by Pinback at 8:01 PM on December 5, 2010 [1 favorite]

Best answer: By the way, the 169.254.x.y address range is reserved for link-local IP addressing (aka zeroconf, aka Bonjour). Hosts that don't get addresses assigned by some other means (e.g. static addressing or DHCP) will just pick 16 bits at random for x.y, do a quick check to see if some other host on the LAN has already claimed that address, and just start using it if not. Assigning static IP addresses in that range is the Wrong Thing.

If you're going to use static addresses, make them 10.x.y.z, 192.168.x.y, or 172.16+w.x.y (where w must be between 0 and 15, x y and z must be between 0 and 255, and they can't all be zero or maximum values). And read about classful addressing even though you're always going to be defining an explicity subnet mask.
posted by flabdablet at 8:19 PM on December 5, 2010 [1 favorite]

Best answer: Also: if these computers are only ever going to talk amongst themselves, they don't need a gateway address defined. The existence of a gateway address just sets up a default route meaning that any packet destined for some other subnet will get sent to the gateway machine. Since all your traffic will be within the same subnet, you don't need a gateway. You also don't need to define a DNS server.

The other option is to ignore everything you know about IP addressing, tell both the machines to configure themselves via DHCP, and actually let the zero-conf and mDNS stuff work its magic; you should then be able to have the machines refer to each other by host name rather than IP address. When this works it's excellent (except that Windows will complain about having "limited connectivity") but if it gives you any grief, kick it in the head and go old-school with static addresses an no names.
posted by flabdablet at 8:27 PM on December 5, 2010

Response by poster: Oh my god I love you people. Ok when I set this up for reals in the space I'll do the 10.x.y.z thing.
posted by edbles at 12:39 PM on December 6, 2010

The most common netmasks for 10.x.y.z addresses are (which has the same effect as the implied netmask for class A addresses) and (which is easy to think about because the host ID fits in one octet). It doesn't matter which (if either) you use, as long as it's the same on all connected boxes.

If you're using netmask, then x, y and z collectively define the host ID and can be anything you like on any box. X and/or y and/or z must differ from box to box, and x, y, z can't be 0, 0, 0 or 255, 255, 255. The broadcast address will be

If you're using netmask, then x and y form part of the subnet ID and z defines the host ID. X and y can each be any 8-bit value at all, and must be the same on all boxes. Z must differ from box to box and can't be 0 or 255. The broadcast address will be 10.x.y.255.

If you can work out the right rules for using netmask with a 10.x.y.z addressing scheme, you've passed IP Addressing 101 and are entitled to have your attention drawn to wireshark.
posted by flabdablet at 9:02 PM on December 6, 2010

« Older Materials for Making Hemp Rope   |   How do I covercome my need for a large amount of... Newer »
This thread is closed to new comments.