Ghost Solution Suite

I'm running GhostCast Server v8.2.0.1116 on Windows Server 2003 R2. This is running on an IBM xSeries 366 server with two on-board Broadcom Gigabit NICs. No matter what I do, I cannot get the Ghost 8.2 client (booted from a Win98 boot disk) to connect to the GhostCast session.

Here are some of the things I've tried:
- Reverted to Ghost 8.0 - no difference
- Tried Multicast, Unicast, and Directed Broadcast - no difference
- Tried entering server's IP address in the client instead of using automatic discovery - no difference
- Tried disabling the second network card on the server - no difference
- Tried using the other network card on the server and disabling the first - no difference
- Set up the GhostCast session on my laptop - works (proves the client PC is OK)
- Booted from a WinPE disk on the server and ran GhostCast on that - works (proves that it's not the hardware)
- Tried running the client on a different PC - doesn't work

Here are some of the things I've discovered:
- I can ping the client's IP address from the server (using DHCP)
- If I capture packets on the server (using Windows' built-in Network Monitor), I can see that the server is receiving the multicast packets (10 of them) from the client looking for the session
- If I do a "netstat -a -b -n" at the server, I can see that GhostSrv.exe is listening on UDP 0.0.0.0:6666 like it should be.
- I do have WINS servers configured so looks like the client is not falling back to NetBIOS broadcasts (and there is no WINS entry for the session).

Any ideas?

That's a very thorough investigation. The only thing I don't see explicitly mentioned is the Windows firewall state - the 8.2 code doesn't actually set itself up automatically in the Windows Firewall so it's possible that it's being blocked, which would seem to match the symptoms that you describe. The NetMon packet capture tool gets the incoming packets before the firewall has a chance to inspect them (and discard them); if they are visible in NetMon but the GhostSrv program doesn't respond then it's seems likely that a firewall has sent the packets to the bit bucket.

The command-line command
c:\> netsh firewall show config
is a good way to dump all your firewall settings at-a-glance for all your NICs, including the enable states, application exceptions, and port exceptions.

To enable logging at the default log location, you can use
c:\> netsh firewall set logging droppedpackets = enable
and that should produce a logfile showing discarded packets. If the incoming session query packets end up in that log, you'll need to add an exception rule for GhostSrv.

I forgot to mention that the Windows Firewall/ICS service is disabled. Also checked for any other firewalls that I could think of. Then I had one of those "d'oh" moments. Never did try disabling the antivirus software. As soon as I did, it started working! Turns out that someone configured the blocking of two ports in McAfee/NAI VirusScan: port 25 and port 6666. (Didn't even know that VirusScan had a firewall.) The module name is called Access Protection and the rule that was blocking 6666 is named "Prevent IRC communication". Once I added GhostSrv.exe to the Excluded Processes list, it worked.

By the way, thanks for the quick response.