Forum Discussion

Mike_Denny_1081's avatar
Mike_Denny_1081
Icon for Nimbostratus rankNimbostratus
Nov 22, 2010

iControl SDK hardcodes http for client running on any port other than 443

we ran into an issue internal to iControl SDK for Java. We were using lab systems for our tests via a gateway/NAT to access the lab systems from our iControl client code. On the gateway, we had mapped port 15443 of the gateway IP to port 443 of the F5 thru the gateway.

 

 

We were connecting with the F5 ok but that’s about it. The error messages were cryptic, and led us to investigate a number of things. We went from inspecting the format of the Soap, to reviewing and changing authentication, changing passwords (there was an issue posted on F5.com about special characters in passwords...is that still an issue?), to suspecting the self-certificates were invalid, reactivating the licenses, updating the certificates, and so on.

 

 

But, the problem it turns out was in the iControl code. iControl assumes that you are using http, not https if you use any other port other 443. This is hardcoded in the iControl assembly source:

 

 

private String buildURL()

 

{

 

String url = "http";

 

if ( 443 == m_port ) {

 

url = url + "s";

 

}

 

 

//url = url + "://" + m_username + ":" + m_password + "@" + m_hostname + ":" + m_port + "/iControl/iControlPortal.cgi";

 

 

url = url + "://" + m_hostname + ":" + m_port + "/iControl/iControlPortal.cgi";

 

 

return url;

 

}

 

 

That's the code used to generate the URL the iControl client will connect to run its operations. It's hardcoded as HTTP unless it's running on 443, in which case it's hardcoded as HTTPS. It was the problem, and we have modified our copy of iControl to work with our NAT setup…
  • Hi Mike,

     

     

    Thanks for posting this info. If Joe doesn't see this post here, you might try opening a support case to document the issue and workaround.

     

     

    Thanks, Aaron
  • I wouldn't open a support case as the iControl library for Java isn't an official supported product. Honestly, this is the first instance I've heard of this being a problem. I'm glad to update the code to what makes sense but the initalize calls only have port as distinguishing feature for the connection type. What I might do is add a separate attribute in the iControl.Interfaces class that contains a list of ssl based ports. Then if the port passed in on the initalize method is in that list, then I will default to a https connection. Does that sound like it would work?

     

     

    -Joe