Wireless Access

Reply
Contributor II

Enable bypass captive portal landing page

In the process of troubleshooting high CPU utilization on our aging M3 controllers, I was looking into this setting:

 

web-server profile

bypass-cp-landing-page

 

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:

 

OLD DOC

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.

 

6.4.4.x DOC

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

 

 

 Thanks

 

Frequent Contributor I

Re: Enable bypass captive portal landing page

bryanc

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 1.2.3.4 and sends tcp syn to 1.2.3.4:80

c) captive portal acl picks it up, dest nats it to controller

d) controller spoofs the other half of the tcp connection from 1.2.3.4, 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 151.101.1.67...

> 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 151.101.1.67...
> 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.

 

hth.

 

 

 

 

Contributor II

Re: Enable bypass captive portal landing page

Thank you for the informative write up, it was interesting to read!

Frequent Contributor I

Re: Enable bypass captive portal landing page

no problem, please mark it as a solution so others can mine it later for info :) 

 

Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: