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
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.
There is no known workaround for this problem.
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