Understanding packet capture dumps

I am trying to debug a communications problem for a remote site.
I have the w32 build of ethereal loaded and running on my workstation.
Capturing is no problem. I have even figured out how to filter for what I am looking for.

The Problem: I don't have much experience interpreting the information within a frame. Anyone have any good links for quick learning...or even a good book that isn't too terribly complex.

Thanks

 

Thats not usually something you can just pick up on the quick out of the book. You are analyzing a stream of data for deviations. If you arent familiar with the standard behavior, recognizing the deviation can be troublesome. Each protocol is going to have its own set of references, so we need more information before i can shoot you links.

I'd recommend you try to collect another trace of the same operation working successfully and look for the delta.

If you want to describe what problem your analyzing, maybe we can give u some pointers on what to look/filter for.

 

What I am trying to see:
I was hoping to undertand why the login process seems to be stalling.

Explanation:

The application I am trying to trouble shoot works for several other clients of ours EXCEPT one location, site XYZ.

At site XYZ we have a linux application server locally hosting a management system in a docotors office. On a separate computer is a "gateway" application which creates a secure tunnel to a 3-rd party service provider.

Here at our office we also have a "gateway" application which creates a secure tunnel to the same 3-rd party service provider. When our computer connects to the service provider, a virtual tunnel between our office and the remote office XYZ is initiated. At this point everything is working.

The application hosted at the client site is accessible from a front-end terminal emulator in GUI mode.

Office->>GW-->R-->internet-->>3-rd-->>internet-->>R-->>GW-->>Linux

where:
Office: is our Office
GW: gateway appl
R: is border routers
3-rd :is the service provider
Linux: management system

As I said, initial connectivity is made from out GW to the service provider.
Connectivity from the Remote site GW to the service provider is confirmed.
Initial connectivity (virtually) from our GW to the Remote GW is confirmed.

However, from the time the initial connectivity is made until the GUI login screen appears, takes up to five minutes. Reviewing the dump file shows a period of time (5 mintues) where very little data is passed through the tunnel. Very little meaning 8 bytes sent received twice.

When the login screen fianlly does comes down, the time between the sending of this data to populating the screen is very fast.

While I agree that mastering or at least understanding the "guts" of a packet can be daunting, I was hoping to find some explanation, even if it is basic.

 

One more thing.

After capturing some data simply while going to a website on my pc, the dump file has a series of:
[ACK]
[FIN, ACK]
[ACK]
[SYN]

From what I undertand, this is normal.

Now from the other dump file from the problem I am troubleshooting
[PSH, ACK]
[PSH, ACK]
[ACK]
[ACK]

 

Hmm. Well, you are going to need to identify the protocol being used to connect. Sounds like some VNC/TermServ sort of app, so ill assume its going to be TCP to a specific port.
You WILL need a good trace of it working to proceed.

You want to compare the logon process to see at what phase its stalling. Does it SYNACKACK, does the intial protocol handshake succeed? Does it send any data? Where does the traffic delta from the knowngood trace?

Office->>GW-->R-->internet-->>3-rd-->>internet-->>R-->>GW-->>Linux

You will need a simultanious trace, taken both at the Office->>GW and the GW->>Linux locations. You need to compare traffic and see if packets that go in, come out in a reasonable time on the far side. With this mystery Gateway thingy, there could be a delay in it establishing the connection between the two, rather than a delay for the app itself.


This could get quite nasty, depending on how abstracted the GW protocols are.

 

If you want a book that is excellent for giving you the information to delve into network packets, I would highly recommend O'Reilly's Internet Core Protocols: The Definitive Guide. Unfortunately my copy is at work at the moment.....

The SYN, ACK and FIN flags are used to set up and close a TCP connection. The communication should go:

SYN=1, ACK=0 - Open Connection
SYN=1, ACK=1 - Acknowledge connection open
SYN=0, ACK=1 - Data packet
SYN=0, ACK=1 - Data packet
SYN=0, ACK=1 - Data packet - etc.

The communication should end with a FIN=1

I am not familiar with PSH flag. The book I do have here suggests it is used to buffer data. I don't think it's presence is necessarily a problem, but am not sure.

 

This is payload for the application. the PSH is the Push Bit. It controls how the data is presented to the application, and is application specific as to its contents and function.

So are you saying you see this?

Code:

Office -> Linux     PSH,ACK  SEQ:50000023
Office -> Linux     PSH,ACK  SEQ:50000090
Linux -> Office     ACK 500000023
Linux -> Office     ACK 500000090

If so, then your app sent application specific traffic, which was received by the linux machine, but didnt respond on the APPLICATION layer (the app didnt do anything with it, but the data got there ok). This is a big black box without understanding the code of the app to know what it expected.

 

Thanks for the feedback.

ReggieB..took your advice, the book is in the mail. Amazon had a much better price though.

JoeHobart...Thanks for some troubleshooting ideas. We moved the receiving gateway at the remote site off one pc and onto another pc. This appears to have been the problem. Our access into the remote server is now working. Won't know for sure what the problem was until I get the first box back for analysis.

TonyT...Thanks as well. We were not actually using a *nix vpn connection. The application was a third party app which works similiar to a vpn client, running on a windows box...connecting to a Linux server. Confusing I know ! This wasn't my design for remote access.

Bottom line... it's working now

Don