GenieACS and SSL note

[Manny Veloso]

Oh, the problem isn’t the handshake, it’s that the device takes a lot longer to respond to the RefreshObject if it’s SSL. I’ll ask our engineering guys to take a look. I suspect that the gateways don’t do SSL offloading, so the 2048 bit stuff is just killing it.

--
Manny Veloso
Sr. Solutions Engineer
Smartrg.com

From: Users <users-bounces at lists.genieacs.com<mailto:users-bounces at lists.genieacs.com>> on behalf of Zaid Abdulla <zaid at genieacs.com<mailto:zaid at genieacs.com>>
Reply-To: Community support for GenieACS users <users at lists.genieacs.com<mailto:users at lists.genieacs.com>>
Date: Wednesday, August 12, 2015 at 4:38 PM
To: "users at lists.genieacs.com<mailto:users at lists.genieacs.com>" <users at lists.genieacs.com<mailto:users at lists.genieacs.com>>
Subject: Re: GenieACS and SSL note

On Thu, Aug 13, 2015, at 01:58 AM, Manny Veloso wrote:
Yep, we tried it with and without SSL. The delay in the response from the CPE averaged around 55 seconds over SSL, which must be SSL overhead. I guess it’s easy to forget that these don’t have a lot of CPU on them.

I don't know much about the topic but 55 seconds sounds way too long for SSL handshake and encryption of a few KBs even for a very limited hardware.

It could be that limited memory causing this delay for large responses due to use of swap space. If you're only seeing this much delay when refreshing the entire parameter tree of the device, then try setting the config option "GET_PARAMETER_NAMES_DEPTH_THRESHOLD" to, say, 3 or 4 to make the ACS fetch the parameter tree in iterations rather than all at once so you end up with smaller responses.

Zaid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genieacs.com/pipermail/users/attachments/20150813/ab9ca600/attachment.html>