The application is crashing while updating the tunnel information in the UI.
After IM starts the hub configurator application(conf_hub.exe), the application sends a request(probe_config_get) to the controller on the hub to get the configuration information of the hub. It then parses the configuration sections and updates the UI controls.
In the failure logs, we have seen the application stops after getting the robots details from the hub.
Mar 8 12:26:00:886 [11832] hub: SREQUEST: getrobots ->XXX.XXX.XXX.XXX/48016
It is not able to read the tunnel info and the subscribers details sections from the configuration data.
On inspecting the hub.cfg of the failover hub, we have noticed the key "notAfter" in the section /tunnel/server has a negative value.
notAfter = -2119687904
In the hub configure window, it relates to "Expire Date" which can be found at:
Tunnels -> Server Configuration -> Expire Date
The application was crashing while converting this value to a valid date and time. We were able to reproduce the crash in our environment by setting the same value in our hub.cfg.
The "Expire date" is a non editable field in the hub configuration window which is populated during tunnel configuration. There is one way negative value could end up in the configuration file. We have generated negative values following the steps below.
1) Go to Tunnel -> Server Configuration
2) Select the "Active" check box
3) It pops up the "Certificate Authority setup dialog box"
4) Provide number of days in the "Expire days" text box. The text box accepts only positive values limited to 4 numbers (max 9999).
5) Click "OK". A request (tunnel_new_certificate) is sent to the hub. Hubs produces "notAfter" in epoch (current epoch time + expire days * 86400), writes to cfg and returns the same value back.
6) The configurator application converts the value to date time in string format
As of today, "Expire days" set to 6887 causes integer overflow causing negative values in the configuration file. The same could be reproduced by setting expire days to 6887 in the new certificate window.
Some wrong values might have been entered during tunnel configuration. This needs to be fixed in the hub and UI code as well.