Error M1556 Software Caused the Connection to Abort (Possible Communications/Device Timeout)

Problem

Status Client displays print requests that have failed with the following error. Failed print requests are moved to the Critical Failure folder under the listed printer.

(M1556) Software caused the connection to abort. (Possible Communications/Device Timeout).


When reviewing the Batchprint logs:

 

Note: The Status Client does not display the Windows Socket Error (WSA) code within the M-code error and can mislead the course of troubleshooting. However, when reviewing the Batch Print log the WSA error code (10053) is revealed.  

Explanation

Scenario 1

In the TCP transaction the LPS server has an active connection with the Printer and wants to close the socket. The LPS server sends the printer (a packet) with a “FIN”. This puts the LPS server in a FIN_WAIT_1 state. The printer receives the FIN packet and goes into a CLOSE_WAIT state. A Packet Capture (PCAP) will confirm if the printer is not sending the acknowledgment packet back to the server. The OS of the server is responsible for the allotted and controlling timeout period (default 120 seconds). When the timeout is reached the OS will shut down socket since the FIN_WAIT_2 state from the printer is never received by the LPS server.

The (M1556) is generated by the Windows OS signifying an problem with the TCP connection [LPS <->to<->Printer] and propagated to be displayed in the Status Client. What’s happening is a WSA [Windows Sockets Error] error was encountered. The specific errors explanations relating to the M-Code of (M1556) are as follows:

WSAECONNABORTED

10053

Software caused connection abort. An established connection was aborted by the software in your host computer, possibly due to a data transmission time-out or protocol error.
TCP/IP Scenario

A connection will timeout if the local system doesn’t receive an (ACK)nowledgement for data sent. It would also timeout if a (FIN)ish TCP packet is not ACK’d (and even if the FIN is ACK’d, it will eventually timeout if a FIN is not returned).
WinSock Description

The error can occur when the local network system aborts a connection. This would occur if WinSock aborts an established connection after data re-transmission fails  (receiver never acknowledges data sent on a data-stream socket).
Link to MS website for the list of WSA Error Codes  https://docs.microsoft.com/en-us/windows/desktop/WinSock/windows-sockets-error-codes-2

Scenario 2

A PRINT REQUEST is to be sent to a PRINTER. The PRINTER begins reading the PRINTSTREAM and detects something invalid in the PRINTSTREAM . It immediately sends an TCP response (with an error status) and closes the connection without trying to continue reading the remainder of the PRINT REQUEST.

Meanwhile, the LPS SERVER is still content writing the remainder of the PRINT REQUEST to the socket (remember a TCP/IP socket connection needs to be closed from both sides). In this case, the PRINTER has closed its side, but the LPS SERVER is still transmitting data into the half-open connection).

The LPS SERVER finishes writing the PRINT REQUEST to the socket — meaning that data has been buffered to Winsock.

The LPS SERVER then tries to read the TCP/IP response, but it cannot because the outgoing re-transmission (of the buffered data by WinSock) failed and the socket connection was shutdown (by Winsock). Even though the PRINTER sent the response, it is lost and cannot be retrieved. The error STATUS CLIENT will receive (M1556) when trying to read the TCP/IP response on the socket is WSAECONNABORTED 10053.

We can see from the PCAP in this instance the printer is initiating "RST". The OS is responsible for controlling the timeout duration; when reached, the OS will shut down the socket since the FIN_WAIT_2 state from the printer is never received by the LPS server.

Suggested First-Round Troubleshooting

  • Verify that the installed NIC in the printer is not faulty
  • Be sure the printer is using the most current firmware 

WHAT IS: FIN_WAIT_2 state in TCP networking is [FIN] = FINish Flag

FIN_WAIT_2 seems to occur when the server has an active connection with a client and wants to shut down the TCP connection (probably in response to a normal application layer "exit"). The server sends the client a packet with a "FIN" bit set. At this point, the server is in FIN_WAIT_1 state. The client gets the FIN packet and goes into CLOSE_WAIT state, and sends an acknowledgment packet back to the server. When the server gets that packet, it goes into FIN_WAIT_2 state. From the server's perspective, the connection is now closed, and the server can't send any more data. However, under the TCP protocol, the client needs to shut down also by sending a FIN packet, which the server TCP implementation should ACK. The server should close after a period of time defined by the Maximum Segment Lifetime (MSL).

Info on a modifying the FIN_WAIT_2 state timeout duration

The timeout for sockets in the FIN-WAIT-2 state is defined with the parameter tcp_fin_timeout. You can set it to a value high enough so that if the remote end-point is going to perform an active close, it will have time to do it. On the other hand sockets in this state do use some memory (even though not much) and this could lead to a memory overflow if too many sockets are stuck in this state for too long.

Configuring FIN_WAIT_2 timeout on Windows Server: Registry

On Windows systems, the variable to control the FIN_WAIT_2 timeout interval can be modified in the Windows Registry.

The Registry entry that controls this setting is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. You need to specify the TcpFinWait2Delay value for the above entry in the registry. The default value is 240s.

Note: Administrator privileges are required to set this value.

  1. In the Windows Registry, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  2. If the TcpFinWait2Delay value already appears in the details window, tune the value. The valid range is between 30s and 300s.
  3. If the value does not exist, right click and select Add a new DWORD value. Add TcpFinWait2Delay and set its value.
  4. Restart your system for the change to take effect.

Troubleshooting

There are a multitude of possible reasons why the error occurred and it is recommended that you work with Loftware Technical Support to resolve this issue.

Using a packet capture software is required to monitor and capture (PCAP) the TCP/IP transmission between LPS & Printer to determine the exact cause (who aborted the connection?). In addition to the source, the Loftware Print Server and the destination, the printer also consider any devices between the source & destination such routers, switches, firewalls, etc. that can contribute to the transmission of the TCP packets.

Please contact your network team to see if this is an option.

  1. Have your network personnel install & configure a packet capture application such as Wireshark.

  2. Allow the Packet Capture to run as long as needed to obtain a PCAP when the M1556 occurs.

    1. It is best to run the packet capture in timed intervals as the PCAP file can grow extremely large.
    2. Best practice dictate to install and run the packet capture software on a third computer to avoid server logoff's or inadvertent interference that can cause interruption of the packet capture.
  3. Loftware also requires these logs as well as the PCAP:
    1. Watchdog Logs.
    2. Batch Print Logs.
    3. Windows Event Viewer (exported)
  4. Only send logs to Loftware that reference the time stamp when the error occurred.  

Article Number

18205

Versions

All supported LPS family product versions

Environment

All supported environments