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@xxxxxxxxxxxx
[mailto:linux5250-bounces@xxxxxxxxxxxx] 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 :)
midrange.com
