Development Delay (Computer Died)

As you may have noticed, I’ve not posted the 3.7 release, however it has been released, back in January.
However, I was looking forward to announcing a 3.7 update soon which includes some massive improvements in database calls for the displaying users page. We went from >1000 database calls to a fixed 9 for display all the users, as well as a much faster loading time. However this release is going to be delayed now due to my computer dieing recently. Until I can replace my computer I’m very limited in what I can do. No work has been lost as everything is nicely backed up, and the hard drive is fine anyway. So now we need to wait until we can afford a replacement computer (really, just the inside components, CPU, RAM, Motherboard) and then I can transplant them into my old case and we’ll be roaring away.

This is really disappointing for me, as I’m 1/2 way through the paypal integration, so you can allow customers to purchase tickets via paypal and credit card.

This is the new computer we are hoping to buy from Case, Powersupply and HDD’s are extras but are things we wanted to purchase in the near future anyway (HDD’s will be in RAID1 array for backup purposes to replace a NAS that is no longer suitable).

Version 3.6 Released

Version 3.6 was released today. This release is just focussed on network settings. You can now change the server lan ip address, and network, as well as set your own DNS servers (or use OpenDNS with Family Shield).
Please take note, that for these changes we now have dnsmasq installed, which all the clients will use as the DNS server, and dnsmasq will do the queries to the servers you set. It WILL NOT use the dns servers from DHCP or /etc/resolv.conf, you will need to set the dns servers manually or it will default to OpenDNS Family Shield.

As part of this update, the coova-chilli package has been update, as have the grase-conf-squid3, grase-conf-freeradius, and we have a new package called grase-conf-dnsmasq that does the network settings for coova chilli and dnsmasq.

For anyone who has manually modified the coova chilli files (/etc/chilli/config) this will again overwrite your changes, but that’s ok as now you can make all the changes in the admin interface and they won’t be overwritten again! If there are any network settings in /etc/chilli/config that aren’t currently available that you need, just open a bug report and it’ll be added fairly easily.

Standard upgrade is “sudo apt-get update; sudo apt-get upgrade”

Version 3.5 Released!

Today Version 3.5 was released to the repository.
Main new feature is customisation of the portal login pages!!! Let me know what more can be customised and it will be!

Straight from the changelog:

grase-www-portal (3.5.1) purewhite; urgency=low

* Editing of machine accounts is now active and working (accounts no longer “locked”)

— Tim White Wed, 28 Sep 2011 11:53:41 +1000

grase-www-portal (3.5) natty; urgency=low

* Display group properties in edit and new user pages
* Customisation of login pages
* Some HTML5 changes for forms and inputs
* Fixes for expiry to support to the second not to midnight of the date
* Easy “unexpire” of an expired user. Fixes #14

Growth of GRASE Hotspot over last few months

Thank you to everyone who is using or assisting with the GRASE Hotspot!

I thought I’d give you a bit of a heads up as to what has been happening over the last few months.

Firstly, a large number of new features have been added this year, including new report graphs, dynamic groups, and internationalisation. So far we have a French translation done, and an Italian and Portuguese translation are in progress. We have also had some members of the community discuss assisting with development which will speed new feature requests up!

For those who don’t know the history of the GRASE Hotspot, it started development almost 4 years ago, and has been in active use for the last 2 years in a single location. Last year a major change in it’s development occurred which was the ability to deploy it quickly and easily using debian packages. This was a major break through and removed a lot of the extra “installation” code that was being maintained just to keep it up to date. We also moved from a SVN repository to using BZR to maintain our source code repository. The big step was at the end of last year (2010) we finally released the project into the community on sourceforge, finally allowing the community to use it.

Since that release things have moved very fast with more development happening faster than before. Feature requests have been filled sometimes in less than a week since it was requested. The large community has also enabled us to find bugs better and squash them with more devices to test on. In particular this is helping fix the iOS bug that was preventing iPhone and iPad users from logging in. (Anyone still experiencing this bug, please contact us).

As you can see in this image, the traffic to the website has been on the increase which shows that we are getting more and more exposure! (The drop at the end is because it’s the start of a new week when I saved this graph).

To assist with the growth of the community, I’ve now setup a mailing list for users and developers to all participate in. This will enable any email support that is occurring to benefit the entire community, especially when the same problem is experienced by a few people. I’d ask that support requests are directed to the mailing list now instead of directly to me.

For those who are wondering what is happening with the hotspot currently, here is what I am working on. Recurring limits, for example allowing a user to have 1hr per day. We are also hoping to have recurring data limits like 200Mb per day, however due to limitations in other software we rely on, it is not possible to guarantee exact limits, so the implementation will be to loosely enforce the data limits. I’m also going to start working on customisation of the login pages so that each location can display a more unique login page.

As I am a University student with a family to support, development will slow down over the next few weeks as I have Exams. (I have mostly finished the recurring time limit code, so that might be released during the exam period).

Lastly, I’d like to remind you that if this project has assisted you, to please consider donating ether some of your time or money to assist it’s development. Even if you aren’t a coder, working on better documentation, or doing translations are all ways you can assist. If you are a developer then working on new features. If you are just someone who benefits from it and don’t want to give time, your financial donations are always welcome as they allow me to develop while at University.

Thank you for being part of the GRASE Hotspot Community.


Caught by Max Int

So, MAX_INT caught me out. Of course, I couldn’t work out why everything worked fine on my machine, but on another machine the exact same code was returning a negative number! I should have clued on when I was told that values over 2Gb caused problems. But why wasn’t the problem showing on my machine? It’s actually really simple, I’m using a 64bit machine so my “intval” function in PHP has a higher limit than on a 32bit machine. A quick google, a “bigintval” function and everything is back to normal!

Improving Debian Compatability

As my main development box is Ubuntu, it’s hard to know if my packages will run on Debian. Obviously I don’t want to exclude any deb based Distro, but for now I don’t offer any guarantee’s that the packages will run on anything other than my machine. I will however do my best to ensure it does run on both Debian and Ubuntu.

Today I fixed a “bug” preventing it running on Debian Squeeze. Turns out there is a bug in the smarty package ( which hasn’t been fixed in Squeeze yet. Quite simply, the path for the Smarty class is in a different place on Debian than Ubuntu. Ubuntu “fixed” the path to be inline with upstream Smarty, and didn’t get it fixed in Debian at the same time. The fix is in Debian unstable. So rather than forcing everyone who wants to use the Hotspot on Debian Unstable, I added an if statement on the class including code to check for the Debian path, and load from there, else load from the standard location for Ubuntu. Problem bypassed!

If you are using this package on Debian, please let me know anything that doesn’t work as expected so I can try and have the package working for everyone.

I also pushed another change today, that force’s the grase-conf-squid3 package to conflict with the squid package. Seems you can have both squid 2.7 and squid 3.1 installed at the same time. Unfortunately my config files are for squid3 (and there are reasons for using squid3 over 2.7), and for foolproof operation I need to ensure that squid3 is running. Simplest solution, make sure squid 2.7 is uninstalled. This also ensures the user doesn’t get confused if they are trying to customise any of it. So when you next update, if you have squid 2.7 installed, it will be removed.


While it is possible to install this from the source code (bzr), it’s not designed to be installed that way and will give you lots of trouble.
The reason it is package in .deb files is so that certain dependencies are met, and the configurations for all the pieces of required software is automatic.
Please read the installation instructions before installing.

Attempting to install from the source will not be supported unless you are building debian packages from the source and installing those. Without the debian packages, crucial steps will be missed.

If you wish to assist with porting it to another packaging system, please contact me and we can see if it satisfies the dependency resolution requirements as well as the setup steps.

Version 3.1

Version 3.1 Has been released today.
From the changelog:

  • Basic support for translations now exists
  • Locale support removes need for selecting Currency
  • Locale support brings proper number formats for all locations
  • Added menu show/hide bar
  • Added Tabs to show groups in User List
  • UAM Fixes for looping login and logout link changed
  • Portal Configuration Options (ChilliSpot-Config)
  • Groups are now Dynamic
  • Removal of mysql_real_escape_string for mdb2->quote
  • Menu reorganised and grouped. Changed appearance
  • Machine group is now known as Computer

If you are already running the hotspot, just “sudo apt-get update” and “sudo apt-get upgrade” to upgrade to the newest version!

Strange Networking Woes

So today is the first day of Auscon. The organisers have choosen to use GRASE Hotspot to manage Internet access at the venue. The machine running the hotspot had been tested at an alternative site successfully, and the interface modified slightly to suit the event. (Which won’t need to be done as much with some new changes in the next version)
However, the day didn’t look good with the hotspot not functioning properly. Everything BUT WWW (http, port 80) traffic was working. Investigating Squid showed that it was attempting to connect to, which most keen observers would notice is a network address not a device address. Strangely enough, squid was trying to connect to via ipv6! It was thinking it was an ipv6 address.

The quick solution was in to install dnsmasq on the hotspot machine, and point it to a public DNS server I know to be working, and restart squid with it using the local dnsmasq instance. Everything is good now.

But is that the real issue? There is an overlapping netmask. Coova Chilli is setup to use (so for it’s addresses. However, the upstream network interface was setup on a which overlaps the Coova Chilli network. It’s very possible that this overlap is causing problems. An example of a squid log message when the problem occurs is below.

GET - DIRECT/ text/html

So maybe if you are pulling your hair out, try changing the upstream network if you can. It could also be the upstream DNS (adsl modem) returning faulty values.

Edit: So on follow up, the overlapping netmasks aren’t the issue. Yes, if there was something on the upstream network that was in the overlap range, then it would be inaccessible to hosts behind the hotspot. However, this issue was caused by the upstream DNS server. I believe it is a dlink running dproxy, which has a bug that causes it to start returning after it gets an ipv6 dns request or something like that. Of course, this then caused squid to try and contact as that was what the DNS had resolved to, which of course leads to a timeout. Forcing the hotspot to use the local dnsmasq with a known good public DNS server fixes the problem as we bypass the faulty DNS proxy upstream.

Preliminary Support for Localisation and Translations

Preliminary support has been added for translations and localisation. Using php-gettext (the php version, not the module) so that the locales don’t need to be installed on the system hosting it, and using php-intl, we now can support numbers and currencies formatted correctly, as well as translations.
I’m hoping that the Strings are “semi frozen” for now, so feel free to pull the .po files from bzr ( and start translating!
I’ll add the code shortly to select the current language and locale.

Also coming soon are the much awaited “Chilli Config” pages, where you can tweak the config that CoovaChilli runs off, all from within the web interface. It’ll use the RADIUS Config attributes so that your don’t need to open your config file up for the webserver to write to. This will allow greater flexability in defining uamallowed domains, MAC password, idle time, and just about anything you could change in the coova chilli config files!