Issue 32046  —   UROUTMON operation GET_UROUTER returns corrupt listen addresses when using TLS

Status:   Solved in 10.4.01

Solution available in patch(es):      10.3.02.025    9.7.05.038

Description:

 Summary:
 When connecting to the URouter using TLS then the UROUTMON operation
 GET_UROUTER returns corrupt listen addresses if a TLS profile TLS connection
 address is used.

 Environment:
 +Uniface:
 * Patch 9.7.05.03x (and higher)
 * Patch 10.3.02.02x (and higher)

 +Operating System:
 * OS independent

 +Database:
 * DBMS independent

 Symptoms:
 The UROUTMON operation GET_UROUTER gets static information about the Uniface
 Router (URouter). The info is returned in the entity parameter
 UROUTERS.UROUTMON. The mentioned entity includes three fields (lisaddr1,
 lisaddr2, lisaddr3) with the listen address of the URouter (e.g. the port
 number).

 In case the UROUTMON API connects to the URouter using TLS then the following
 problems can occur:

 1) If a TLS profile is used the remaining LISADDR fields (lisaddr2, lisaddr3)
 can be corrupted by the long data.
 2) If a TLS connection address is used, then it is possible that that port will
 appear as a duplicate in one of the LISADDR fields.

Workaround:

 There is no known workaround for this problem.

Notes:

 The corruption in the data has been fixed. For compatibility reasons the 'port
 address' field where it appears in an entity parameter will only show the first
 two characters of the TLS profile, if it has been used. This port address field
 appears in the UROUTERD entity as the 'conaddr' and 'lisaddr' fields, and in
 the URCLIENTS and the URSERVERS as the 'conaddr'.
 This does apply to the field when it is used as a parameter to the 'connect'
 operation. See the documenation for more details