Ghost Solution Suite

I can install the client from the console (on Server 2003) to XP and Win2k machines with no issues. The Win2k machines then communicate with the console. However, the XP machines will not.

It's not a firewall issue. I disable the firewall service on SP2 machines, still no go. I installed plain XP on a new machine (no SP2), still no go. I sniff packets on the client machines and see the the server is periodically polling on ports 137 and 138 UDP, but the client machine is not responding. In fact, I see no traffic from the machine to the server at all.

Machines are Dells (GX520 with Broadcom gig onboard nic, GX240 with onboard 3Com nic). Same issue on both types. Machines are also on same subnet as server (10.30.x.x, 24 bit subnet mask).

I'm stumped.

D'oh, I was sniffing the wrong ip address.

I sniff packets from client machine ip to 229.55.150.208 on port 1346 from 1345. But the server does not receive them. I can't sniff the server because it's on VMWare and my sniffer won't play ball with the virtual nic.

Sniffing on a Win2k machine shows the same request, but it promptly gets acknowledged by the server.

The ngctw32.log file shows polling for the right server.

Bizarre. Win2K is perfect, XP with firewall disabled can't communicate.

> I sniff packets from client machine ip to 229.55.150.208 on port 1346 from 1345.

Those are queries to locate the server; 229.55.150.208 is an IP multicast group, to which the server subscribes when it starts so that it can be found. The server should reply to this, and from then on once the client has found the server it will send occasional polls from port 1346 to port 1347.

> But the server does not receive them.

Presumably, you're looking in the ngserver.log to determine this; incoming server-location requests are logged there, although ones that it doesn't recognise as being for itself aren't logged in much detail.

> I can't sniff the server because it's on VMWare and my sniffer won't play ball with the virtual nic.

I personally use Wireshark, from http://wireshark.org - if it's installed on the host machine, it can sniff the virtual networks fine and the captures it gets from the host's NIC include any bridged traffic for guests.

There have been versions of VMWare workstation where guest operating systems do not receive IP multicast packets at all. However, if the Win2k machines are getting responses from multicast inquiries then that's probably not the issue. One thing to check is that the queries being responded to are sent to 229.55.150.208 - if the queries getting a response are sent to the unicast IP of the server machine rather than to the class D, then that's potentially an explanation.

**One thing to check is that the queries being responded to are sent to 229.55.150.208 - if the queries getting a response are sent to the unicast IP of the server machine rather than to the class D, then that's potentially an explanation.**

Should have mentioned that. Yes, that is where the 2K machines are sending packets.

I'll try the sniffer you recommended. I'll update with any results.

Thanks, Nigel, for pointing me the right way.

I needed to turn on IGMP on the vlan interface at our core switch router. I have no idea why Win2k was able to function without it, and XP could not. But now, they are both happy.

Wireshark got me over the hump :-). Thanks for your assistance there, too.