In the release notes for 7.70 I believe, CA updated their recommendations that tunnels should be used whenever possible and that compatibility mode should be used (or at least that's how I read the verbiage).
I have seen the following issues:
- On a new install using the 8.2 infrastructure package from the web (hub 7.71), in some case, the hub will terminate with no reason logged between 5 and 15 seconds after starting the tunnels configured. Windows event log records the event as an app crash with the C0000005 indicator. Setting ssl_mode = 0 and restarting the hub "fixes" the issue.
- After a period of days running, probes on a hub (7.70/7.71/7.72) with ssl_mode = 1 will stop being successful in connecting to queues on that hub. Restarting the robot will "fix" the issue for a period of hours to days but it will reoccur. Again, setting ssl_mode = 0 and restarting the hub "fixes" the issue.
- After a period of time, probes will report the contents of queues as being corrupt (hub 7.71/7.72). For example, I use the syslog probe and parse those results with logmon. After a period of days, logmon will stop being able to read the contents of the SYSLOG queue and will record in the logs that the head entry in the queue is corrupt. Restarting the individual probes or robot didn't correct the issue. Resetting ssl_mode to 0 and restrting the robot did correct the issue and logmon successfully read the entries on the queue.
- And as an annoyance, the hub logs are full of log messages like (7.70 and newer):
Jul 1 10:27:45:170  hub: SSL - negotiated ciphers: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
Jul 1 10:27:45:170  hub: SSL_write - wrote 276 bytes to 192.168.0.15/48000
Jul 1 10:27:45:185  hub: SSL_read - read 54 bytes from 192.168.0.15/48000
Jul 1 10:27:45:185  hub: SSL_write - wrote 248 bytes to 192.168.0.15/48000
Jul 1 10:27:45:185  hub: SSL - SSL_shutdown 192.168.0.15/48000
even at log_level=0
- After a period of hours to days, hubs (7.72) with tunnels but local LAN access to other hubs will stop their tunnels and refuse to restart/use them. Another reachable hub will then report that failed hub as a robot under it. It was not possible to connect to the errant hubs with any of the Nimsoft GUI tools but from the logs it appeared that the hub process was still active and that the tunnel server was working as expected but the tunnel client had failed. This resulted in the situation where data inbound came into the partially failed hub and was queued but that the "next hop" get queues were unable to retrieve that data because hub path that was configured into the GET queue was no longer valid. Restarting the robot would fix this until it happened again. Resetting ssl_mode to zero and the issue has not reoccurred.
Anyone have any similar experiences?