Configuration

The additional parameters are located in the network settings for the COM port.

WEBconfig: LCOS menu tree / Setup / COM ports / COM-port server / Network settings

• Assume binary mode Some network devices connected to a serial COM port transmit data structures which may be interpreted as control characters (CR/LF – carriage return / line feed). In the default setting, the COM-ports in LANCOM devices process this information to control the data flow. "Binary mode" instructs a COM port to forward the data in binary format and ignore any control characters. Possible values:
  • Yes, No.
  Default:
  • No.
• Newline conversion Here you select the character to be output by the serial port when binary mode is activated. This setting is independent of the application communicating via the serial port. If the port is connected to another LANCOM device, you can either enter CRLF here or just CR. This is because the outband interface of these devices expects a "carriage return" for the automatic determination of data-transfer speed. However, some Unix applications interpret CRLF as a prohibited double line feed character. In these cases enter either CR or LF. Possible values:
  • CRLF, CR, LF
  Default:
  • CRLF
  Note: This setting is only relevant if binary mode is deactivated for this port.
• TCP keepalive The RFC 1122 sets down a method of checking the availability of TCP connections, called TCP keepalive. An inactive transmitter queries the receive status from the remote station. If the TCP session to the remote site is available, then the remote responds with its receive status. If the TCP session to the remote site is not available, then the query is repeated for as long as it takes for the remote to respond with its receive status (after which a longer interval comes into play). As long as the basic connection functions, but the TCP session to the remote station is not available, then the remote station sends an RST packet which triggers the establishment of the TCP session by the requesting application. Possible values:
  • Inactive: TCP keepalive is not used.
  • Active: TCP keepalive is active; only RST packets cause the disconnection of TCP sessions.
  • Proactive: TCP keepalive is active, but the request for the receive status from the remote site is only repeated for the number of times defined under "TCP retry count". If this number of requests expires without a response with the receive status, then the TCP sessions is classified as "not available" and the application is informed. If an RST packet is received during the wait time, the TCP session will be disconnected prematurely.
  Default:
  • Inactive
  Note: The setting "active" is recommended for server applications.
• TCP keepalive interval This value defines the interval between sending requests for receive status if the first request is not affirmed. The associated timeout is defined as being interval/3 (max. 75 sec.). Possible values:
  • Maximum 10 characters
  Default:
  • 0
  Special values:
  • 0 activates the RFC 1122 default values (interval 7200 seconds, timeout 75 seconds).
• TCP retransmit timeout Maximum time for the retransmission timeout. This timeout defines the the interval between checking TCP-connection status and reporting the result to the application using the TCP connection. Possible values:
  • 0 to 99 seconds.
  Special values:
  • 0 activates the RFC 1122 default value (60 seconds).
  Default:
  • 0
  Note: The maximum duration of the TCP-connection check is the product of TCP-retransmit-count and TCP-retry-count. The TCP application is only informed after the timeout for all attempts has expired. With the default values of 60 seconds timeout and max. 5 attempts, it can take up to 300 seconds before the application is informed about an inactive TCP connection.
• TCP retry count The maximum number of attempts for checking TCP-connection status and reporting the result to the application using the TCP connection. Possible values:
  • 0 to 9
  Special values:
  • 0 activates the RFC 1122 default value (5 attempts).
  Default:
  • 0
  Note: The maximum duration of the TCP-connection check is the product of TCP-retransmit-count and TCP-retry-count. The TCP application is only informed after the timeout for all attempts has expired. With the default values of 60 seconds timeout and max. 5 attempts, it can take up to 300 seconds before the application is informed about an inactive TCP connection.