unable to establish contact with session

[Migration User]

GhostCast Server 8.3.0.117

Okay, the problem I'm having is with establishing a session in GhostCast. Ghostcast is started and I give it a session name. Then I do a PXE boot on the client and Ghost loads. Then I go (still on the client) to GhostCast and then multicast, directed broadcast, unicast, it makes no difference. No matter what I select it goes for a while and then comes up with an error that says it's unable to establish contact with the session, and to check to make sure Ghost is accepting new clients. If I pause on the selection screen it give me a Class C IP address, which is on the same subnet as the server (windows 2003 RC2). If I ping the client's IP address from the server, I get responses... but it *never* connects to the session. I've tried editing wattcp.cfg and in it, it shows a static IP address for the server, which is correct, and the correct subnet mask. I have tried changing receive modes with no effect.

One of the things on the server; the NIC is a Gigabit NIC (with the latest drivers) and the computer I'm trying to load to is 100Mbit. The switch I'm using which was previously working with an older version of Ghost (but a different server), is an auto-negotiating 1000/100/10 switch. The light will be blue for the server indicating it's a 1Gb port and the light also lights up on the client as green, indicating it is 100MB. When the client attempts to connect both lights blink like they are seeing each other, but always the same error. I would really appreciate anybody who could shine some light on this subject, because I am at a loss.

[Migration User]

Since the client and server can't even start communicating, we need to begin by looking at your network configuration with a packet trace using a tool like Wireshark http://www.wireshark.org

Basically, I'd begin by getting a capture at the server machines end to see how the discovery phase is operating, since you aren't even getting through that part. There are two sets of things that can happen during discovery, the client will first try sending multicast packets to locate the server session and then it can fall back to using WINS (the NetBIOS name service) which will use a WINS server if you have one, or broadcast if you don't.

> I've tried editing wattcp.cfg and in it, it shows a static IP address for the server,

The client uses dynamic discovery methods, so as long as you have a properly configured DHCP setup you should be fine without needing to have a wattcp.cfg file. If you are using one all the time it would be helpful to see it.

> One of the things on the server; the NIC is a Gigabit NIC (with the latest drivers) and the computer I'm trying to load to is 100Mbit

That shouldn't be a problem, just to confirm are the client and server plugged into the same switch?

If you can get some traffic captures, check my profile and you should be able to work out my gmail address if you'd like me to analyse them for you.

[Migration User]

Nigel,
Thanks for your words of wisdom, I had never used a network analysis tool before. I looked at that and it seemed like everything was working like it should, except when it was actually reading the program on the Ghost boot partition.
So here's what happened... We upgraded to a new version of Ghost and it was still reading the old PXE environment for the previous version. We just used Ghost Boot Wizard, and made another environment, one that was compatible with the version on the box, and it works great now. BTW, never did figure out your email address in gmail, but for those wondering, it's not [e-mail] :p

Thanks again,
Gary

[Migration User]

And my question is answered...

[Migration User]

> I had never used a network analysis tool before.

Wireshark is a fantastic debugging tool, no two ways about it. For even quite routine network tasks it's a boon being able to just look at what's out on the wire.

Good work on figuring out the problem by the way, that's a nice catch. Having the wrong version sitting in PXE wouldn't have occurred to me.

> BTW, never did figure out your email address in gmail

My google pages profile should be visible in my board profile here; extra hint: my name is basically unique on the internet.

[Migration User]

I'm hoping Nigel Bree can help me out because I am having exactly the same problem in that I am trying to estblish a session, the client finds the GhostCast Server IP address and the client gets an IP address that I can ping. But it keeps telling me it cannot establish the session. I have even follwoed a step-by-step guide and still no joy. This is driving me in sane here so if Nigel is out there please help me sort this out. I have used Ethereal to trace packets hitting the GC Server and it all looks fine (not sure what I'm looking for though). I can see the GC Server talking to the client IP over UDP and thats about it.

[Migration User]

Always happy to help, although I'm a tad busy right now.

For reference, here's an example trace just showing the connection setup to pull an image (I cancelled out in the Ghost client before actually moving any image data). This should show you what to expect from the traces you have, and how to follow through what you captured.


Here's the packet capture: http://nigel.bree.googlepages.com/ghost_session_start.cap
Here's a text dump of it: http://nigel.bree.googlepages.com/ghost_session_start.txt
Here's a really verbose text dump of it: http://nigel.bree.googlepages.com/ghost_session_start_detailed.txt


No. Time Source Destination Protocol Info
1 0.000000 192.168.92.130 224.77.0.0 UDP Source port: 1066 Destination port: 6666

This first packet is the client machine asking to find the server for a specific session. 224.77.0.0 is a multicast address, and all the GhostCast servers register for packets on that multicast address. Port 1066 is just an arbitrary address chosen by the TCP/IP stack; port 6666 is the discovery protocol's UDP port address that the GhostCast server listens on.

0020 00 00 04 2a 1a 0a 01 1d 12 72 65 78 61 6d 70 6c ...*.....rexampl
0030 65 00 cc cc cc cc cc cc cc cc cc cc cc cc cc cc e...............

This data is the session name that the client is looking to find a server for - "example" - terminated by a NULL, the data after that is mostly filler - the last 20 bytes of the packet is room for flags and stuff that is mostly not used.


No. Time Source Destination Protocol Info
2 0.000165 Vmware_c0:00:01 Broadcast ARP Who has 192.168.92.130? Tell 192.168.92.1

This is the server machine looking for the address of the client, so it can send a reply to the session query.


No. Time Source Destination Protocol Info
3 0.001244 Vmware_32:52:42 Vmware_c0:00:01 ARP 192.168.92.130 is at 00:0c:29:32:52:42

The client machine responds with its Ethernet address, so the server can talk to it.


No. Time Source Destination Protocol Info
4 0.001261 192.168.92.1 192.168.92.130 UDP Source port: 6666 Destination port: 1066

And here the GhostCast server's actually response to the session query.

0020 5c 82 1a 0a 04 2a 01 0c 54 3f 65 78 61 6d 70 6c \....*..T?exampl
0030 65 00 d8 fd df 02 50 fb df 02 90 65 62 7d d8 fd e.....P....eb}..

This data for the response is mostly the same as the query; the session name, null-terminated, plus a lot of filler (which strictly speaking should be set to zeroes instead of left as junk).

0120 2e 00 c0 0e 00 00 ff ff ff ff 04 82 04 83 ..............

The last 4 bytes are interesting, though. They contain the UDP and TCP ports on which the client is to call back the server for session-specific data. Port 6666 is just for discovery, the UDP port (0x482 hex) is for connecting up the bulk data transfer once the transmission starts, the TCP port (0x483 hex) is for the session setup.


No. Time Source Destination Protocol Info
5 0.017676 192.168.92.130 192.168.92.1 TCP 1067 > 1155 Seq=0 Len=0 MSS=1460

And here, the client dutifully calls back to the indicated TCP port to begin the process of finding out about the session. There are a couple packets of TCP handshake, then...


No. Time Source Destination Protocol Info
8 0.021261 192.168.92.130 192.168.92.1 GHOSTDEV Version Request

Now, you won't see this because you don't have an Ethereal plugin to dismantle the protocol bytes (although we do hope to make this available to customers at some point). All of this is being done over the TCP connection that was just set up. The first part of the TCP phase is a version check...


No. Time Source Destination Protocol Info
9 0.032891 192.168.92.1 192.168.92.130 GHOSTDEV Version Reply

To which the server responds. Now, this version number is a protocol version only, and we try hard not to change it except as necessary (to avoid forcing people to rebuild every single boot disk they have when we put out an update).


No. Time Source Destination Protocol Info
10 0.042737 192.168.92.130 192.168.92.1 GHOSTDEV Transfer Options Request

In this packet the client asks the GhostCast server how the session is configured...


No. Time Source Destination Protocol Info
11 0.042817 192.168.92.1 192.168.92.130 GHOSTDEV Transfer Option Request "-clone,mode=create,dst=@mcexample"

And the server gives back what you should be able to recognise as a command-line string; here it is in the raw packet data:

0040 2d 63 6c 6f 6e 65 2c 6d 6f 64 65 3d 63 72 65 61 -clone,mode=crea
0050 74 65 2c 64 73 74 3d 40 6d 63 65 78 61 6d 70 6c te,dst=@mcexampl
0060 65 00 00 00 4d d0 61 7d da 1c 4e 7d 01 00 00 00 e...M.a}..N}....

Basically, for an image pull, this is enough to get you to the business end of the cloning process. If I had actually proceeded, what we'd see next is the process of moving from a TCP connection to a UDP connection to do the transfer.

For multicast image deploys, that's a more complex process, with many more options. However, if you're having the session connection process fail before it gets there, this should be a suffcient example of what to look for.

Basically, check to see that the GhostCast server is replying to the connection request, check what ports it tells the client to call it back on, and look for the TCP connection back to it. If some part of that process is missing, we should probably start there.

Something that may help is to use the 32-bit version of Ghost, Ghost32, running under Windows. If you try and start a session using that, you can have WireShark running on that machine to get a clients-eye view of what is happening on the network. Often it's useful to be able to compare what is being sent and received at each end, so you can see if your network is not passing some traffic (for instance, if you have a switch that blocks multicast traffic).