The StayLinked Server is the key component in the StayLinked Host-based Telnet solution. As a telnet client, the StayLinked Server performs all transactions between itself and the telnet server. It also communicates input (keys, scans and touchscreen) and output (screen updates) to the remote device. StayLinked is designed to provide as much information as possible when there is any interruption or error. When the devices can freely communicate with the server, the server will present these messages in the form of eSPXXXX error codes. When the device cannot freely communicate with the server, it will display an Exclamation or Asterisk in the upper right of the screen, followed by [Linking] or [Out of Range] messages with a retry counter. This document aims to describe these events and possible troubleshooting steps. Some amount of these messages should be expected in nearly every wireless network, but troubleshooting may be necessary if these messages are appearing enough that your users are frequently interrupted.
All or Nothing
When all of your devices display these messages at the same time, following a predictable pattern, or at a certain time of the day, please contact StayLinked support for troubleshooting assistance. These simultaneous messages could be related to the performance tuning or operation of the StayLinked Server. If the issue is specific to a network segment, device model or specific location, the issue is almost invariably related to the network infrastructure. The StayLinked Server does not contain any options that can provide priority to any session over other sessions.
The Handshake
When a gun tries to connect to the server it’s assigned a dedicated UDP port for that session. New sessions are assigned a new UDP port, while devices connecting to an existing session are redirected to the port for that session. One of the configuration options in the StayLinked Server is to use a ‘Fixed Port Range’. This fixed port range allows the Server to request a UDP port within the range, instead of allowing the server operating system to supply any random port. This is most often used in conjunction with firewall rules that secure different network segments.
Blacklisted Ports
You many notice in some of the StayLinked logging that ports will be ‘Blacklisted’. In this instance, Blacklist is not a negative term.
When a handshake for a new session fails, the server will ‘blacklist’ that port number, just in case it was a problem using that specific port over the network. If you have more ports in your ‘fixed port range’ than guns, you may never need that particular port again. If the range runs out of ports to use, the server will clear the ‘non-preferred’ list and try using them all again.
In short, we ask the server operating system for a port. If the handshake fails, we skip that port again on subsequent connections unless it’s needed.
Handshakes fail all the time on a typical network. This feature was put in place in case some network appliance uses a particular port that would prevent it from working. In previous server versions, we would pick the next sequential port in a fixed port range. If that port failed because of some random network appliance, the clients would almost never be able to get connections working beyond that port number.
We offer another technical reference document for the “Err:Host Timeout!” message if these handshakes are failing too frequently.
Connectionless
Communications between the Client and Server are connectionless. This means that the device will continue to display the last session screen until the user provides input or the server sends new display information. The Client and Server will not communicate if there are no transactions for a period of time. This is accomplished by operating under the UDP network protocol, with reliability added by the StayLinked Client2Host Protocol.
After the handshake with the server completes, devices will show the emulation screen presented by the telnet host. The client and server will confirm that they are synchronized after each transaction. As the user provides input, the client will queue these transactions in order and deliver them to the server as fast as the network allows. The client then clears them from the queue once the server has acknowledged receipt of that transaction.
Radio Power Management
Some devices have the option for aggressive radio power management. These PSP and Fast PSP power management protocols can have a direct impact on network performance, especially for small, fast packets like those used by StayLinked. We typically recommend that the device power management settings are used to conserve battery, and not the radio power management features. The device isn’t very useful without the radio, so you might as well suspend the whole device if you want to save power. We have seen great success in reducing network interruptions by setting the radio to CAM mode in the radio profile power save options.
Quality of Service (QoS)
StayLinked clients communicate with the StayLinked server using the UDP network protocol. StayLinked enhances the transactions for reliable delivery. Many network appliances can offer packet prioritization based on the protocols in use. Since UDP is commonly used in streaming media, it can sometimes be the target of these QoS features. Allowing QoS to downgrade or restrict UDP packets used by StayLinked can negatively impact performance and result in a poor user experience. Be sure to disable these QoS services or configure exceptions for your StayLinked transactions for the best performance.
Asterisk vs. Exclamation
Most interruptions in communication should be invisible to the user. These interruptions will occur and resolve between inactivity or within a fast enough time frame that the users are none the wiser. If the interruption persists for two seconds, a character will appear in the upper right corner of the display. This character is a precursor to the one of the messages below.
The Asterisk is a prelude to the [Linking] screen. This means that there has not been a successful synchronization between the client and server for at least four seconds. If the state persists, the screen is replaced with [Linking] after a total of 10 seconds.
The Exclamation mark is a precursor to the [Out of Range] screen. This means that the device operating system is currently reporting that it is not associated to an access point for at least one second. If this state persists, it will be replaced with the [Out of Range] screen after a total of five seconds.
Linking
During the [Linking] screen, the retry counter represents each attempt to synchronize with the server. These requests are two seconds apart, and will continue until the Client and Server are able to successfully synchronize.
Devices operating behind a connection using a Network Address Translation (NAT) may display this screen when the NAT entry times out on the network appliance that is performing the NAT. This would affect devices that use a gateway, proxy, or shared network interface similar to what many home networks use for internet access. This message would never recover, requiring the user to press escape and reconnect with a standard handshake. Enabling the Server setting for ‘Support for Client Dynamic NAT’ will usually resolve this issue.
Out of Range
This message will appear three seconds after the exclamation. If it persists, you can use the StayLinked client’s ‘radio stats’ option to view the MAC address of the access point reported by the radio.
If this appears on a new device, it could mean that the client installed does not match the hardware, making it unable to properly request the association status. This may also appear if the hardware manufacturer makes changes to the radio hardware during the lifecycle of the device. Devices can be configured to ignore the association status using the client setting always_in_range=1. This setting is best applied using the Scan2Command profile options in the Administrator.
Log File Records
We can break these interruptions into two possible situations. The first is that the server is not receiving transactions from the device and the second is that the server is receiving the transactions, but the replies are not making it back to the device. There are a multitude of reasons that packets may not reach the server, but the second scenario is different because you know the device is associated and authenticated with an access point, has a valid network address and can probably communicate with other systems on your network. In either case, the ping and tracert commands can be important tools in detecting network connectivity. We typically recommend that these tests are completed from the StayLinked Server to the device, in order to confirm routing and other network variables for the StayLinked Server operating system.
The following are sample events recorded in the staylink.log file from a client device.
In this event, the client is connecting to the server and logging the server IP and port for this connection:
140401-215131.340:[i] reg_ip=10.162.21.10, reg_port=20050
In this event, the client is reporting the Exclamation and then [Out of Range], including a confirmation from the device operating system that the MAC of the access point is blank:
100321-011635.599:[i] <- oor_beg
100321-011636.614:[i] <- oor_max - AP=[00:00:00:00:00:00]
100321-011639.979:[i] <- oor_end
In this event, the client is reporting two interruptions, the first displays the [Linking] screen very briefly at the oos_max entry and then another interruption shortly thereafter. These current logs also show a ping of the gateway and server, confirming partial network connectivity:
140401-131508.548:[i] <- oos_beg
140401-131510.855:[i] gateway ping: reply from 10.133.1.1: time=3ms
140401-131510.889:[i] server ping: reply from 10.162.21.10: time=31ms
140401-131518.904:[i] <- oos_max - AP=[00:08:A2:01:64:00]
140401-131519.893:[i] <- oos_end
140401-131526.736:[i] <- oos_beg
140401-131528.051:[i] gateway ping: reply from 10.133.1.1: time=2ms
140401-131528.087:[i] server ping: reply from 10.162.21.10: time=31ms
140401-131528.090:[i] <- oos_end
In this event, the client is reporting an interruption that displays [Linking] in which the user presses the escape key to cancel the retry attempts:
140130-152938.077:[i] <- oos_end
140130-155357.570:[i] <- oos_beg
140130-155404.035:[i] <- oos_max - AP=[54:78:1A:D1:70:10]
140130-155445.206:[i] <- oos_abt
140130-155445.383:[i] <- oos_end
140130-155445.383:[i] host disconnect, code=120
From the Server perspective, the server will not be aware of packets that do not make it from the device. Once the device is displaying the exclamation or asterisk, these synchronization requests will be recorded in the StayLinkedManager log file as a query session status. The date and time are removed from this example for formatting.
Processing Query Session ID Request from 192.186.83.7: 'A8~05~263EC~'
Results of Query Session ID Request from 192.186.83.7 for 263EC is 'Y'
All log files are best reviewed with the assistance of StayLinked Support.
Share the post "Client-Server Connectivity"