01-12-2018 07:32 AM
In the process of troubleshooting high CPU utilization on our aging M3 controllers, I was looking into this setting:
We enabled this when the command was introduced but has the behavior of the command changed? The reason I ask is I was comparing the old documentation with what I saw in the 6.4.4.x CLI guide:
Enable bypass captive portal landing page -- Bypasses captive portal landing page. This enhancement is added to reduce the load on the controller for non-browser applications on smart devices like iPhone, iPad, and more. By default it is false(disable).
When this feature is enabled, the controller sends 200 OK status code message to the now-browser based apps
so that the apps stop sending repeated requests to the controller. This reduces the load of the httpd process
on the controller. This feature is enabled by default.
If disabled, the controller uses the new
redirection scheme also known as the landing
page by default including the meta tag. This
can reduce the CPU load on the controller. The
controller falls back to the old redirection
scheme if this parameter is enabled.
So, how should we have this set to help reduce CPU utilization from unauthenticated sessions?
We have it set to:
Enable bypass captive portal landing page true
According to the latest documentation, it sounds like we should set it to Disabled (false):
Enable bypass captive portal landing page false
Solved! Go to Solution.
01-15-2018 06:35 AM
yeah it's a bit confusing, the documents are not really clear about it. Here is the summary for you:
since day 1, Aruba used a HTTP 302 redirect mechanism, as do most captive portals. The sequence being like this
a) user browses to cnn.com
b) dns happs, gets IP 126.96.36.199 and sends tcp syn to 188.8.131.52:80
c) captive portal acl picks it up, dest nats it to controller
d) controller spoofs the other half of the tcp connection from 184.108.40.206, the browser sets up a tcp connect and does HTTP GET / (or other page)
e) controller responds with a 302 redirect to the 'login page' and appends all the captive portal window dressing (macaddr and friends)
f) client then follows the 302 redirect which causes the actual captive portal login page to be generated and sent to the client. In the case of the controller, and especially in the case of https, this is real "work"
All was well until smartphones turned up with background apps doing everything in the background, which caused the httpd on the controller to get pounded all day long, setting up connections, sending 302 redirects that when followed, returned the whole login page to some app that only cared about polling some API endpoint for the weather forecast etc....
The solution to this was, in short, to send HTML back containing a <meta http-equiv='refresh' location='somewhere'> rather than setting the Location in the HTTP header.
The reason being that background apps generally don't decode HTML and thus they don't follow the 'refresh' and don't end up putting any further load on the controller beyond that first packet.
You can demonstrate this to yourself using wireshark and your webbrowser. Below demo is using curl because it's easier to copy/paste here (captive portal set to controller landing page, protocol-http enabled)
>> A) Enable bypass captive portal landing page false (default)
$ curl --verbose http://cnn.com * Trying 220.127.116.11... > GET / HTTP/1.1 > Host: cnn.com > User-Agent: curl/7.56.1 > Accept: */* < HTTP/1.1 200 Ok < Date: Mon, 15 Jan 2018 14:22:49 GMT < Server: Apache < X-Frame-Options: SAMEORIGIN < X-UA-Compatible: IE=edge;IE=11;IE=10;IE=9 < Expires: 0 < Content-Length: 134 < Connection: close < Content-Type: text/html < <html> <head> <meta http-equiv='refresh' content='1; url=http://cnn.com/&arubalp=c9669565-d7df-4f12-873e-70baf57a3a'> </head> </html>
>> B) Enable bypass captive portal landing page true
$ curl --verbose http://cnn.com * Trying 18.104.22.168... > GET / HTTP/1.1 < HTTP/1.1 302 Temporarily Moved < Date: Mon, 15 Jan 2018 14:01:12 GMT * Server Apache is not blacklisted < Server: Apache < X-Frame-Options: SAMEORIGIN < X-UA-Compatible: IE=edge;IE=11;IE=10;IE=9 < Location: http://192.168.1.123/cgi-bin/login?cmd=login&mac=10:00:02:3f:21:ea&ip=192.168.1.52&essid=cp%2Dcp&apname=apXYZ&apgroup=blah&url=http%3A%2F%2Fcnn%2Ecom%2F
In the first case, the default, you can see the controller sending back
<meta http-equiv='refresh' content='1; url=http://cnn.com/&arubalp=c9669565-d7df-4f12-873e-70baf57a3a'>
which in itself, once queried, will return a 302 redirect that looks like item B) above, this acting as a bit of a double blind (arubalp == aruba landing page).
The amount of CPU saved here is significant, certainly you should leave it set to 'false' in 6.4.x which means "use the <meta> method"
Side note, if you're having high httpd cpu on M3, you can also review a few things like whether you can do with out https, or better still run the page in http, and just set the action in the username/password form to be https.