Re: Getting debug displays from sniffer traces

On Mon, 24 Jun 2002, Jonathan S. Polacheck wrote:
>
> We often take protocol analyzer traces to diagnose performance problems
> related to 5250 sessions.  The problems seem most likely related to issues
> at the AS/400 and/or the client system rather than any kind of network
> latency, but we still need the trace to prove which system is hanging and
> when.  We, as network administrators, do not have detailed knowledge of all
> the apps that are being access through 5250.  If we could re-create a 5250
> screen and see it's contents at the time we observed the large delta time
> in the trace, we would have a better idea of what the user was doing and
> what applications were being accessed.
>
> We usually use Network General Distributed Sniffer Servers to take traces.
> These traces can be converted to tcpdump format and view through Ethereal.
> Then, the data payloads could be extracted from a given TCP (Telnet) flow.
> The display is tantalizingly like getting a view of the screen output (see
> attachment 5250.txt).  But not really like looking at the actual screen
> display, and no indication of what packet relates to what screen display

You can't send attachments over the mailing list, sorry.  It simply strips
them out.  Therefore, I haven't seen your attachment, and I'm not quite
sure what you mean.

>
> Any suggestions?

Kinda sounds like you're seeing the raw 5250 protocol.  Yes?   What do you
define as being a "new screen", then?  When the system requests input from
the terminal?

>
> BTW, I installed your tn5250 on a Win2k system and tried to use the "debug"
> option to view a trace. I got an error and, supposedly, generated a log
> file.  If I knew where the log file  was created (it doe's not seem to be
> in C:\Program Files\TN5250>) I would send it.
>

I don't have a Win2k system to diagnose this on.