Re: Using tn5250

Hi Scott.  Thank you for your detailed answer.

To answer your first question - "not well".  We are trying to help a
client who is seeing a lot of X-WAIT issues on some clients connected
over a wireless connection.  This can often appear for several minutes
which interrupts the work flow.  We have installed the wireless
infrastructure (not the clients or the AS400) and need to rule it out
but are unable to do so at the moment without better seeing what traffic
is flowing.

Your information about the flow of information in 5250/AS400 sessions is
useful and informative.  I'll take a look through it and try and
manipulate the Wireshark information.  Maybe for my purposes I can get
away with just using the incoming traffic (from the AS400).

As an aside - is there anything that you can tell me about "X-WAIT" -
the terminal displays an X followed by the word WAIT.  I understand that
this is in response to a command from the AS400 but I don't fully
understand the flow of traffic around that point.

Thanks again.

Best regards

Robin
-----Original Message-----
From: linux5250-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]
[mailto:linux5250-bounces-Zwy7GipZuJhWk0Htik3J/[email protected]] On Behalf Of Scott Klement
Sent: 09 February 2010 07:10
To: Linux 5250 Development Project
Subject: Re: [LINUX5250] Using tn5250

Hello Robin,

> But I'd like to reply sessions that I have captured at the gateway of
> the network using Wireshark.

Hmmmm...  how well do you know the 5250 and telnet protocols?

The basic concept is that tn5250 gets input from two sources.  The 
network (as a series of "records") and the keyboard.  In order for us to

reproduce everything happening in the 5250 code (when someone finds a 
bug and we have to trouble shoot it) we needed a way to reproduce the 
problem locally.  The easiest way was to record all of the inputs to a 
file -- then the user could send us the file, and we could "replay" (as 
you put it) the session by making tn5250 read the data from the file 
instead of getting it from the keyboard and network.  That way, we can 
see the exact inputs our user was getting, and we can reproduce their 
problem exactly -- thus making it much easier to chase down and fix the
bug.

Re-creating this from a Wireshark log won't be nearly as easy because of

the way the 5250 data stream works with keyboard events.  You could 
quite easily reproduce the data sent from the host (i.e. the "as/400") 
to your PC.  No problem with that at all.

However, figuring out the appropriate keyboard codes to simulate the 
data going from the user to the '400 would not be so easy.

When you press MOST keys in a 5250 session, they are NOT transmitted 
over the network to the host.  Instead, they cause the emulator to print

a character to the screen, or to move the cursor somewhere.  Only when 
an AID-generating key (like the ENTER key or an F-key) is pressed does 
anything get sent to the host, and what is sent is the contents of all 
of the fields on the screen, in the state that they were in when the 
AID-generating key was pressed.  So no cursor movement, et al, is ever 
sent to the host.

What TN5250 reads from it's debug logs, however, is the actual 
characters pressed on the keyboard.  NOT the data that's eventually 
translated to the '400!  So to reproduce the trace file from Wireshark, 
  (which is the raw 5250 data sent to the 400) you'd have to interpolate

what keyboard presses were necessary to put the screen into the 
appropriate state in order to put that data on the screen in the 
appropriate places.

That's not so easy.  I suppose it's possible, though.

The format of the trace file isn't too tough to understand if you're 
familiar with the idea of "records" in a telnet session.  First of all, 
a lot of the stuff in the trace file is just info to help us developers 
with the debugging, and is NOT used to replay the session.

Each line in the trace file ends with the Unix newline (0x0a) character.

  This is what distinguishes one line from another in the trace file.

Each line used to replay a session MUST begin with the @ symbol followed

by a keyword that identifies what is being replayed.  Any lines that do 
not start with the @ symbol are assumed to be diagnostic notes for the 
developers -- and are ignored when replaying the session.

Currently there are 3 keywords used by the replay feature. they are 
'record', 'eor' and 'key.  So lines used by the replay feature always 
start with one of these:

@record
@eor
@key

The @record and @eor keywords are used to log the data that's sent over 
the network from the telnet server to the tn5250 client, *not* including

Telnet option negotiations.

When Telnet options are negotiated, a tn5250 client must negotiate the 
telnet end-of-record option.  So a "record" that's read over the network

is delimited by this EOR character.  TN5250 will read data from the 
socket and put it into a buffer until it receives this EOR.  Once EOR is

received, the whole record is dumped to the trace file as follows:

@record +0000 045612a0 00000400 00030440 04110018  ....  .  .. .. .
@record +0010 01070000 00180000 00110116 22404040  ..   .   ....
@record +0020 40404040 40404040 4040e289 879540d6            Sign O
@record +0030 95020137 40201102 2f20e2a8 a2a38594  n... .....System
... more data here ...
@record +0420 02164a00 20111827 22404dc3 5d40c3d6  ... ..... (C) CO
@record +0430 d7e8d9c9 c7c8e340 c9c2d440 c3d6d9d7  PYRIGHT IBM CORP
@record +0440 4b40f1f9 f8f06b40 f2f0f0f5 4b404040  . 1980, 2005.
@record +0450 40200452 0000                         ...
@eor

Since each buffer can potentially be large, TN5250 logs it to the trace 
file in 16-byte chunks.   So the first 16 bytes are printed in hex 
format, and then in character format.  (with unprintable characters 
replaced by the . symbol)

So each @record line starts with an offset into the record buffer +0000 
means the start of the record, +0010 means 16 bytes from the start, 
+0420 means 1056 bytes from the start, etc.  (because hex 420 = decimal 
1056)

After the offset, is 4 groupings of 4 bytes each, in hex, to make up the

16 bytes.  This is followed by the character representations of the same

bytes, with unprintable characters printed as . characters

So in my example, I had this:

@record +0000 045612a0 00000400 00030440 04110018  ....  .  .. .. .

The +0000 means it's the start of the record buffer.  The first 4 bytes 
of the buffer are 045612a0 in hex.  (0x04 is the first byte, 0x56 is the

second, and so forth) 00000400 are the next 4 bytes, etc.

None of the bytes in this line happen to be printable, so you just see a

sseries of dots at the end.

However, here's another example:

@record +0430 d7e8d9c9 c7c8e340 c9c2d440 c3d6d9d7  PYRIGHT IBM CORP

These 16 bytes belong 1072 (or hex 430) bytes from the start of the 
record buffer.  It's printed as 4 groupings of 4 bytes.  the character 
values of those bytes happen to spell 'PYRIGHT IBM CORP' which are 
printable characters in this case.

TN5250 dumps the entire record buffer, in sequence from the start of the

record buffer to the end by listing as many @record lines as it needs to

represent the whole buffer.

Once the entire record buffer has been included, the @eor line is 
written to tell the replay function that it has reached the end of a 
record of data.

The only other entry needed for replay is the @key entries.

@key entries look like this:

@key 107
@key 108
@key 101
@key 109
@key 115
@key 99
@key 111
@key 116
@key 9

Each @key line is simply an ASCII code (in decimal) that was pressed at 
the keyboard.  so in ASCII 107 is lowercase letter k, 108 is lowercase 
letter l, etc.  the 9 at the end is the tab key moving to the next field

of the screen.  (in this case I was typing my userid, which is 
"klemscot", followed by the tab key to move to the password line.)

Reproducing these @key lines from a Wireshark log will be the toughest 
part of your assignment.

But if you can write these @record, @eor and @key lines to a text file 
in the appropriate sequence, TN5250 should be able to replay them with:

    tn5250 debug:/path/to/myfile.txt

For more details, I recommend checking out the source code itself.  It's

been many years since I last reviewed how this debug stuff works, but 
hopefully I remembered it well enough to get you started :)
-- 

-- 
This is the Linux 5250 Development Project (LINUX5250) mailing list
To post a message email: LINUX5250-Zwy7GipZuJhWk0Htik3J/[email protected]
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/linux5250
or email: LINUX5250-request-Zwy7GipZuJhWk0Htik3J/[email protected]
Before posting, please take a moment to review the archives
at http://archive.midrange.com/linux5250.