All StayLinked clients record a client log, but the StayLinked server can also be configured to record additional log files for each session. These server-side session-specific files are stored in the server’s logs subdirectory and include the IP address of the related device as part of the file name. An example of a file name would be StayLinkedHandler.192.168.12.142.log.
When gathering client files, the StayLinked Administrator will store them in the files subdirectory. Log files gathered from the server are written to the Administrator’s local logs subdirectory.
Client
Default state: Enabled as staylink.log
Maximum size: 512KB with optional client settings to adjust size.
Cleanup: 512KB or device cold reset
History: None
The StayLinked client’s job is to reliably display screen updates and submit user inputs to the server in the order there are received. The client log shows the device’s point of view for communication. It records startup and connection details as well as interruptions in the network. More information on communication interruptions can be found in the Client-Server Communications Guide.
Stop and error events in the client are also recorded here, but application errors are not recorded. Applications run on the host, not as part of the StayLinked client which simply paints whatever the server sends out to the device screen.
Log events are recorded as [i] information, [e] error, or [d] debug. Debug events should only appear when enhanced/verbose logging is enabled. Errors are uncommon, but may help identify sources when issues are encountered. The informational events range from standard messages and confirmations to entries about network and connectivity status.
The following are examples of important client log file contents.
During startup, dozens of general client and device details are recorded:Date Time:[i] *** StayLinked v12.1.0(130) [Feb 19 2016] ***
Date Time:[i] device_type=MC9190C_E5
Date Time:[i] espcontrol version=10.0.0(116)
Date Time:[i] ip addr: 10.10.225.187
Once a connection is initiated, the client logs the connection request:Date Time:[i] ------- host connect -------
Date Time:[i] connect: h=192.168.100.63, p=3006
A session ID of 00000 is a request for a new session. A client recovering an existing session will request a specific session ID:Date Time:[i] session-requested=513EA
Network interruptions are an important part of the client log:
[Out of Range]Date Time:[i] <- oor_beg
Date Time:[i] <- oor_max - AP=[00:A0:F8:61:D7:D2]
Date Time:[i] <- oor_abt
Date Time:[i] <- oor_end
[Linking]Date Time:[i] <- oos_beg
Date Time:[i] <- oos_max - AP=[00:08:A2:01:64:00]
Date Time:[i] <- oos_abt
Date Time:[i] <- oos_end
Out of Range events are recorded when the device operating system reports that the radio is not associated to network. Linking events are recorded when packets are not returning in a timely manner. Each event is recorded as a begin, displaying a character in the upper right corner of the screen. If the issue continues, the log will record a ‘max’ which means the user is being presented with a retry counter. The event will ‘end’ when the network access is returned or when the user presses a key to cancel, recorded as an ‘abort’.
More details on these events can be found in the technical references for Client-Server Communications and Host Timeout.
Disconnections from a session are recorded to the log with a disconnect code:Date Time:[i] client disconnect, code=110
Date Time:[i] host disconnect, code=110
The following is a list of the possible disconnect codes:
| CLIENT_DIS_SERVICE | 100 |
| CLIENT_DIS_OOR_ABORT | 110 |
| CLIENT_DIS_OOS_ABORT | 120 |
| CLIENT_DIS_NETM_ABORT | 130 |
| CLIENT_DIS_SCRIPT | 140 |
| CLIENT_DIS_FROM_USER | 150 |
| CLIENT_DIS_SWITCH_SESS | 160 |
| CLIENT_DIS_FROM_ADMIN | 170 |
| CLIENT_DIS_CLIENT_EXIT | 180 |
| CLIENT_DIS_SESSION_ENDED | 190 |
| CLIENT_DIS_SESSION_NOT_FOUND | 195 |
| CLIENT_DIS_TRANSFER_SESS | 200 |
| CLIENT_DIS_SERVERS_LIST | 210 |
| CLIENT_DIS_RECONNECT | 220 |
Session
Default state: Disabled, enabled in server settings for session, handler and socket logging.
Maximum size: Per Server Settings
Cleanup: Deleted and restarted after reaching max size
History: None (see section
1.4 for snapshot)
The session log records transactions between the StayLinked server and telnet host. Each outbound transaction submitted to the telnet host is recorded. Telnet host responses are noted, but the log file does not include the contents of those return presentation events. The session log is an excellent source to determine how long the host application is taking to respond to user inputs. Timestamps can help review this file for each input and the corresponding response or host event.
Viewing the host responses is best accomplished using the handler or proxy log files. Minor adjustments have been made to the following example for readability and demonstration.
The following are examples of important session log file contents.
Typical events include a user input and host reaction:Date Time - getDeviceInput() KEY (#9) keyCode = '720000', thisKey = '[pf3]'
Date Time - processSession() is sending key: '[pf3]' to host.
Date Time - OIANotifyEvent: Event being processed now.
Date Time - refreshOIALine: running...
Date Time - refreshOIALine: 5250 Session is Inhibited.
Date Time - refreshOIALine: completed.
Date Time - -------------------------------------------
Date Time - OIANotifyEvent: Event being processed now.
Date Time - Processing presentation space update event.
Date Time - PSNotifyEvent: Calling displayCurrentScreen() for full screen update
Date Time - displayCurrentScreen: From 1 to 1920, Size 1921, Cursor Pos 12,1
Date Time - displayCurrentScreen: Processing Standard Full Screen Update
Date Time - sendEntireScreenToDevice: running...
Date Time - displayCurrentScreen: Completed.
Date Time - refreshOIALine: running...
Date Time - refreshOIALine: 5250 Session is not Inhibited.
Date Time - refreshOIALine: completed.
In this example, you can use the user pressed the function 3 key, which set caused the host to paint new information to the screen. This presentation events shows the amount of data painted to the screen and current cursor position. The timestamps of this log can help demonstrate the timing between input and response, since the input received at the server no longer includes network delays.
Different input types can appear in this log:Date Time - getDeviceInput() KEY (#7) keyCode = '0D0D00', thisKey = '[enter]'
Date Time - getDeviceInput() SCAN (#27) barType = 0, scanData = 'Q02748277'
Key codes are referenced in the StayLinked keyboard map. Barcodes show the barcode symbology type and barcode contents. While the handler log records the data coming from the client, this log shows the data after StayLinked processing. This means that any barcode adjustments by StayLinked will show in this log, but not in the handler log. The following is a list of the different barcode symbology types recognized by StayLinked in the Session log (in the Handler log they will be hex):
| 1D Symbologies | 2D Symbologies | Other Types |
| 8 = "MSI/Plessey" | 128 = "PDF417" | 252 = "Scale Data" |
| 9 = "Alpha Plessey" | 129 = "MicroPDF417" | 253 = "Mag Stripe" |
| 10 = "ISBN Plessey" | 130 = "MacroPDF417" | 254 = "RFID" |
| 11 = "Pure Plessey" | 131 = "MacroMicroPDF417" | 0 = "Unknown/Unsupported" |
| 12 = "Sains. Plessey" | 132 = "MaxiCode" | |
| 15 = "UCC/EAN 128" | 133 = "Data Matrix" | |
| 16 = "UPC A/E" | 134 = "QR Code" | |
| 17 = "EAN 8/13" | 135 = "Micro QR Code" | |
| 18 = "UPC/EAN" | 136 = "Aztec Code" | |
| 32 = "Codabar" | 137 = "Multi-Dimensional" | |
| 40 = "Code 3 of 9" | 138 = "Code 32" | |
| 41 = "Trioptic 39" | 139 = "Imager" | |
| 48 = "All Code 2 of 5" | 140= "Signature" | |
| 49 = "Discrete 2 of 5" | 141 = "Web Code" | |
| 50 = "Inter. 2 of 5" | 142 = "Cue Code" | |
| 51 = "Indus. 2 of 5" | 143 = "Composite AB" | |
| 52 = "Matrix 2 of 5" | 144 = "Composite C" | |
| 53 = "IATA 2 of 5" | 145 = "TLC 39" | |
| 56 = "Code 11" | 146 = "USPost Net" | |
| 64 = "Code 128" | 147 = "US Planet" | |
| 76 = "RSS-14" | 148 = "UK Postal" | |
| 77 = "RSS-14 Limited" | 149 = "Japan Postal" | |
| 78 = "RSS-14 Expanded" | 150 = "Australian Postal" | |
| 80 = "Code 93" | 151 = "Dutch Postal" | |
| 82 = "Code 49" | 152 = "Canada Postal" | |
| 88 = "AMES Code" | 153 = "Chinese 2 of 5" | |
| 154 = "Bookland" | ||
| 155 = "Coupon" | ||
| 156 = "Korean 3 of 5" | ||
| 157 = "US4 State" | ||
| 158 = "US4 State FICS" |
Some applications paint screen events even when the user is inactive:Date Time - Processing presentation space update event.
Date Time - PSNotifyEvent: Calling displayCurrentScreen() for multi-line update
Date Time - displayCurrentScreen: From 1121 to 1280, Size 1921, Cursor Pos 16,12
Date Time - sendScreenLinesToDevice: running...
Date Time - displayCurrentScreen: Completed.
Date Time - -------------------------------------------
Date Time - Processing presentation space update event.
Date Time - PSNotifyEvent: Calling displayCurrentScreen() for full screen update
Date Time - displayCurrentScreen: From 1 to 1920, Size 1921, Cursor Pos 16,12
Date Time - displayCurrentScreen: Detected Empty Screen Update
Date Time - displayCurrentScreen: Completed.
Date Time - -------------------------------------------
Date Time - Processing presentation space update event.
Date Time - PSNotifyEvent: Calling displayCurrentScreen() for full screen update
Date Time - displayCurrentScreen: From 1 to 1920, Size 1921, Cursor Pos 16,12
Date Time - displayCurrentScreen: Processing post Empty Screen Full Screen Update
Date Time - sendEntireScreenToDevice: running...
Date Time - displayCurrentScreen: Completed.
In this example, the telnet host is sending repeated presentation events to the device. This example has a host that repaints the telnet screen every second. This unnecessary traffic significantly increases the amount of data passed between the telnet client and host. This behavior is most often seen in applications with a clock or timer that updates on a regular interval in the emulation space.
Application screens drive screen recognition features, which are recorded in the session log:Date Time - recognitionProcess: no recognized screen found
Date Time - recognitionProcess: ***** Recognized screen 'login' out of 13 screens *****
Date Time - recognitionProcess: Screen recognition instance #1, Host Event, Show this = true
Date Time - recognitionProcessHostAPI: Processing Update User Name = 'jmasters'
Handler
Default state: Disabled, enabled in server settings for session, handler and socket logging.
Maximum size: Per Server Settings
Cleanup: Deleted and restarted after reaching max size
History: None (see section
1.4 for snapshot)
Shows the handling of the session by SL, and includes all inbound inputs and outbound presentation events. Since this log is StayLinked Client to StayLinked Server, the inputs will show as they came from the device and will not show any adjustment by the server process.
Minor adjustments have been made to the following example for readability and demonstration. Note that some events have improved logging starting in version 15.1 build 208 of the Server to include additional event recording.
The following are examples of important handler log file contents.
The session and connection information is recorded when a session is started:Date Time **********
Date Time StayLinked Handler Starting Session 66407 for 10.10.225.187
If a fixed port range is configured for your connections, the port and range is recorded:Attempting to open a socket on IP 192.168.100.12 on a UDP port between 5000 and 6000
StayLinked Handler is using socket on IP: 192.168.100.12 Port: 5005
Once the standard handshake completes, the device returns the ‘getdeviceconfig’:Date Time esp_GetDeviceConfig() returns 'AB~001~19~000~MC9190C_E5~14~22~12~01~0130~0000 ~000~002368E6EAFE~640~6007~3~20170406092835~S~WindowsCE ~2~01~3~0~'
More information on the client-server handshake can be found in the Err:Host Timeout and Client-Server Connectivity technical references.
Once the device has been identified, StayLinked processes several advanced features:Date Time SEND: (0006) 'AA~007~14~00~02~0018~Client Settings...~'
Date Time SEND: (0007) 'AA~008~14~00~03~0020~Device Management...~'
Date Time SEND: (000B) 'AA~012~14~00~04~0018~Client Software...~'
Date Time SEND: (000C) 'AA~013~14~00~05~0015~Provisioning...~'
Note the outbound screen update packet sequence numbers in parenthesis. These values are in hexadecimal and are recorded for all inbound and outbound packets. These are how StayLinked guarantees packet delivery and synchronization.
The device is then placed into a device group:Date Time EspLinkDeviceLoader configureDevice Selecting Best Device Group
Typical Input Types
There are five types of user inputs:
Keyboard – On-screen or hardware keyboard, transmits the 6-character key code-Date Time esp_ProcessDeviceInput() - RECV: (seq#) 'AC~343400~Y~'
Scan – Input strings from a scan engine or Android label. NOTE: the second value is the barcode type in hex (e.g. 40 is 0x40, which is decimal 64 or Code 128 in the table above)Date Time esp_ProcessDeviceInput() - RECV: (seq#) 'AD~40~0~11~A2203000104~§~'
Tap – touch screen or mouse input that does not hit an on-screen buttonDate Time esp_ProcessDeviceInput() - RECV: (seq#) 'AG~08~0D~'Voice – Data converted to an input string by Vangard VoiceDate Time esp_ProcessDeviceInput() - RECV: (seq#) 'AI~015~Your Voice Data~'
Mnemonic Command – touch input on a graphical buttonDate Time esp_ProcessDeviceInput() - RECV: (seq#) 'AH~10~nyc[enter]~'
Note the device input string starts with characters that represent the input type following the sequence number of the input by the user in parenthesis. In these examples, AC is a keyboard input which will always include a six-digit key code while AD is a scanned barcode that includes data for the barcode type (in hex) and length. Tap inputs are recorded as AG transactions or AH depending on what was tapped on the device screen.
Outbound transactions to the device screen appear as a screen print. These SEND packets are sequenced for delivery and include information about the position of the update and update contents.Date Time esp_XYPrintC()Date Time SEND: (0039) 'AA~058~28~09~10~0005~ûùø4~09~10~1~'
Inputs without a host reaction are common when the host does not paint screen updates. These can be hidden fields, such as a password or when the host does not echo the input back to the user.
Log Analysis Tool
When a StayLinkedHandler log file is opened in the view, the file menu will include the option to analyze the file for you. This takes the standard file and reformats it into a more easily read version. This analysis log will be stored to the Administrator’s local logs directory as mentioned above. The StayLinked Server does not get a copy of the file since it is generated by the StayLinked Administrator.
The analysis log takes the inputs and reactions from the handler log and formats them into a recreation of the device screens. This usually allows for a simple view of a screen, user input and then the reaction screen.
When the analysis program runs, it reads through the file assuming 24×80 rows and columns until the screen dimensions are found. Once the client screen size if found in the file, screens are formatted knowing the proper display size. If a file does not contain a connection request, it may not be able to format the screen in the proper screen dimensions.
Starting in Server/Administrator version 15.5, any Handler log can be run through the analysis tool as an option from the Logs Menu in the Administrator. This replaces the standalone tool that has been included in the Administrator installation folder. The integrated Administrator analysis tool offers a wider range or features and recognition of events that will not be included in the standalone tool that has been deprecated.
While timestamps are removed from these examples, it should be noted that the timestamps can be an important part of diagnostics efforts. Excessive delays between the user input and host response will directly impact the user experience.
The following is an example of the analysis log file with comments.
The user is presented with a menu:
The user pressed a 6 on the device, generating the key code 363600:Date Time USER PRESSED KEYCODE: 363600 '6'
The host updates the selection field with the user input: Date Time SCREEN UPDATE at Row 12, Col 1, Cursor at Row 12, Col 1 with Length 5, Data 'ûùø6'
The host then paints a new screen based on the menu item:
The user then scans a barcode which is parsed across two fields:
The host responds by entering the data in the fields:
The user presses enter:
The host processes the input and responds with a beep and an error message:
Socket
Default state: Disabled, enabled in server settings for socket logging.
Maximum size: Per Server Settings
Cleanup: Deleted and restarted after reaching max size
History: None (see section
1.4 for snapshot)
Also known as the IP Traffic log, this file shows synchronizations, packet payloads and sequence numbers. While not often required, this log shows the reliability of the Client2Host protocol by detailing each inbound and outbound transaction between the StayLinked Client and Server.
The following is a few examples of socket log contents.
Note the SYNC-OK message, which confirms that the client and server have confirmed that they are on the same sequence numbers and are fully synchronized.
Several abbreviations are used. These represent server and client sequence numbers. For example, Last Observed Client Sequence (LOCS) and Last Observed Server Sequence (LOSS).
Instructional Video: Turn on Session Specific Socket Logging
Proxy
Default state: Disabled, enabled as an emulation property in the telnet host entry.
Maximum size: Per Server Settings
Cleanup: Deleted and restarted after reaching max size
History: None
This file is enabled in the telnet host entry as an emulation property and records untouched telnet client (C) and telnet Server (S) conversation details. These logs are stored in the StayLinked Server’s Logs subdirectory and cannot be accessed through the StayLinked Administrator.
The proxy log can be an important tool when confirming the source of error messages as well as the host processing time between transactions. This file can also help confirm if input adjustments are being made by the telnet host or telnet client.
Proxy logging is best used on standard VT emulation types. 5250, 3270 and secured emulation protocols will not offer the same simple formatting that VT emulations provide. SSH connections may require changing to VT emulation as part of your troubleshooting efforts.
The following is a brief example of proxy log contents.
This raw input and output is best reviewed in an editing tool that can show the hexadecimal values in each transaction. This can help identify escape sequences and control codes used in the conversation.
Share the post "Log Files – Session-Specific Log Files"