2011-09-27 - Re: [GRASE-Hotspot] Some Questions

Header Data

From: Tim White <ti***8@gmail.com>
Message Hash: 51875edbb13f6f4750507051a38368f332a3a5a42dcfcb640ecd7fb6720c8637
Message ID: <4E8246E1.5090003@gmail.com>
Reply To: <1317133053.3718.YahooMailNeo@web161421.mail.bf1.yahoo.com>
UTC Datetime: 2011-09-27 14:57:53 UTC
Raw Date: Wed, 28 Sep 2011 07:57:53 +1000

Raw message 

Hi Tim

On 28/09/11 12:17 AM, tim storey wrote:
>
> Secondly, my setup involves tickets based on data volume, so I have 
> had to write up some very basic PHP pages (and add one table to 
> mysql) to issue tickets and see who's on. You are welcome to a copy if 
> you would like.
I'd love to see the changes you've made as GRASE already has support for 
tickets based on data volume. (Just ignore the prices). We are looking 
at how we can better customise what options are presented when creating 
a user.
>
> My questions are as follows:
>
> 1) Idle-Timeout
> The idle timeout of active connections is very low (5 minutes?). I 
> added the Idle-Timeout attribute to radgroupcheck, but it made no 
> difference.
> Is there another way to do this?

Currently it's set in the coova chilli config file. I'll see at putting 
it as a configuration option in the portal config section.
>
> 2) ADSL Availability
> When my ADSL is not available (a frequent problem here in South 
> Africa) the login page is not served to new connections - the DNS 
> cycle simply times out.
> Obviously I would like to post ADSL status messages on the portal (and 
> mini) pages, but what do I need to configure (and how) to change the 
> default coova-chilli/radius behaviour?

Unfortunately this is a lot harder than you would think. Coova Chilli 
relies on a connection being made through the gateway, so it can 
"hijack" your connection (send you the captive portal). I actually 
developed the software while living in South Africa, so I know your 
pain. My solution only worked for machines in the office/internet lounge 
as I just set the homepage to be the portal login page. Computers that 
are dynamically coming and going just had to put up with it not working 
when the net was down.
There are remnants of a status page (see the bottom of the first page in 
the radmin interface for a link) that we'd use to determine why the net 
was down, by pinging dns servers, gateway servers, a south african 
google server and an international server to determine where along the 
route the problem was.

If you can find a better solution I'd love to hear about it!

Tim

Thread