> Have never been that frustated!!
We understand, it can be difficult to diagnose these things. My best advice for these things is to be methodical - when solving tricky problems like this, I grab a pencil and a notebook and start writing down everything I can. Sometimes the notes come in handy when trying to sift through data, but as often as not the important thing about having a lab notebook is the act of noting things itself.
Diagnosing these things remotely is hard too, so I'll be methodical in terms of trying to sort out some important details of what is happening for you.
> It just goes into Ghost 8.3 and all I could do there is to create an image locally, which obviously I can not.
Just to confirm, do you actually get to the point of trying to choose a session, or is the option to GhostCast not available to you?
If not, then there's some kind of problem with the network drivers; either they don't match your specific NIC, which can happen - the Broadcom design is licensed out widely and if you're working with a licensed variant then you may need manufacturer-specific drivers or something else along those lines. Basically, anything more you can tell us about the hardware you have will help.
From here on, I'll presume that you do get to enter a session name, and it fails to actually find the server.
When you enter a session name into Ghost, it begins by trying to find the server; it starts by sending out a multicast packet to try and find the GhostCast server that is hosting the session name. If that doesn't yield results, it tries to look for the session name using the WINS protocol, which is the same protocol used for workgroup machine name resolution. If you have a designated WINS nameserver on your network (advertised through DHCP) it asks that nameserver, otherwise the WINS protocol does a local network broadcast to find a nearby machine that has that name registered.
So, if it can't find your GhostCast server quite a few things have to go wrong, and it can take a while to diagnose each one. For instance, you can use "nbtstat -n" on the machine running the GhostCast server application - once you have clicked the "Accept clients" button in that application is when it tries to register the session name, and the "nbtstat -n" command lets you confirm that it has (and that therefore, the client can use that method to find it).
Ultimately, the easiest way through this tends to be to do a packet capture using Wireshark on the GhostCast server machine, covering the time setting up the session on the GhostCast server (specifically, so it can see the multicast group and WINS name registration) and the client querying to try and find the server. You can send them to me for analysis, but the main thing I tend to look at is which query packets the client generates actually make it to the server machine, and how your switch is configured with respect to multicasting.
> The GhostCast server and client both on same segment.
Well, the "segment" is really a concept from the days of classic DIX coaxial Ethernet when a segment of coaxial cable supplied the "ether". Nowadays since almost all "Ethernet" networks are switched point-to-point twisted-pair links, I'd tend to assume that being on the same segment means being connected to ports on the same switch, and that your IP subnetting is probably set up so that the client and server reside on the same IP subnet.
What kind of switch do you have - it is managed, or unmanaged? Does it have multicast support explicitly disabled? Does it also explicitly disable the use of broadcast traffic on the local IP subnet?