[coova-chilli]chilli internal web server VERY slow

[sophana]

While testing firmware-ng with coova-chilli, I found that initial redirection was very slow (the wireless hotspot bitmap redirection page)

After some testing, it looks like the mesh network is ok (about 4-5ms ping)

Then I noticed that it was the internal coova-chilli web server that is VERY slow.

For example, loading the hotspot.jpg (27kbyte) takes more than 3 seconds. (  http://10.126.0.1:3990/www/hotspot.jpg )

Wether you are authenticated to the hotspot doesn't matter. Internet speed is ok (authenticated or not) (about 550kByte/s through a repeater node).

This is not always slow. I've seen rare times when it goes at normal speed.

seen in r260

looks like a bug in coova-chilli.

[marek]

Yes, we have seen the same slowness but don't know what to do about it. Seems like a bug in coova-chilli. Did you try contacting the project and ask there ?

[sophana]

No I haven't contacted coova-chilli's author.

What is coova's version used? What about a downgrade test?

[marek]

NG uses coova chilli revision 299 directly pulled from the SVN. I vaguely remember we had to go to this version because it fixed a bug we were seeing. I would need to dig through my mails to give you details on that.

Downgrade to which version ? Do you know a version that worked better ?

[sophana]

What about an upgrade to lastest official release? v1.2.5, r394

[sophana]

I installed the coova-chilli ipkg from openwrt backfire.

 http://downloads.openwrt.org/backfire/10.03/atheros/packages/coova-chilli_1.2.2-1_atheros.ipk

It replaced the existing coova-chilli without any problem (have to disable open-mesh ipkg repository)

It seems to work without any problem. No performance problem anymore.

Another suggestion: the uamhomepage parameter is set to the default coova.html page inside chilli which makes a redirection after 7 seconds. This page is at /etc/chilli/www/coova.html

Could you please change the redirection time inside this page to 0, because it is very annoying.

The line to change is :

<meta http-equiv="refresh" content="0; URL=/prelogin">

The wait time is in content

It could be possible to remove the uamhomepage option, but I think it can offload the uam page http server, because of the multiple internet connections that are made from hidden background running software on windows clients.

Thanks

[marek]

Are you sure this is related to the new version or rather some configuration issue ? The openwrt package might also have installed some different settings ?

What is the difference between this redirection time in coova.html and the delay you reported ? Sorry, if this seems to be an obvious case but you seem to know much more about coova than I do.

[sophana]

The internal web server's job is (among others) to serve files for the captive portal. The time taken to serve static files is not configurable. This is why I think it is bug, and not a configuration issue.

When changing coova's version, no configuration has been touched. It seems to integrate the same as it looks compatible.

Is there a reason not upgrading to latest official version?

[marek]

Maybe my question was not clear enough. Does the timeout change in /etc/chilli/www/coova.html fix the delay or is this another issue and if it is something else, how does it manifest itself ? I'd like to test it before I submit the change.

Every time we upgrade coova and fixed one bug we got at least one new problem (or more). Therefore are very careful about changes ...

[sophana]

The redirection time in coova.html is another issue.

To reproduce the problem itself. simply connect to the public ssid, and get redirected. You should see the wireless hotspot bitmap appearing. Right click on it and display the bitmap directly in the browser.

 http://10.126.0.1:3990/www/hotspot.jpg

When I click on f5 (refresh), it takes 3 to 5 seconds for the bitmap to reload.

As I said, it sometimes works with no delay. Maybe you will have to connect more clients to the hotspot to make it slower.

Too bad custom.sh is not yet implemented. I would need a fix ASAP. BTW are the firmware-ng sources available? (or will they be?)

[marek]

Thanks for the explanations - I'll give it a try and make the according changes.

A custom.sh like system is on the to-do list but don't expect it to land this year.

For all questions not related to software bugs, please don't use this bug tracker but contact the proper channels ( http://www.open-mesh.com/contacts/).

[sophana]

Thanks

Another thing about coova-chilli setup. In the manual parameters, the uam url setting is absolutely useless. It is used inside the default UAM_SERVER.

It should be replaced by UAM_HOMEPAGE setting. The UAM_HOMEPAGE variable is the url of the default coova.html which shows the redirect page. If you set it to none, you will be redirected directly to the uam server.

After having examined the coova.html page, I found that it uses javascript to parse its parameters to build the redirection url. This implies that the client has javascript enabled or doesn't use a firefox extension like noScript. So this page will lower browser compatibility because of its javascript use.

There are 2 solutions for this: set UAM_HOMEPAGE to none or create a welcome.chi page that will not use javascript, but uses the internal coova-chilli haserl to generate the page.

If you want I can make this welcome.chi page for you to integrate it. It is quite easy.

It would be also very nice if there could be a new setting like "additionnal options" that would be a text box that would be appended to the generated /etc/chilli/config. It would allow to use all other useful coova-chilli options. It could replace the UAM_HOMEPAGE setting as you would allow to override all settings.

Actually, to change the uam_homepage, there is no other solution than editing the /etc/chilli/default file. Editing the /etc/chilli/local.conf has no effect other than making a warning because the setting was already set. It could also be possible to add an include to a local additionnal configuration file after the generated config file.

If you need help, just tell me...

Thanks ;-)

[marek]

We upgraded coova-chilli to 1.2.5 in our experimental builds and I also added the redirection time change you suggested. However, we are having trouble if the first page the user enters is a SSL secured site (https) the redirection will just hang until the browser timeouts. Is this is a known issue ?

If you made a welcome.chi how would we need to integrate it ? I welcome every step to make the setup more interoperable.

Thanks for your help!

[sophana]

Hi

This is very good news. I was about to publish an ngfix.sh script to fix this problem... Did it fix the redirection time for you? Will you also replace the uam url setting?

About https, I think this is normal. When the browser looks for an https page, it starts an SSL connection. coova-chilli will have to implement SSL in order to redirect the request. I'm not even sure coova chilli can even detect that it is an https request other than looking at the request destination port. This means it will never work for an url like  https://example.com:2000

I know quite recent coova-chilli versions have the openssl option, but I'm not sure it is for this purpose.

Even if coova-chilli had an ssl implementation, it would have a wrong ssl certificate, and the user will see an https warning before being redirected...

There is no good solution for this I think.

For the welcome.chi, I haven't made it yet. But I can work on it, it should be quite easy. I will also forward it to david. The welcome.chi file would be added in the /etc/chilli/www dir and the default uamhomepage (in /etc/chilli/default file) would point to it.

[marek]

With us some things might take a bit longer but that does not mean they were forgotten. ;-)

The redirection time was indeed shortened - good hint! But I did not touch the uam url setting because I have no idea what it does. Keep in mind that I am a novice when it comes to coova-chilli.

Your explanations regarding SSL make sense but why does it hang such an awful long time ? Most users will be frustrated at that point. Would it be possible to produce an error message ?

If you find the time to make a welcome.chi simply attach it to this ticket.

[marek]

Chilli 1.2.5 has entered the test repository, therefore I close this ticket. Feel free to re-open this ticket or open a new one if you have more ideas or the welcome.chi finished.

Thanks!

[sophana]

Hi

I succesfully tested r274. Thanks a lot for fixing this.

I've had a look at coova.html. It has a default redirection to /prelogin which seems to work also (but with an additionnal redirection)

Anyway, for a direct redirection without javascript here is the simple haserl script:

/etc/chilli/www/welcome.chi:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<html><head><title>Wireless HotSpot</title>
<meta http-equiv="refresh" content="0; URL=<? echo -n $FORM_loginurl ?>">
</head>
<body style="margin: 0pt auto; height:100%;">
<div style="width:100%;height:80%;position:fixed;display:table;">
<p style="display: table-cell; line-height: 2.5em;
vertical-align:middle;text-align:center;color:grey;">
<img src="hotspot.jpg" alt="" border="0"/></a><br>
<small><img src="wait.gif"/> redirecting...</small></p>
<br><br>
</div>
</body>
</html>

It can't be simpler. (it must be executable)

in /etc/chilli/defaults look for HS_UAMHOMEPAGE and change the line to

HS_UAMHOMEPAGE=http://\$HS_UAMLISTEN:\$HS_UAMPORT/www/welcome.chi

The dashboard manual configuration still has a useless "UAM URL" entry which IMHO you should remove or replace by an "additionnal options" text area.

[sophana]

I think I found a new bug in this coova version. The coova-chilli internal web server seems incompatible with android phones browsers.

The workaround is to set HS_UAMHOMEPAGE to none (or empty), and everything is working well. It simply removes the intermediate welcome.html page step. Redirection is directly made to the UAM server.

I'm still investigating on this.

[marek]

What a timing - I already started integrating the 'welcome.chi'. I wait for your feedback then ?

I have another question: You said the dashboard 'UAM URL' option is not needed but many of the existing captive portals make use of it today. Removing it would render them useless ? Maybe I misunderstand ?

Thanks for the clarifications!