Proxy_check debugging

[Emery Clark]

We are trying to secure a robot. The hub is secured and hub_adapter is installed and non-secure robots are communicating with the hub fine.

However, when we try to secure one of the robots we are getting the following communication error:

Mar 24 12:58:04:424 0 proxy_check: Sending get_info request to remote hub to verify proxy communications

Mar 24 12:58:04:430 1 proxy_check: (outbound proxy) Timeout or comm error waiting for reply. rc=-2

Mar 24 12:58:04:430 0 proxy_check: Failed to send message to hub

 

How can we debug this communication error?  Firewalls are OFF on both the hub and robot host.

[Gene Howard]

set the loglevel to 5 and logsize to 75000 on the hub and the controller.
restart the hub robot contorller service
then restart the robot's controller service.


------------------------------
Gene Howard
Principal Support Engineer
Broadcom
------------------------------

[Emery Clark]

I sent a private DM with our case ID. I don't see anything abnormal in the log files, other than the proxy_check.log noting the timeout with communication to the hub.
Logs were captured immediately after performing the steps you suggested above.

[Gregg Stillwell]

HI Emery,

I have not set this up as of yet but I noticed your top line on the screen shot. Do you have the proxy_private_key_password in robot.cfg? Is it still throwing out that error?

proxy_private_key_password

(For tunnel certificates) Specifies the password that you used while creating the tunnel certificate.

[Emery Clark]

From what I understand that's only for tunnel certs, as noted in your text and the documentation.
IM uses a salted hash to store the passwords in the config file so I don't think it would even work.
I have set this up previously using third party certs with no password. We have successfully ignored those messages.

[Gregg Stillwell]

Yes I see that now: only for tunnel server and client robots. Good to know to ignore that error.

[Erica Kelly]

Have you gotten a resolution to this? We are experiencing the same thing.

[Emery Clark]

Hi Erica,

No, there was no resolution. Broadcom Support was unable to assist and unfamiliar with installing third-party certs. They told us that we should expect an 8-12 week response from their dev team. After several weeks, a meeting was finally scheduled. By this time we had already moved forward with another solution. Ultimately our customer was forced to agreed to install/trust the internal Nimsoft-generated CA certificate used to sign the certs.

[Erica Kelly]

Good morning all,

 

Thank you Emery Clark for responding. I meant to send that sooner. I just wanted to let you all know that we got this to work. We ended up having to use wildcard certificates. You can use non wildcard certs, but that would mean you'd have to list every server (robots) name in the SAN section of the cert Or all of the server certs on those robots would have to be installed on the tunnel server. That just isn't efficient nor feasible due to new robots being deployed onto new servers all the time in my environment. So we went with *.domain.com in the commonName field of the certificate. For us the proxy_check was failing due to the hostname of the robot not matching the commonName nor subjectAltName of the certificate. The wildcard cert solved that problem the quickest and most efficient way.

 

Erica Kelly (Halfaker & Associates)

System Administrator, Sr

VA OI&T Service Delivery and Engineering

Financial Technology Serivce

Financial Services Center (FSC)

Office: [phone]

[e-mail]