Sniffer 4.7 Symptoms ACK TOO LONG 1

[JoeVac]

I did capture with Sniffer 4.7 on a 10 user Network.
2-3 People on the Network are having problems getting booted out of an application and the data keeps getting corrupt (Time MATTERs - a legal database)

When using Sniffer the Capture has about 500 ACK TOO LONG
messages
port 1367-139
Ack Delta Time 153-200 ms
Maximum Ack Time 136ms

I was talking to Sniffer experts at NAI and nobody could tell me if this could be the source of the problems and what the resolution was..

I am going for 5 Days of Sniffer Training in Aug but I;m leary about getting detailed packet level information and not knowing where to go from there..

All the Machines are Windows 2000 and they are not running a dedicated server yet. Which is the Next Step

 

[rwullems]

The ack time is calculated by sniffer during the compete TCP session. There is a lot of information to be found about that in the Sniffer TCP/IP course.

But regarding to your problem, if you don't see many retransmissions, the akc too long sohlud not be a big problem. If a TCP timer times out, the result shoud be retransmission of the packet (or until the packet) that isn't acked.

So if you don't see many retransmissions, this menas that the packets did arrive, a little later then the response time that sniffer calculated, but they did get there.

About your courses, i teached them myself, and i think there is also a good book out there that can help you. The ISBN is : 1931836574

And a good recourse of books and even example trace files is

http://www.packet-level.com.

regards,
Robert

Robert Wullems
Network Specialist
SCP/SCE/SCM/CNX/MCP/MCSA/Network+
***************************************
If you can Sniff it, you can solve it!
***************************************

 

[wybnormal]

One of the more interesting things I saw with ACKs was a custom application problem. The wireless scanner would send a packet with the scanned data to the server. It would wait a certain amount of time to resend the data if it did not get the ack in time. The server was slow so the scanner would send the packet with the data a second time over a different port then it would get the orginally expected ACK. Then it got the ack on the new port.. this double send/ack would go on a few minutes then bomb the server. It took the client months to figure this out and even then they did not get it till I got there with my sniffer and took a trace apart, packet by packet. It was a alot of fun at the time

MikeS

Find me at

http://www.packetattack.com

"Take advantage of the enemy's unreadiness, make your way by unexpected routes, and attack unguarded spots."
Sun Tzu